After some tests, we discovered that when the smbd process is started by the lauchd daemon, exploiting this vulnerability using the size() pointer in initial_malloc_zones may cause a unexpected behavior. The lauchd daemon starts a smbd process only at the first brute force interaction, and does not start any new smbd processes at subsequent iterations, causing exploitation to fail.
However, we found a reliable way to exploit this vulnerability even if the smbd process is started by the launchd daemon.
Initially, we need to use another pointer in initial_malloc_zones structure, but before just using another pointer, care must be taken because pointers in initial_malloc_zones that are called before the one we will use, can be trashed by the szone_free() function, causing the program to crash before we gain control of execution.
To avoid a crash, we use the free() pointer and let the szone_free() to trash the calloc() or valloc() pointers, which are not called before free() after the overflow.
However, we need to find another nop block that not only results in a nop-like instruction at our target address, but also do a near jump over the pointer written four or eight bytes past our target address, or move a valid value to the ecx register, which in free()context does not point to a valid memory location (it is zero). After some calculations, we discovered that a nop block of 0x16 and the address 0x1800014 satisfies all these conditions.
0x357b ^ ( 0x1800014 ^ 0x16161616 ) = 17962379
Implied that we use the second mov instruction, it will result in the following instruction block being executed as the first few bytes of our target address.
0: 79 23 jns 0x25 2: 96 xchgl %eax,%esi 3: 17 popl %ss 4: 16 pushl %ss 5: 16 pushl %ss 6: 16 pushl %ss 7: 16 pushl %ss 8: 14 00 adcb $0x0,%al a: 80 01 16 addb $0x16,(%ecx) d: 16 pushl %ss e: 16 pushl %ss f: 16 pushl %ss
The jump condition is always true because the sign flag is zero at the time our target address is executed. When executed, this will jump over the address written eight bytes past our buffer, hitting directly the nop block, which will be executed until it reaches the payload appended to it.
We also recently released an exploit module for this vulnerabilty in Solaris x86 and SPARC, you can download all these modules from the exploits section, or checkout the trunk of Metasploit Framework 3.