3 ms·

This is a version of userland execve() for OS X so the plan is to run something new in the memory space of the process which was exploited. The technique prese

by brl 18y ago

This is a version of userland execve() for OS X so the plan is to run something new in the memory space of the process which was exploited. The technique presented consists of a bootstrapping 'Auto-loader' which receives an arbitrary Mach-O binary over the network and then 'executes' it in the same process space after evicting the previous tenant. Loading a executable directly from the network is an obvious application of userland exec but as far as I'm aware this is the first time somebody has published an implementation. Not an entirely new concept, but solid original research to make this happen on OS X. Check out the slides.

tptacek 18y ago
I read the slides, and while I get how this was tricky to pull off, I don't get how it's valuable. The reason implementations of techniques like this aren't already published is that there are easier ways to do a two-stage exploit on both OS X and Win32, without touching the filesystem.
- brl 18y ago
  There is an easier way to produce sophisticated second stage shellcode than simply writing it in C and compiling it? There are certainly more tedious ways to write shellcode such as hand crafting position independent assembly code like it's 1997. Also, there are some failed experiments like writing a crippled C --> shellcode compiler in Python, but I'm not aware of anything that is simpler and more general than userland exec. You write the loader once and you're good to go (at least until Ulrich Drepper breaks your loader by refactoring ld.so).
  - tptacek 18y ago
    Meh. You're probably right; being able to simply compile a Mach-O binary and load it over the network is more convenient than, say, proxying system calls or basic blocks like Mosdef.
    - brl 18y ago
      > proxying system calls Locally calculating what needs to be on the remote stack then transferring it all across the network to a tiny 'syscall server' is very nice conceptually but turns out to have huge flaws in practice. The commercial implementation of this idea which you might be thinking of was completely replaced years ago by an executable that still executes individual system calls, but it accepts an XDR marshalled RPC protocol instead of raw bytes to place on the stack. This executable is statically compiled (well it has no library dependencies to begin with) and installed into memory with a very crude implementation of userland exec :)
      - tptacek 18y ago
        Mosdef was never just raw system call stack frames, but if you ask me about commercial syscall proxies, I don't think of CORE Impact; I think about BMC/BladeLogic, which provides a "remoted cygwin"-style interface built on syscall proxying. Again, you're right that just being able to compile and run an oblivious application is nicer than having a good remoting implementation; however, most exploits just use remoting. (I'm actually prepared to concede that this is a big win, since you're closer to shellcode development than I am.)

by brl 18y ago

tptacek 18y ago

I read the slides, and while I get how this was tricky to pull off, I don't get how it's valuable. The reason implementations of techniques like this aren't already published is that there are easier ways to do a two-stage exploit on both OS X and Win32, without touching the filesystem.

brl 18y ago
There is an easier way to produce sophisticated second stage shellcode than simply writing it in C and compiling it? There are certainly more tedious ways to write shellcode such as hand crafting position independent assembly code like it's 1997. Also, there are some failed experiments like writing a crippled C --> shellcode compiler in Python, but I'm not aware of anything that is simpler and more general than userland exec. You write the loader once and you're good to go (at least until Ulrich Drepper breaks your loader by refactoring ld.so).
- tptacek 18y ago
  Meh. You're probably right; being able to simply compile a Mach-O binary and load it over the network is more convenient than, say, proxying system calls or basic blocks like Mosdef.
  - brl 18y ago
    > proxying system calls Locally calculating what needs to be on the remote stack then transferring it all across the network to a tiny 'syscall server' is very nice conceptually but turns out to have huge flaws in practice. The commercial implementation of this idea which you might be thinking of was completely replaced years ago by an executable that still executes individual system calls, but it accepts an XDR marshalled RPC protocol instead of raw bytes to place on the stack. This executable is statically compiled (well it has no library dependencies to begin with) and installed into memory with a very crude implementation of userland exec :)
    - tptacek 18y ago
      Mosdef was never just raw system call stack frames, but if you ask me about commercial syscall proxies, I don't think of CORE Impact; I think about BMC/BladeLogic, which provides a "remoted cygwin"-style interface built on syscall proxying. Again, you're right that just being able to compile and run an oblivious application is nicer than having a good remoting implementation; however, most exploits just use remoting. (I'm actually prepared to concede that this is a big win, since you're closer to shellcode development than I am.)