|Security Now! podcast
||[Feb. 4th, 2007|02:19 am]
I happened to listen to a few episodes of the
Security Now podcast, by Leo Laporte and Steve Gibson. It's mostly Windows stuff, hence uninteresting technically, but it's an eye opener nevertheless. And not in the positive sense. They, well Steve, often makes clueless comments about non-Windows OSes in hos attempt to give every OS its fair share. But this of course backfires when the comments are wrong or misleading.
But the worst thing I came across so far is in episode 71, called "Securable". That's a program of Steve's and of no relevance. But he tried to explain the NX feature of modern x86/x86-64 processors and this is what he said (see the transcript):
[...] what this does is essentially it allows the system to stop virtually all buffer overruns. And that’s big. I mean, all the security problems that we encounter with incredibly small exception are buffer overrun attacks. [...]
This is really what he thinks, he repeats it with different words later on in the show.
It seems for him
buffer overflow is synonymous with
inject code through a writing over buffer boundaries and then execute that code in place. Everybody who deals with security will laugh about such a definition. These are the first generation buffer flows which were exploited. At least on platforms which are secure. In Linux we have for the longest time means to protect against these kinds of attacks, starting from address space randomization to NX emulation. This does not in any way stop buffer overflows from being a problem.
Buffer overflows still can be used to redirect program execution. Overwriting return addresses for return-to-libc exploits (so other libraries), overwriting function pointers elsewhere, overwriting local variables and changing the direction of execution at branch points. The list goes on. These kinds of effects of buffer overruns are not detected by NX.
There are two ways I can interpret Steve's comments:
- On Windows, because it is such a soft target, attackers didn't have to bother with more sophisticated attacks and they really didn't happen. In this situation the attackers will simply adapt and use the attack vectors I described above.
- Steve doesn't know what he's talking about and he's doing his listeners a disservice by suggesting they are almost completely safe just because they enable NX.
For Steve's sake, and Leo's since he would be guilt by association, let's go with the first possibility. But all this means that Windows is years, many years, behind the Unix world when it comes to security. It might be a rude awakening for some people to find that the new features do not cure all problems.
Yes, MSFT has copied us on many levels and also implement things like address space randomization and stack canaries. This will help but only if the features are enabled. And this is the second eye opener from the show. Windows has apparently no fine grained control. This means at the slightest sign of problems the features will be turned off completely. They mentioned the BIOS and OS control of the NX bit. Since drivers and many applications are badly written the machines run with the feature turned off. One point for an easy sysadmin interface, but -100 points for security.
I think everybody who hopes that with the (slow) proliferation of MSFT's new OS release the Internet will be more secure is gravely mistaken. There are still not enough security features in place and those which are in place will be turned off. Heck, or they are not even implemented. Apparently several of the security features are not implemented in the 32-bit version to maintain compatibility.
This is very, very wrong. But it's been MSFT's goal, don't piss of the customer even if it's technically wrong and it causes huge problems for everybody. I'm a strong advocate of security over backward compatibility if there is a good reason. But usually it does not come to this because you can strengthen security without compromising backward compatibility. Case in point: see how we implemented non-executable stacks. Old programs continue to run while almost all new code automatically gets protected. And the case with, automatically again, get flagged as requiring an executable stack got fixed. It is one of Red Hat's release requirements that no binaries needs stack execution permission.
One last thing: it's really amusing to see that x86-64 pick-up (I mean real 64-bit code) is so slow on Windows. For the last 3 years I haven't been using any 32-bit machine except my laptop. This is no isolated case in the Linux world, we are well on the way to make 32-bit obsolete.