Freigeben über

Use of ASLR, NX, etc

  • Artikel

Found a really great post by David Maynor here. He points out that various counter-measures aren't always used by apps other than Windows. I would have commented directly to his blog, but didn't feel like signing up, so I'll make some comments here –

David Maynor said:

A good example of this is Apple. Their QuickTime application (part of iTunes) is installed on a lot of Windows computers, if not most. Yet, there is a new vulnerability discovered in QuickTime every couple months because the code is inherently insecure. The vulnerabilities allow attackers to break into Vista machines because Apple doesn't take advantage of Vista's security features.

It doesn't have to be that way. One of the most important Vista security features is "address space randomization" or "ASLR". […]

I wouldn't tend to phrase it quite that strongly myself, but what I've been told is the case is that Apple requires compiling with gcc. This is something that makes things more difficult for me, since gcc's support for templates isn't the best (about the same as Visual C++ 6), and SafeInt - despite being purely standards-compliant C++ and not platform-specific – won't compile. So what I suspect might be going on with QuickTime is that it gets compiled with gcc for all platforms, and I'm guessing that gcc won't set the ASLR bit. If my guess is right, it would be a Good Thing for someone to go add that.

[update] I've been informed that I'm wrong and that QuickTime is using the Visual Studio compiler, and should be flipping the ASLR bit in upcoming releases. My apologies.

Something else David said:

Turning on the ASLR flag in all products will undoubtedly cause (or expose) a few bugs, but most software will run just fine. There is no reason for software companies to continue to ignore this issue. Among the companies/products currently ignoring these features are: Mozilla's Firefox, Google's toolbar, Apple's iTunes, Adobe's PDF reader, Roxio's media creation tools, and Divx's player. Actually, we haven't found any company that turns on ASLR consistently.

We flipped the ASLR bit in Office 2007 very late in the development process, and we did this with great trepidation. Office has a lot of really complex code, and generally even a small change is going to have some side-effect. What we found broke was testing harnesses that had hard-coded app addresses. There was not a single break in Office itself. Anyone can flip the ASLR bit with very little fear of regressions. From our experience with a huge, varied code-base, I'd expect ASLR to cause bugs in extremely rare cases – unless it's an exploit.

Note that the same is not true of NX – this can take some work, depending on what your app does. If you have an ordinary app, it might not cause any problems. Something else to consider as you port to 64-bit is that you get NX enabled whether you like it or not, so you may as well figure out what needs to get fixed now. This is one reason I prefer running a 64-bit OS – some of the exploits aren't going to work until people start building x64 exploits.

He also said:

In the screenshot, we scanned the Microsoft Office subdirectory on a Vista machine. We find that while a lot of code supports ASLR, a lot of code doesn't. We likewise see that only some code supports the NX bit. We also see that Microsoft Office still uses dangerous functions like "strcpy". As it turns out, most of Microsoft Office is secure, but that code supporting legacy features (such as older file formats) is where it's insecure.

Anything we built in Office 2007 should have ASLR – if it doesn't have ASLR, then we likely purchased it from a 3rd party. In the future, we'll make sure ASLR, etc. are enabled for everything. I'd also point out that just because you see strcpy present doesn't always mean there's an exploit. Copying a fixed string into a fixed buffer is safe. We actually swept the code to remove these back in Office 2003. It's been noted that Vista has removed these and used SAL – what's less known is that we did this in Office 2003 and the low regression rate and positive results we got from it ended up in the SDL and Vista. Obviously, if David's finding these, some must have either been missed, or we decided that instance was safe. I'd like to reinforce one of his points – some of the code that supports older formats, especially formats we didn't produce, is scary stuff to try and go change, and we don't think it can easily be made as secure as either more modern code, or even older code that we wrote for our own formats. This is one of the reasons we've disabled some of these in Office 2007 and Office 2003 SP3. It's interesting to see a noted researcher come to the same conclusion.

I'm also going to make a counter-argument I think David might agree with – ASLR, NX and other techniques work as great safety devices to make flaws less likely to be an exploitable flaw, as opposed to an ordinary flaw. You should _never_ write code that assumes flaws are OK. Solid code tends to be secure code.

I'll try to post more later – been busy lately.

Comments

  • Anonymous
    March 14, 2008
    gcc does not currently support building x64 binaries targeting the Windows x64 platform. AFAIK, no compiler except for Visual Studio does support it. [dcl] Interesting - thanks!