The producers will want the R1 disc out ASAP, following up with the R2/other regions as the translations are done.
But the translations have to be done ealier anyway, they do have subtitles in the cinema. And there is still a large enough window between the DVD comming to a cinema and the DVD being released. Having translations ready shouldn't be a problem.
How did you get 36 million? That is a large number.
It is a large number. During those four days I also performed nummerous adjustments to my system. I shortned the SMTP responses from my honeypot because I have a quite limited upstream. I adjusted the maximum number of simultaneously allowed SMTP sessions. I found ways to control the bandwith used for spam, so I could slow down the spam when I needed to use the connection for other purposes.
Did you request any for testing or does that include ORDB testing?
Any SMTP server on the net receives messages from spammers looking for open relays. And spammers do use databases with informations about open relays. I have no proof that they use ORDB, but another database who's name I don't remember. I had a simple heuristic for identifying relay probes, and after looking on them I relayed by hand anything I was confident was in fact such test messages. But AFAIR I have always avoided those from ORDB. The delay caused by this manual handling will probably not look suspicious to the spammers. That is what they should expect from a server feed with this large number of spam mails. Of course none of those spam mails ever reached their intended recipients.
With my own honeypot I was once able to collect 36 million spam mails over a periode of four days. That means I have (hopefully) stopped more spam mails than I will receive in my entire life. So I did my share of the spam fighting. And hey, I don't worry about those emails from spammers threatening to kill me.
But that domain name points at an IP address inside Microsoft's network. But then I just noticed the funny part. The most stable web servers on Microsoft's own network are running Apache/1.3.9 on Linux
So what does it take to make the paperless office become reality? Considering that most of the tasks I ever do with paper boils down to a few simple actions. I print something out on paper. I sit down in a nice chair or at my desk and read it. I sit down at my desk with a few pieces of paper and a red uni-ball and write comments on the paper, possibly also drawing a few lines. Later I sit at my computer with the paper lying beside me, and do some typing.
All it takes to stop me from using paper is a few fairly simple pieces of hardware. An electronic desk, where I can manipulate my virtual printouts and add comments with an electronic pen. And an A4 size handheld, where I can do the same. Obviously it must be robust and good for reading from unlike
monitors.
Number one problem I see today preventing this from becomming reality is people constantly trying to make systems incompatible. For this system to be usable, it must be as compatible as a piece of paper and a pen. As long as we have closed document formats the paperless office will never become reality.
Because it is d*mn hard to prove who was actually sitting at the keyboard when the attack was successful.
You don't need to be sitting at the keyboard to perform an attack. Of course successfull attacks can be tricky as it will allow the attacker to change the logs. But if attempts against secured systems were logged, there is no way to avoid leaving some trail. Whether the trail leads all the way to the attacker is doubtful.
IIRC the load balancing for Windows Update is carried out bu linux machines
Not anymore according to netcraft. Only trace left of Linux I could find is www.microsoft.com running on Linux until about a week ago. And they have been changing a lot the last week, so those traces will soon be gone as netcraft appears to keep only the last 10 changes.
Put MD5 sum of original driver(s) and check for it on the Knoppix
CD?
That is also what I would do (except that I might choose SHA1 rather than MD5), but the problem is, how do you know the MD5 sum of every possible version of that file with wich the driver works. What about the day you try to use your CD on a system which have a new version of the.sys file released after your CD?
Surely it is illegal to copy the ntfs.sys driver and distribute it in another operating system
I was thinking exactly the same, but there might be a way around that. Knoppix just have to contain the wrapper code, the actual.sys file can be loaded from the harddisk (if present). Systems with an NTFS formatted harddisk and no ntfs.sys file are probably rare. Problems that need to be solved are, how to verify intergrity of the ntfs.sys file you are going to load (if you care about that), and how to actually load the ntfs.sys file from an NTFS filesystem. It is not entirely a chicken and egg situation, as Linux already have NTFS read support, which is far simpler than full read-write support. Besides loading ntfs.sys would even be a user mode task, and reading NTFS from user mode is probably easier to implement than doing it from kernel mode.
There are a bunch of other places in the kernel that call do_brk() - mostly in the binary loaders
Is it exploitable through binary loaders? My investigation seems to show you had to move the stack to exploit the vulnurability. BTW my investigation also shows, that the vulnurability is not an interger overflow. I could crash my system without making any overflows.
Slashdot Mirror
the DVD comming to a cinema
Oh boy, what does it help to preview, if you don't read it before clicking submit?
The producers will want the R1 disc out ASAP, following up with the R2/other regions as the translations are done.
But the translations have to be done ealier anyway, they do have subtitles in the cinema. And there is still a large enough window between the DVD comming to a cinema and the DVD being released. Having translations ready shouldn't be a problem.
I'd hate to burst your bubble there, but Windows does not run on PPC architecture. Neither do most of the OSes.
But using Virtual PC is still Cheating. So probably this just means you cannot run that many different operating systems on a Mac without cheating.
need to say something like "150 hours a month
:-)
How about at most 745 hours per month
A few days in a sleep test chamber...
Simpler than that, just pick those who regularily oversleep.
can ti do the proof for 11^2+12^2=13^2
I hope not.
"A pigeon can fly at a cruising speed of 65km/h, 100km/h when pushed," said Mr Andreef.
And somewhere else he said 20km in about 6 minutes. so which numbers are correct?
How did you get 36 million? That is a large number.
It is a large number. During those four days I also performed nummerous adjustments to my system. I shortned the SMTP responses from my honeypot because I have a quite limited upstream. I adjusted the maximum number of simultaneously allowed SMTP sessions. I found ways to control the bandwith used for spam, so I could slow down the spam when I needed to use the connection for other purposes.
Did you request any for testing or does that include ORDB testing?
Any SMTP server on the net receives messages from spammers looking for open relays. And spammers do use databases with informations about open relays. I have no proof that they use ORDB, but another database who's name I don't remember. I had a simple heuristic for identifying relay probes, and after looking on them I relayed by hand anything I was confident was in fact such test messages. But AFAIR I have always avoided those from ORDB. The delay caused by this manual handling will probably not look suspicious to the spammers. That is what they should expect from a server feed with this large number of spam mails. Of course none of those spam mails ever reached their intended recipients.
With my own honeypot I was once able to collect 36 million spam mails over a periode of four days. That means I have (hopefully) stopped more spam mails than I will receive in my entire life. So I did my share of the spam fighting. And hey, I don't worry about those emails from spammers threatening to kill me.
an alias for www2.microsoft.akadns.net
But that domain name points at an IP address inside Microsoft's network. But then I just noticed the funny part. The most stable web servers on Microsoft's own network are running Apache/1.3.9 on Linux
So what does it take to make the paperless office become reality? Considering that most of the tasks I ever do with paper boils down to a few simple actions. I print something out on paper. I sit down in a nice chair or at my desk and read it. I sit down at my desk with a few pieces of paper and a red uni-ball and write comments on the paper, possibly also drawing a few lines. Later I sit at my computer with the paper lying beside me, and do some typing.
All it takes to stop me from using paper is a few fairly simple pieces of hardware. An electronic desk, where I can manipulate my virtual printouts and add comments with an electronic pen. And an A4 size handheld, where I can do the same. Obviously it must be robust and good for reading from unlike monitors.
Number one problem I see today preventing this from becomming reality is people constantly trying to make systems incompatible. For this system to be usable, it must be as compatible as a piece of paper and a pen. As long as we have closed document formats the paperless office will never become reality.
A lot of incorrect assumptions about Linux - stated by Andrew S. Tanenbaum in 1992. Read the posting on google groups.
- Minix is simpler than FAT, and thus requires less code to implement
- Minux use a tree structure and thus performs better than the linked lists used in FAT
- Minix have a cleaner design
- Minix natively supports long filenames without that vfat crap.
Funny that the patents really only covers all the design mistakes.Because it is d*mn hard to prove who was actually sitting at the keyboard when the attack was successful.
You don't need to be sitting at the keyboard to perform an attack. Of course successfull attacks can be tricky as it will allow the attacker to change the logs. But if attempts against secured systems were logged, there is no way to avoid leaving some trail. Whether the trail leads all the way to the attacker is doubtful.
It doesn't have, but would be trivial to implement. Here is my suggestion how a patch for that should look (untested):
Break in to SCO... priceless...
What would you do if you succeeded? Steal their source?
IIRC the load balancing for Windows Update is carried out bu linux machines
Not anymore according to netcraft. Only trace left of Linux I could find is www.microsoft.com running on Linux until about a week ago. And they have been changing a lot the last week, so those traces will soon be gone as netcraft appears to keep only the last 10 changes.
Put MD5 sum of original driver(s) and check for it on the Knoppix CD?
.sys file released after your CD?
That is also what I would do (except that I might choose SHA1 rather than MD5), but the problem is, how do you know the MD5 sum of every possible version of that file with wich the driver works. What about the day you try to use your CD on a system which have a new version of the
Surely it is illegal to copy the ntfs.sys driver and distribute it in another operating system
.sys file can be loaded from the harddisk (if present). Systems with an NTFS formatted harddisk and no ntfs.sys file are probably rare. Problems that need to be solved are, how to verify intergrity of the ntfs.sys file you are going to load (if you care about that), and how to actually load the ntfs.sys file from an NTFS filesystem. It is not entirely a chicken and egg situation, as Linux already have NTFS read support, which is far simpler than full read-write support. Besides loading ntfs.sys would even be a user mode task, and reading NTFS from user mode is probably easier to implement than doing it from kernel mode.
I was thinking exactly the same, but there might be a way around that. Knoppix just have to contain the wrapper code, the actual
What about 2.2.x series kernels, is there a similar patch?
I wrote some exploit code for the 2.4 kernel, it didn't work on 2.2, so maybe 2.2 never had this vulnurability.
There are a bunch of other places in the kernel that call do_brk() - mostly in the binary loaders
Is it exploitable through binary loaders? My investigation seems to show you had to move the stack to exploit the vulnurability. BTW my investigation also shows, that the vulnurability is not an interger overflow. I could crash my system without making any overflows.
(addr + len) > TASK_SIZE
Isn't this a strange place to perform this test? Wouldn't it be simpler to just test for (brk > TASK_SIZE) in sys_brk?
(addr + len) < addr
Isn't that case already covered by the test (brk <= mm->brk) in sys_brk?
I did some hacking on my RH7.3 system, so now I can answer my own question. This is how
I could not find mention on Redhat's bugzilla. Do they know about it?
They should know. Quoting...
Study of the exploit by the RedHat and SuSE kernel and security teams...