As discussed previously, iTunes has certain anti-debugging features built into it.
Namely, it is not possible to attach or trace to the process using GDB or DTrace.
Observe what happens if you try to attach to iTunes using GDB:
(gdb) attach 1149
Attaching to process 1149.
Segmentation fault
This is because iTunes issues the ptrace PT_DENY_ATTACH request when it starts up and at other times within its lifetime. The man page for ptrace explains:
PT_DENY_ATTACH
This request is the other operation used by the traced process; it allows a process that is not currently being traced to deny future traces by its parent. All other arguments are ignored. If the process is currently being traced, it will exit with the exit status of ENOTSUP; otherwise, it sets a fl ag that denies future traces.
An attempt by the parent to trace a process which has set this fl ag will result in a segmentation violation in the parent.
Trying to attach to iTunes with GDB (or any ptrace-like debugger) causes it to die with a segmentation violation—how rude! Trying to run a DTrace script against iTunes doesn’t crash, but doesn’t actually turn on the probes.
From DTrace’s perspective, absolutely nothing is happening within iTunes!
Presumably, this anti-debugging feature is to protect Apple’s DRM.
This mechanism is enforced in the kernel. Checking out the XNU source code reveals the magic. You see in the fi le bsd/kern/mach_process.c the following code for the ptrace system call.
if (uap->req == PT_DENY_ATTACH) { proc_lock(p);
if (ISSET(p->p_lflag, P_LTRACED)) { proc_unlock(p);
exit1(p, W_EXITCODE(ENOTSUP, 0), retval);
/* drop funnel before we return */
thread_exception_return();
/* NOTREACHED */
}
SET(p->p_lflag, P_LNOATTACH);
proc_unlock(p);
return(0);
}
95363c04.indd 108
95363c04.indd 108 1/25/09 4:40:47 PM1/25/09 4:40:47 PM
Chapter 4 ■ Tracing and Debugging 109 When a process issues the PT_DENY_ATTACH request, it exits if it is
cur-rently being traced; otherwise it sets the P_LNOATTACH fl ag for the process.
Later in the same function, if a process tries to attach to a process with the P_LNOATTACH fl ag set, it segfaults.
if (uap->req == PT_ATTACH) {
…
if (ISSET(t->p_lflag, P_LNOATTACH)) { psignal(p, SIGSEGV);
}
As for DTrace, the bsd/dev/dtrace/dtrace.c fi le shows what happens.
#if defined(__APPLE__)
if (ISSET(current_proc()->p_lflag, P_LNOATTACH)) { continue;
}
#endif /* __APPLE__ */
This comes from the dtrace_probe() function that the provider calls to fi re a probe. If the process has set the P_LNOATTACH flag, DTrace doesn’t do anything.
Luckily, this mechanism is easily circumvented. In Chapter 12, “Rootkits,”
we’ll show you a method which could be used to defeat it using kernel modules.
For now we can use GDB manually. The basic idea is to ensure that iTunes never (successfully) calls ptrace() with the PT_DENY_ATTACH request. We’ll inter-cept this function call in the debugger and make sure that when the parameter PT_DENY_ATTACH is passed; the function doesn’t do anything. To accomplish this goal, make sure iTunes isn’t running, start up GDB, and set a conditional breakpoint at ptrace(). (Really, this is overkill, because iTunes has no business calling ptrace(), but better safe than sorry.) Then, when it hits, have GDB make the function return without actually executing. Place these commands in a GDB init fi le.
You simply set a breakpoint at ptrace, and when it is hit you tell GDB to return to the previous function in the call chain, thus not executing the ptrace code.
After starting iTunes, you can safely detach from the process and debug/trace to your heart’s content.
$ gdb /Applications/iTunes.app/Contents/MacOS/iTunes
GNU gdb 6.3.50-20050815 (Apple version gdb-768) (Tue Oct 2 04:07:49 UTC 2007)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show warranty” for details.
This GDB was configured as
“i386-apple-darwin”…/Users/cmiller/.gdbinit:2: Error in sourced command file:
No symbol table is loaded. Use the “file” command.
Reading symbols for shared libraries ... done (gdb) source itunes.gdb
Breakpoint 1 at 0xf493b24 (gdb) run
Starting program: /Applications/iTunes.app/Contents/MacOS/iTunes Reading symbols for shared libraries
+++++++++++++++++++++++...
... done Breakpoint 1 at 0x960ebb24
Breakpoint 1, 0x960ebb24 in ptrace ()
Reading symbols for shared libraries .. done Reading symbols for shared libraries . done Reading symbols for shared libraries . done
…
Notice how the breakpoint is hit early in the processes lifetime. You now have a running iTunes and it doesn’t have the evil P_LNOTRACE fl ag set. This means you can attach to it again at your leisure.
$ gdb -p 3757
GNU gdb 6.3.50-20050815 (Apple version gdb-768) (Tue Oct 2 04:07:49 UTC 2007)
95363c04.indd 110
95363c04.indd 110 1/25/09 4:40:47 PM1/25/09 4:40:47 PM
Chapter 4 ■ Tracing and Debugging 111
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show warranty” for details.
This GDB was configured as
“i386-apple-darwin”./Users/cmiller/.gdbinit:2: Error in sourced command file:
No symbol table is loaded. Use the “file” command.
/Users/cmiller/Desktop/3757: No such file or directory.
Attaching to process 3757.
Reading symbols for shared libraries . done Reading symbols for shared libraries
...
...
done
0x967359e6 in mach_msg_trap () (gdb)
DTrace works as well now, as apparently iTunes is displaying an episode of Chuck from Season 1:
$ sudo dtrace -qs filemon.d 3757
open(/dev/autofs_nowait) = 20 open(/System/Library/Keyboard
Layouts/AppleKeyboardLayouts.bundle/Contents/Info.plist) = 21 close(21)
Order is restored to the universe.
Conclusion
Before diving in to learn about exploitation techniques, it is important to know how to dig into the internals of applications. We discussed GDB and ptrace on Mac OS X and how it differs from more-common implementations. We then
95363c04.indd 111
95363c04.indd 111 1/25/09 4:40:47 PM1/25/09 4:40:47 PM
talked about the DTrace mechanism built into the kernel. DTrace allows kernel-level runtime application tracing. We wrote several small D programs that per-formed some useful functions for a security researcher, such as monitoring fi le usage, system calls, and memory allocations. The next topic was the Mac OS X port of PyDbg. This allowed us to write several Python scripts that performed debugging functions. The scripts included such things as searching memory and in-memory fuzzing. We also showed how Pai Mei could be used to help reverse-engineer a binary. Finally we discussed and showed how to circumvent Leopard’s attempt at anti-debugging.
References
http://landonf.bikemonkey.org/code/macosx/Leopard_PT_DENY_
ATTACH.20080122.html
http://www.phrack.com/issues.html?issue=63&id=5 http://steike.com/code/debugging-itunes-with-gdb/
http://www.sun.com/bigadmin/content/dtrace/
http://www.mactech.com/articles/mactech/Vol.23/23.11/
ExploringLeopardwithDTrace/index.html
http://dlc.sun.com/pdf/817-6223/817-6223.pdf
http://www.blackhat.com/presentations/bh-dc-08/Beauchamp-Weston/Whitepaper/bh-dc-08-beauchamp-weston-WP.pdf
https://www.blackhat.com/presentations/bh-usa-07/Miller/
Whitepaper/bh-usa-07-miller-WP.pdf
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3944 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1026
95363c04.indd 112
95363c04.indd 112 1/25/09 4:40:47 PM1/25/09 4:40:47 PM
113 In the process of exploitation, vulnerabilities are what everything else builds upon. You can’t have an exploit without an underlying bug. In this case, a bug is an error in the functioning of a program, and a vulnerability is a bug that has security implications. The reliability and robustness of an exploit depends greatly on the qualities of the vulnerability that it takes advantage of. You can’t install a rootkit without fi rst running an exploit. So every aspect of taking over a computer begins with a bug. If software were perfect, security researchers would all be out of a job. Luckily, it isn’t, and Apple’s code is no exception. In this chapter we look at some basic approaches to fi nding bugs in Leopard. Many of these tech-niques are general-purpose and would be valid for any piece of software; some are specifi c to the intricacies of Apple. Since Mac OS X contains both open- and closed-source components, we present approaches for fi nding vulnerabilities in source code and in binaries for which we don’t have the source code. In addi-tion, we present some clever ways of taking advantage of the open-source public development process used by Apple to identify vulnerabilities in Leopard.