
Stealthy Memory Injection Attack in Mac OSX - jaydub
http://www.dailytech.com/Hacker+Unveils+Stealthy+Memory+Injection+Attack+in+Mac+OSX/article14340.htm
======
fuzzbang
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...](http://www.oneitsecurity.it/22/01/2009/mac-os-x-
vulnerability-an-interview-with-vincenzo-iozzo/)

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](http://www.phrack.com/issues.html?issue=62&id=8)

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

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

------
CalmQuiet
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."

