3 ms·

Can somebody describe what this document is all about in simple words, for the average "high level" developer? Thanks in advance!

• amalcon 17y ago
  Basically, if you have any potential memory attacks in your software (buffer overflows, bad printf format strings, stack smashes, etc), an attacker can make your software do whatever he wants. He can do this without using a RET instruction (which is the more "standard" way of doing this, so people have been investigating looking for it as an active defense).
• tptacek 17y ago
  You've probably heard the term "buffer overflow". A buffer overflow is one example of a memory corruption flaw. In virtually all modern memory corruption exploits, the goal of the attacker is to corrupt a victim program in such a way that they can upload their own code into the victim and run it. For about 8 years (95-'03, the "summer of worms"), the bulk of all the work in stopping these attacks was directed at the broken code that allowed the vulnerabilities (for instance, the use of strcpy() and sprintf(), which are unbounded). The payoff for this work went asymptotic. Starting in the late '90s and really picking up in the '00s, research instead went into hardening runtimes to break exploits. For instance, you can't simply overwrite the activation record for a function to change the return address, because there's a random cookie there. The stack and heap aren't executable, and the text segment isn't writeable. The whole runtime is randomized, so you can't predict addresses. What papers like this (and, as Dave Aitel pointed out on Twitter, papers like John McDonalds from the 90s -- that guy is spooky) aim to show is that even if attackers can't literally upload x86 instructions into their targets, they can still take control of the process. That's because even simple real-world programs are very complex at the runtime level, and linked to very complex libraries. The CPU can be coerced into executing any of the instructions in those libraries --- or, indeed, any sequence of bytes comprising any fragment of those instructions. So, if you do some basic binary analysis on your target, you can craft a sequence of addresses in the target which, if executed in the right order, will have the same effect as any program you could write (it's "turing complete", but a more helpful way to think about it is that they're synthesizing a simple VM running out of fragments of code). As far as we know, it is very hard to stop these kinds of attacks. An attacker that can write 1-4 bytes to an arbitrary (or even restricted) address in memory can trick the CPU into looking at attacker-controlled memory (say, the 1024 character login name they just gave you), and once the CPU is looking at that memory, it starts running sequences of its own code against itself. This is systems programming, compiler theory, computer architecture, and computer security. If you're into serious practical CS, you're crazy if you don't consider security as a career. There are very few other jobs that will reliably expose you to so much CS (and even EE) at this level.