Understanding JIT spray | Hacker News Reader

Understanding JIT spray

blog.cdleary.com

112 pointsmbrubeck9 comments

Great article! Chris Rohlf and myself gave a talk on attacking JIT engines at BlackHat earlier this year[1]. We covered JIT sprays and mitigating against them fairly thoroughly (not this thoroughly, but our goals were a bit different :)).

Check it out if you're into this.

[1] http://www.matasano.com/research/jit/

The section on staged shellcode payloads reminded me of bombers, replicators, and scanners in corewars (http://en.wikipedia.org/wiki/Core_War#Strategy)

Excellent article. Looking forward to the next one!

RISC processors with fixed instruction sizes and enforced 4-byte instruction alignment, are looking even saner than they did before I read this.

You think RISC sounds like a good idea now.. wait until you read about "return-oriented programming" with variable length instructions!

http://cseweb.ucsd.edu/~hovav/talks/blackhat08.html

The short story: arbitrary computation by finding 'ret's wit short sequences of useful code before them. Finding them in your code, and they need not actually be 'ret's thanks for the same reason this stuff works.

ROP does not need a variable-length instruction set. ROP is a common exploitation method for iDevices...

Correct, it just makes it a hell of a lot more wicked.

Or runtime environments that enforce some of these constraints on binaries for variable-length-instruction architectures [1] :)

Variable-length instructions, when done right, closely approximate Huffman coding your binary, so you can get big code size wins, but there are definitely hardware/system software complexity and security disadvantages to be aware of. An intermediate point between, say, MIPS and x86, is something like ARM's Thumb, where you have one set of small instructions for your most common operations, and you can distinguish between the two in hardware without much hassle.

[1] http://code.google.com/p/nativeclient/

Agreed -- you can get large code size wins. This would require actively managing the instruction set so that the most common instructions are shortest. In theory, this could be done.

However, this doesn't work for a legacy architecture like x86, because many of the short opcodes are no longer the commonly used ones. Some are even actively deprecated. So overall, ARM wins in code size. I'm not sure about x86/64, maybe it is better there...

Reply on news.ycombinator.com