Windows 2003 vs Linux 2.6.x
Thursday 28th December, 2006 00:35 Comments: 0
I know, it's a little unfair to compare them, but a quick glance at Secunia's website currently reveals:
Microsoft Windows Server 2003 Enterprise Edition
Affected By 111 Secunia advisories
Unpatched 9% (10 of 111 Secunia advisories)
The most severe unpatched Secunia advisory affecting Microsoft Windows Server 2003 Enterprise Edition, with all vendor patches applied, is rated Less critical
Linux Kernel 2.6.x
Affected By 107 Secunia advisories
Unpatched 18% (19 of 107 Secunia advisories)
The most severe unpatched Secunia advisory affecting Linux Kernel 2.6.x, with all vendor patches applied, is rated Moderately critical
To be slightly fairer, at least when things are wrong with the Linux Kernel 2.6.x they're not usually as bad as Windows.
It seems Linux problems typically result in DoS, while Windows is more likely to have remote execution.
Mainline Linux since version 2.6.12 has included the Exec Shield code for address space layout randomization* (ASLR); I suspect with things like ASLR - and if people turned DEP on for everything, the default is just Windows and its services - Windows Vista will be a lot harder to get remote execution (although only for binaries which are linked to be ASLR enabled). ASLR is not a replacement for insecure code, but when used in conjunction with other technologies, it is a useful defence.
When you boot into Windows Vista, system code is loaded into different locations in memory. This helps defeat "return-to-libc" attacks, where exploit code attempts to call a system function, such as the socket() function in wsock32.dll to open a socket, or LoadLibrary in kernel32.dll to load wsock32.dll in the first place. The job of ASLR is to move these function entry points around in memory so they are in unpredictable locations. In the case of Windows Vista, a DLL or EXE could be loaded into any of 256 locations, which means an attacker has a 1/256 chance of getting the address right, which makes it a lot harder for exploits to work correctly.
What are the other layers of defence in Vista? There's "/GS", a compile-time option in Visual C++ (on by default) that adds stack-based buffer overrun detection. It also juggles around some of the function arguments and the function stack variable to make some classes of attack harder to pull off. Virtually all Windows Vista binaries are compiled with this, and it's now in its fourth iteration. When /GS is triggered, the application is terminated. This should make it very difficult to do anything with buffer overruns in Vista.
There's also "/SafeSEH" (which I won't go into, as it's quite boring) and Data Execution Protection (aka AMD's NX or Intel's XD). Data Execution Protection, often simply referred to as DEP in Windows, requires CPU as well as operating system support. Buffer overruns come into a vulnerable application as data, and then that data is executed. DEP can prevent the exploit working by marking data segments as no-execute so it can't be run. This means that even if the Vista binary wasn't compiled with "/GS" it should be stopped by DEP. When this happens, it immediately terminates the application, which is why I had trouble running World of Warcraft on Vista x64 when I changed it from the default setting to the non-default setting to check everything (I've had to add wow.exe as an exception), and the application would stop dead without any error messages appearing.
And, finally, there's "Function Pointer Obfuscation". Long-lived function pointers are targets for attack because they hang around for ages (hence "long lived") and they point to functions that are called at some point by the code (so you know they're going to be used at some point in the future). In Windows Vista, numerous long-lived pointers are encoded, and only un-encoded when the pointer is actually needed. This is also a bit boring to explain properly, I like to think of it as a clever magic trick where the card you picked is put back into the deck, shuffled around a bit, and then - when you ask for it - the chosen card is pulled back out to be revealed first time.
* I know, it's "randomisation" here in the UK, but I'm sticking with the American spelling for now as it's part of the popular acronym ASLR
Microsoft Windows Server 2003 Enterprise Edition
Affected By 111 Secunia advisories
Unpatched 9% (10 of 111 Secunia advisories)
The most severe unpatched Secunia advisory affecting Microsoft Windows Server 2003 Enterprise Edition, with all vendor patches applied, is rated Less critical
Linux Kernel 2.6.x
Affected By 107 Secunia advisories
Unpatched 18% (19 of 107 Secunia advisories)
The most severe unpatched Secunia advisory affecting Linux Kernel 2.6.x, with all vendor patches applied, is rated Moderately critical
To be slightly fairer, at least when things are wrong with the Linux Kernel 2.6.x they're not usually as bad as Windows.
It seems Linux problems typically result in DoS, while Windows is more likely to have remote execution.
Mainline Linux since version 2.6.12 has included the Exec Shield code for address space layout randomization* (ASLR); I suspect with things like ASLR - and if people turned DEP on for everything, the default is just Windows and its services - Windows Vista will be a lot harder to get remote execution (although only for binaries which are linked to be ASLR enabled). ASLR is not a replacement for insecure code, but when used in conjunction with other technologies, it is a useful defence.
When you boot into Windows Vista, system code is loaded into different locations in memory. This helps defeat "return-to-libc" attacks, where exploit code attempts to call a system function, such as the socket() function in wsock32.dll to open a socket, or LoadLibrary in kernel32.dll to load wsock32.dll in the first place. The job of ASLR is to move these function entry points around in memory so they are in unpredictable locations. In the case of Windows Vista, a DLL or EXE could be loaded into any of 256 locations, which means an attacker has a 1/256 chance of getting the address right, which makes it a lot harder for exploits to work correctly.
What are the other layers of defence in Vista? There's "/GS", a compile-time option in Visual C++ (on by default) that adds stack-based buffer overrun detection. It also juggles around some of the function arguments and the function stack variable to make some classes of attack harder to pull off. Virtually all Windows Vista binaries are compiled with this, and it's now in its fourth iteration. When /GS is triggered, the application is terminated. This should make it very difficult to do anything with buffer overruns in Vista.
There's also "/SafeSEH" (which I won't go into, as it's quite boring) and Data Execution Protection (aka AMD's NX or Intel's XD). Data Execution Protection, often simply referred to as DEP in Windows, requires CPU as well as operating system support. Buffer overruns come into a vulnerable application as data, and then that data is executed. DEP can prevent the exploit working by marking data segments as no-execute so it can't be run. This means that even if the Vista binary wasn't compiled with "/GS" it should be stopped by DEP. When this happens, it immediately terminates the application, which is why I had trouble running World of Warcraft on Vista x64 when I changed it from the default setting to the non-default setting to check everything (I've had to add wow.exe as an exception), and the application would stop dead without any error messages appearing.
And, finally, there's "Function Pointer Obfuscation". Long-lived function pointers are targets for attack because they hang around for ages (hence "long lived") and they point to functions that are called at some point by the code (so you know they're going to be used at some point in the future). In Windows Vista, numerous long-lived pointers are encoded, and only un-encoded when the pointer is actually needed. This is also a bit boring to explain properly, I like to think of it as a clever magic trick where the card you picked is put back into the deck, shuffled around a bit, and then - when you ask for it - the chosen card is pulled back out to be revealed first time.
* I know, it's "randomisation" here in the UK, but I'm sticking with the American spelling for now as it's part of the popular acronym ASLR