Linked by Amjith Ramanujam on Mon 11th Aug 2008 16:13 UTC, submitted by gonzo
Privacy, Security, Encryption Ars Technica has analyzed recently publicized Vista's security flaws. "Unfortunate, yes, but not as was reported in the immediate aftermath of the presentation evidence that Vista's security is useless, nor does this work constitute a major security issue. And it's not game over, either. Sensationalism sells, and there's no news like bad news, but sometimes particularly when covering security issues, it would be nice to see accuracy and level-headedness instead. ... Furthermore, these attacks are specifically on the buffer overflow protections; they do not circumvent the IE Protected Mode sandbox, nor Vista's (in)famous UAC restrictions."
Thread beginning with comment 326587
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Comment by Soulbender
by kerframil on Tue 12th Aug 2008 13:20 UTC in reply to "RE[2]: Comment by Soulbender"
kerframil
Member since:
2005-07-13

This is not a particularly well informed comment.

Firstly, building something with gcc does not guarantee a non-executable stack [1].

Secondly, heap and address space randomization was only introduced mainline as of 2.6.25 (released 17th April 2008) [2] and, in order to leverage fully, it requires a complete PIE userland - which almost all distros fail to provide (Hardened Gentoo being a noteworthy exception) [3].

Thirdly, the Linux kernel has supported the NX bit on x86 processors since 2004 (around the same time that XP SP2 was released which introduced its DEP implementation). Even then, it requires PAE OR HIGHMEM64 to be enabled - one wonders exactly how many stock distro kernels do this.

Further, based on the implementation in the kernel alone, if you do not have a hardware NX bit then you are out of luck. Besides which, the protection is really quite limited; the mainline kernel only provides a subset of the functionality provided by the Exec Shield project and, arguably, the protections offered by Exec Shield are arguably inferior to PaX (which is never going to go mainline) [4].

Fourthly, Win32 has defined a formal memory protection sheme and supported various memory protection attributes upon allocation of pages from the very beginning [5]. The only thing that has changed now is that the resultant policy is actually capable of being enforced on x86. The point is that the framework for allocating memory in the right way has always been there for application developers to use.

[1] http://www.gentoo.org/proj/en/hardened/gnu-stack.xml#doc_chap2
[2] http://kernelnewbies.org/Linux_2_6_25#head-fc71477174376b69ac7c3cd1...
[3] http://www.gentoo.org/proj/en/hardened/hardened-toolchain.xml
[4] http://en.wikipedia.org/wiki/PaX
[5] http://msdn.microsoft.com/en-us/library/aa366786(VS.85).aspx

Reply Parent Score: 5

RE[4]: Comment by Soulbender
by netpython on Tue 12th Aug 2008 13:48 in reply to "RE[3]: Comment by Soulbender"
netpython Member since:
2005-07-06

* Hardware based NX (No eXecute, also known as DEP) support is enabled for Stack and Heap since SUSE Linux Enterprise Server 9 on:
o all AMD64/EM64T processors.
o on x86 machines using the "bigsmp" kernel and the processor being able to support the NX bit."

There aren't a lot of CPU's these days that doesn't support hardware NX and 64-bit.

Reply Parent Score: 2

StaubSaugerNZ Member since:
2007-07-13

This is not a particularly well informed comment.

True. I don't disagree that you may know more than I about this, this is not my area of expertise. However, the parent stated that neither Linux nor Mac had memory protections. I know enough to see this is incorrect - so that fact you may know more than me doesn't make my point any less valid.

Why someone who knows more than I would not point these out makes their statements come across as insincere (especially coming from a Microsoft employee).


Firstly, building something with gcc does not guarantee a non-executable stack [1].

True. But has been possible for a while to make a non-executable stack with gcc. You are not forced to but any network facing application should do this. Keep this 'possible but not forced to' point in mind when I get to your last point.


Secondly, heap and address space randomization was only introduced mainline as of 2.6.25 (released 17th April 2008) [2] and, in order to leverage fully, it requires a complete PIE userland - which almost all distros fail to provide (Hardened Gentoo being a noteworthy exception) [3].

But some do. So choose your distro wisely. How hard is that is network security is your concern?


Thirdly, the Linux kernel has supported the NX bit on x86 processors since 2004 (around the same time that XP SP2 was released which introduced its DEP implementation). Even then, it requires PAE OR HIGHMEM64 to be enabled - one wonders exactly how many stock distro kernels do this.

Further, based on the implementation in the kernel alone, if you do not have a hardware NX bit then you are out of luck. Besides which, the protection is really quite limited; the mainline kernel only provides a subset of the functionality provided by the Exec Shield project and, arguably, the protections offered by Exec Shield are arguably inferior to PaX (which is never going to go mainline) [4].

Honest question: will Vista's NX protection work without NX being present in hardware?


Fourthly, Win32 has defined a formal memory protection sheme and supported various memory protection attributes upon allocation of pages from the very beginning [5]. The only thing that has changed now is that the resultant policy is actually capable of being enforced on x86. The point is that the framework for allocating memory in the right way has always been there for application developers to use.

See my response to the first point above. It similar to having capabilities in gcc but not being forced to use it. Since you argued that gcc's stack-protection wasn't any use because it wasn't mandatory it would then follow that the equivalent must be true for the Win32 memory protection scheme. Logical?

Vista's memory protection may be superior to Linux (or not, if the recent hyped news articles are to be believed). Fair enough, but to flat-out deny that Linux (and possibly Mac) has similar schemes is incorrect, yes?

Reply Parent Score: 3

RE[5]: Comment by Soulbender
by kerframil on Tue 12th Aug 2008 22:28 in reply to "RE[4]: Comment by Soulbender"
kerframil Member since:
2005-07-13

> However, the parent stated that neither Linux nor Mac had memory
> protections. I know enough to see this is incorrect - so that fact you
> may know more than me doesn't make my point any less valid.

In that case I apologise as I hadn't realised the context of your comment. The parent would be incorrect to say so (although I cannot speak for Mac OS X) and indeed, to counter that is absolutely valid.

The part I was really concerned about was the assertion that Linux had had address space randomization for a "long time" and the closing remark. This led me to believe that perhapse your view of the situation with Linux was somewhat rose-tinted ;)

For the record, the main reason for my response was to sound a cautionary note. Yes, there are some excellent hardening technologies - maybe even best-of-breed - that can be used in conjunction with Linux (see below). However, they are not mainstream and, where they are adopted by the well-known distros or in the mainline kernel itself, they seem to be implemented only partially or sub-optimally. That said, the situation is improving, albeit slowly.

> Honest question: will Vista's NX protection work without NX
> being present in hardware?

Well, sort of. The term DEP is a little misleading in this case as it does not offer the W^X memory protection that hardware-enforced DEP does. What it does do is to offer a form of stack protection via SAFESEH (Safe Structure Exception Handling). As I understand it, Microsoft's C++ compiler supports a /SAFESEH flag which, where the x86 architecture is concerned, instructs the linker to integrate a table of safe exception handlers into the header of the application binary. Of course, only applications that are built in this manner will benefit from this protection (which touches again on the interesting matter of some hardening technologies requiring co-operation over in userland). There is an interesting paper about it here:

http://www.nextgenss.com/papers/defeating-w2k3-stack-protection.pdf

Going back to the topic of W^X memory protection, note that both PaX and Exec Shield helpfully support the emulation of a NX bit in software on x86 so that, where a hardware NX bit is not available, there need be no impact on the level of security provided. PaX itself supports two different schemes, one of which entails a performance tradeoff (PAGEEXEC) and the other of which entails a memory tradeoff (SEGMEXEC). For anyone interested, there is an old-but-still-relevant article about it here:

http://www.pjvenda.org/linux/doc/pax-performance/

EDIT: changed "was incorrect" to "would be incorrect" so as to avoid any potential misunderstanding of what the aforementioned parent had intended to say

Edited 2008-08-12 22:44 UTC

Reply Parent Score: 1