During my presentation at this year Black Hat DC conference, I promised to show in the demo my attack applied to Safari. Unfortunately I forgot to patch a small bug in the code and wasn't able to show that part of the demo. This blog post serves for three key reasons:

• To explain the problem that was encountered during the demo
• To show my attack with Safari (finally)
• To explain some misunderstanding on the technique

I won't describe the whole attack again in this blog post, so if you're interested in more than the video please read the code and the slides or the white paper.

The problem with the code was related to the fact that Safari is a huge application; for that reason its __TEXT segment overlapped with the location of the buffer used to store the injected binary. Solving this problem is as easy as specifying a large (eg 0x10000000) address to the mmap() syscall, that way the buffer containing the binary will not be overwritten while loading its segments. In fact mmap() let you specify a desidered virtual address as the starting address of the mapped buffer. What can happen is:

• That address is free, so the buffer will be mapped there
• That address is not free, so the buffer will be mapped to a different location (if we are lucky to a further(?) one)

So the question is what value we want to specify as starting address, this highly depends on the size of the binary that we want to inject; the general rule is "large enough". The mapping of the binary is done by the first stage shellcode(jumper.c file), the code on the website is already patched.

Now we can go on and speak a bit about the demo. I will run the first stage shellcode which will receive the injected binary and executed it(in our case Safari). Having done this I'll be showing two outputs of wireshark and vmmap; the former to inspect the network packet dump and the latter to take a look at the memory layout before and after the execution of the attack.

It's time for some final considerations about the attack and its usefulness. I didn't show the demo with a vulnerable program but with a fake one and I know this created some frustration. Anyway my technique was never meant to be a mass-ownage tool, it is more like a sophisticated payload (something similar to Meterpreter for Windows). Therefore neither his current usage nor his ability to own a machine need to be taken into account while judging it. The former because not using it in the wild doesn't mean that it has no utility and the latter because, once again, it has no "exploiting" capabilities. What the technique should be used for is to highten the level of the exploitation process(ie inject high-level languages payloads, in-memory rootkits) and to help in ruining forensics evidences.

I'd like to thank the Black Hat staff for giving me the opportunity to write to this page.

You can see the new demo video here.