Stealthy Memory Injection Attack in Mac OSX | Hacker News Reader

Stealthy Memory Injection Attack in Mac OSX

dailytech.com

7 pointsjaydub9 comments

There is a much better article here (you can actually understand what he has done): http://www.oneitsecurity.it/22/01/2009/mac-os-x-vulnerabilit...

I haven't read the slides, so I can't say specifically what he's done, however this is nothing new [1]. Essentially, he has ported a known technique, for executing programs within a host address space, to the OS X platform. It is neither "new" nor an "attack", so the article is extremely misleading.

From the article it appears that he's implemented a framework for injecting code into another process on OSX. It sounds like he uses the original binary to either a) hook execution, or b) access dynamic libraries[2]. [The part about using addresses from the existing Mach-O binary isn't clear as to the purposed purpose].

This "attack" is actually more like a technique for running a binary without creating an on-disk image. For examples of why you'd want to do this see phrack [3].

[1] Userland Exec, 2004. http://seclists.org/fulldisclosure/2004/Jan/0001.html

[2] Cheating the ELF: Subversive dynamic linking on UNIX platforms, 2001. http://mirror.sweon.net/madchat/coding/Cheating_elf.pdf

[3] Remote Exec, 2005(?). http://www.phrack.com/issues.html?issue=62&id=8

So, if you already have a remote execution bug in OS X, you can execute code in other processes to hide yourself. This wasn't new when Back Orifice did it in the '90s. I'm also not sure why he's bothering mucking with Mach-O files, when you can just use the Mach task APIs to do the same thing directly.

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.

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.

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).

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.

> 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 :)

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.)

Details somewhat less exciting than headline:

"The main weakness of his attack is that it relies on an unspecified means of executing arbitrary code on the computer in the first place: according to Iozzo’s presentation (PDF), an attacker must have knowledge of remote code execution “in his pocket” in order to convince his mark’s computer run a bootstrapper that initiates the attack."

Reply on news.ycombinator.com