The NX Bit And ASLR
Alan: When the NX bit was first introduced, it was supposed to dramatically reduce the amount of malware. Suppose the Alan Dang Web browser had a bug in the code that parses the URL. If I had a Web address that was too long, it’ll end up copying that data into the memory that’s beyond the space allocated for data. The machine will execute that code and now it’s compromised. My understanding is that the NX bit prevents that from happening. But it seems as if the developers of malware simply transitioned to other methods of exploiting a system. Nowadays, the buzzwords are 64-bit ASLR, code signing for kernel extensions, or sandboxing? How much of this will help?
Charlie: The NX bit is very powerful.When used properly, it ensures that user-supplied code cannot be executed in the process during exploitation. Researchers (and hackers) have struggled with ways around this protection. ASLR is also very tough to defeat. This is the way the process randomizes the location of code in a process. Between these two hurdles, no one knows how to execute arbitrary code in Firefox or IE 8 in Vista right now. For the record, Leopard has neither of these features, at least implemented effectively. In the exploit I won Pwn2Own with, I knew right where my shellcode was located and I knew it would execute on the heap for me.
Alan: And just so that our readers know, ASLR is implemented in Windows Vista (but not XP) and Vista SP1 is required for the full ASLR. Leopard had some binaries placed randomly, but Snow Leopard is rumored to introduce full ASLR. On Linux, kernel 2.6.12 has a weak form of ASLR like Leopard does, but PaX and ExecShield will implement Windows Vista-like ASLR.
I know you can't talk about this year's Mac exploit, but let's talk about last year's Safari flaw. To win, you were able to remotely execute code on the MacBook Air. I would imagine that a malicious hacker would have then directly installed malware without triggering the confirmation for root access, etc?
Charlie: In neither case did I get root/admin access. That would have required additional vulnerabilities. However, just running as the user is still very bad. I could have still watched keystrokes as you went to an online bank, read your calendar and address book, sent emails, etc. In real life, one or all of these things would have occurred.
Alan: In hindsight, was there anything that could have been done on the user end? That is, if you had outgoing firewalls, anti-spyware/anti-malware software, weren't logged in as a root user, would that have done anything to limit the extent of the breach?
Charlie: None of those protections would have probably worked, or at least there were potential workarounds. The best thing the user could have done is not click on the malicious link. Of course, in some cases such as a man-in-the-middle attack, even this wouldn't have helped.
