Reading the announcement for Exec Shield, I can see that the author is aware of the work of Solar Designer, who released the first non-execuable stack solution many years ago. However, I don't see any mention of PaX, which extends the the Openwall solution to other memory regions.
It should also be pointed out that while most buffer overflow exploits do indeed simultaneously overwrite the return address and inject the shellcode onto the stack, a certain class of buffer overflow exploits called return-into-libc attacks do not require executable stacks and are not too difficult to construct. These attacks overwrite the return address with the starting address for one of the libc exec*() functions. At the same time, the parameters for executing/bin/sh are pushed onto the stack. The execution of the corresponding return instruction then causes the exec*() function to execute/bin/sh. See this paper for a more detailed analysis of some buffer overflow solutions.
I think that it's interesting that in the past few weeks, several solutions for buffer overflows have been announced (e.g., the OpenBSD announcements). Each of these solutions are good solutions, but they heavily borrow from earlier solutions. Unfortunately, the previous work has often not been properly acknowledged. Since the masses are generally not aware of the current state of the art, these supposedly new solutions are given more credit than due. Still, I suppose it's a good thing if general awareness of the buffer overflow problem is raised, even if the pioneers of the technology do not receive their due credit.
Microsoft is not stupid. They realize that most people will not bother to do extra research in verifying claims. In this case, somewhat readily available information casts NT-based system availability guarantees in a inferior light. Some of the information is of the smack in your face type, like the Compaq page that shows a much better guarantee for Unix systems than for NT systems.
Yes, the Compaq site clearly shows that the availability guarantees for Unix are much higher (.9999 vs.999) than for NT. This is also true for HP (.9995 vs.999), although you have to do a search of the HP site to find the Unix availability guarantee.
Perhaps the Unisys guarantee is the most interesting. Microsoft implies that the use of NT on Unisys systems allows Unisys to guarantee availability. However, the fine print says "A system failure is defined as a hardware failure.... This specifically excludes other causes of failures including, but not limited to, site disasters, operator errors, or failures of applications, ***operating systems***, or networks."
The cars-laptops analogy is interesting. However, the question is not necessarily pure speed vs. pure efficiency. To pursue the car analogy further, the Geo Metros and other ultra-efficient cars were not commercially successful because the same design that produced ultra-efficiency also caused the performance to drop below the acceptable threshold of most consumers. Rather than really small cars that could get 50mpg, consumers decided that 30-40mpg cars with more power were more desirable. It still remains to be seen whether Crusoe-based laptops will be in the Geo Metro class or the more successful Civic/Corolla class.
Another consideration is the growing trend of business laptop users using their laptops as their primary computer. Whereas in the past, laptops were used mostly for their mobility and more demanding tasks were executed on more powerful desktops, there is a growing shift to using a single laptop in a docking station. Such machines must not only be efficient in a mobile mode, but performance must rival desktops. This trend will only grow and will only drive up the minimum acceptable performance threshold for laptops.
I have tried using beam-it on my.mp3.com, and I like it. It makes listening to my CDs easy, no matter where I am. The legal stuff may be a bit murky. If I can make a cassette copy of CDs that I've bought, then this steaming format should probably be okay. Sure, I could go out and borrow my friends' CD and "beam" them, but at least I can't save the audio stream to a file (unless someone comes up with a hacked streaming player that will do this).
A few notes about beam-it. First, I had trouble getting beam-it to work from my work computer. My guess was that the firewall was causing problems. Second, at home, I couldn't get some CDs to be recognized, even after many attempts.
One question I had was what type of info beam-it is reading and transmitting. It appears to be sending back several kilobytes of data. I would guess that the CD's ID is the only thing that it should need. Maybe it needs to verify that the CD is authentic, and so maybe it reads certain parts of certain tracks that are then checksummed. But, that still wouldn't explain why the track data needs to be sent back to mp3.com. For the conspiracy theorists out there, maybe they are secretly gathering personal data off our PCs.
Slashdot Mirror
It should also be pointed out that while most buffer overflow exploits do indeed simultaneously overwrite the return address and inject the shellcode onto the stack, a certain class of buffer overflow exploits called return-into-libc attacks do not require executable stacks and are not too difficult to construct. These attacks overwrite the return address with the starting address for one of the libc exec*() functions. At the same time, the parameters for executing /bin/sh are pushed onto the stack. The execution of the corresponding return instruction then causes the exec*() function to execute /bin/sh. See this paper for a more detailed analysis of some buffer overflow solutions.
I think that it's interesting that in the past few weeks, several solutions for buffer overflows have been announced (e.g., the OpenBSD announcements). Each of these solutions are good solutions, but they heavily borrow from earlier solutions. Unfortunately, the previous work has often not been properly acknowledged. Since the masses are generally not aware of the current state of the art, these supposedly new solutions are given more credit than due. Still, I suppose it's a good thing if general awareness of the buffer overflow problem is raised, even if the pioneers of the technology do not receive their due credit.
Tim Tsai
Microsoft is not stupid. They realize that most people will not bother to do extra research in verifying claims. In this case, somewhat readily available information casts NT-based system availability guarantees in a inferior light. Some of the information is of the smack in your face type, like the Compaq page that shows a much better guarantee for Unix systems than for NT systems.
.999) than for NT. This is also true for HP (.9995 vs .999), although you have to do a search of the HP site to find the Unix availability guarantee.
.... This specifically excludes other causes of failures including, but not limited to, site disasters, operator errors, or failures of applications, ***operating systems***, or networks."
Yes, the Compaq site clearly shows that the availability guarantees for Unix are much higher (.9999 vs
Perhaps the Unisys guarantee is the most interesting. Microsoft implies that the use of NT on Unisys systems allows Unisys to guarantee availability. However, the fine print says "A system failure is defined as a hardware failure
Tim Tsai
ttsai@advanix.net
The cars-laptops analogy is interesting. However, the question is not necessarily pure speed vs. pure efficiency. To pursue the car analogy further, the Geo Metros and other ultra-efficient cars were not commercially successful because the same design that produced ultra-efficiency also caused the performance to drop below the acceptable threshold of most consumers. Rather than really small cars that could get 50mpg, consumers decided that 30-40mpg cars with more power were more desirable. It still remains to be seen whether Crusoe-based laptops will be in the Geo Metro class or the more successful Civic/Corolla class.
Another consideration is the growing trend of business laptop users using their laptops as their primary computer. Whereas in the past, laptops were used mostly for their mobility and more demanding tasks were executed on more powerful desktops, there is a growing shift to using a single laptop in a docking station. Such machines must not only be efficient in a mobile mode, but performance must rival desktops. This trend will only grow and will only drive up the minimum acceptable performance threshold for laptops.
I have tried using beam-it on my.mp3.com, and I like it. It makes listening to my CDs easy, no matter where I am. The legal stuff may be a bit murky. If I can make a cassette copy of CDs that I've bought, then this steaming format should probably be okay. Sure, I could go out and borrow my friends' CD and "beam" them, but at least I can't save the audio stream to a file (unless someone comes up with a hacked streaming player that will do this).
A few notes about beam-it. First, I had trouble getting beam-it to work from my work computer. My guess was that the firewall was causing problems. Second, at home, I couldn't get some CDs to be recognized, even after many attempts.
One question I had was what type of info beam-it is reading and transmitting. It appears to be sending back several kilobytes of data. I would guess that the CD's ID is the only thing that it should need. Maybe it needs to verify that the CD is authentic, and so maybe it reads certain parts of certain tracks that are then checksummed. But, that still wouldn't explain why the track data needs to be sent back to mp3.com. For the conspiracy theorists out there, maybe they are secretly gathering personal data off our PCs.
Tim