Vulnerabilities

Userland

WebKit 531 (Vita FW BEFORE 2.00)

There are two exploits used for WebKit prior to 2.00. One is a data leakage exploit CVE-2010-4577 using type confusion to treat a double as a string memory address and length. The other is a type confusion exploit CVE-2010-1807 on the parseFloat() function using a Nan as the arg.

WebKit 536 (Vita FW 2.00 thru 3.20) (CVE-2012-3748) (2013-09-03-1)

The heap memory buffer overflow vulnerability exists within the WebKit's JavaScriptCore JSArray::sort(...) method. This method accepts the user-defined JavaScript function and calls it from the native code to compare array items. If this compare function reduces array length, then the trailing array items will be written outside the "m_storage->m_vector[]" buffer, which leads to the heap memory corruption.

WebKit 537.73 (as used in Vita FW 3.30-3.36) (CVE-2014-1303)

The CSSSelectorList can be mutated after it's allocated. If the mutated list contains less entries than the original one, a restrictive 1-bit OOB write can be achieved.

WebKit 537.73 (as used in Vita FW 3.50-3.60) (unknown or no CVE)

The JSArray::sort method has a heap use-after-free vulnerability. If an array containing an object with a custom toString method is sorted, and the toString method causes the array to be reallocated, then the sorted elements will be written to the old freed address.

https://blog.xyz.is/2016/webkit-360.html

PSM Mono privilege escalation

https://yifan.lu/2015/06/21/hacking-the-ps-vita/

PSM Unity privilege escalation

UnityEngine.dll is a trusted assembly (SecurityCritical) and is not signed (can be modified). However, the actual file at ux0:app/PCSI00009/managed/UnityEngine.dll is PFS signed and encrypted, making this (and any) resource based hacks just as difficult as unsigned code execution hacks (which is the original goal).

PSM NetworkRequest privilege escalation

NetworkRequest.BeginGetResponse(AsyncCallback callback) invokes callback with SecurityCritical allowing for a privilege escalation. Unfortunately, Sony closed down the scoreboards feature which means that Network.AuthGetTicket() fails and Network.CreateRequest() cannot be invoked. There is no other way of creating a NetworkRequest object.

using System;
using System.Security;
using System.Runtime.InteropServices;
using Sce.PlayStation.Core.Services;

namespace NetHax
{
	public class AppMain
	{
		[SecurityCritical]
		public static void Escalate (IAsyncResult result)
		{
			Console.WriteLine("Should be SecurityCritical");
			IntPtr ptr = Marshal.AllocHGlobal(1000);
			Console.WriteLine("Look at me allocating memory: 0x{0:X}", ptr);
		}
		
		public static void Main (string[] args)
		{
			Network.Initialize("af1c0a1b-a7b8-4597-a022-eee91e6735d1");
			Network.AuthGetTicket();
			NetworkRequest req = Network.CreateRequest(NetworkRequestType.Get, "", "");
			IAsyncResult result = req.BeginGetResponse(new AsyncCallback(Escalate));
			while (!result.IsCompleted)
			{
				Console.WriteLine("waiting...");
			}
			Console.WriteLine("Completed!");
		}
	}
}

h-encore savedata exploit

To be disclosed by TheFloW.

Discovered on 2018-02-17. Released on 2018-06-29.

Exploitable in theory on any firmware (not patched yet).

h-encore userland ASLR bypass

To be disclosed by TheFloW.

Released on 2018-06-29.

Exploitable in theory on any firmware (not patched yet).

Kernel

Stack buffer overflow in sceSblDmac5EncDec

(2014-09-16)

might have found one
SceSblDmac5Mgr_sceSblDmac5EncDec
reads in 0x18 bytes from first arg
processes a little
then
ROM:005F711A                 MOV             R1, R11
ROM:005F711C                 ADD             R0, SP, #0x88+var_70
ROM:005F711E                 MOV.W           R2, R10,LSR#3
ROM:005F7122                 BLX             _import_SceSblSsMgr_SceSysmemForDriver_sceKernelMemcpyUserToKernel
R10 comes from orginal read in buffer+0x10
bad news is it got patched in 1.80
they also added a isShell check

Consensus: Confirmed exploitable before 1.80. YEAH!

sceIoDevctl does not clear stack buffer

(2014-11-24) Call some interesting functions that interest you in a kernel context (call some damn syscalls) Then call devctl and get upto 0x3FF bytes of that stack!

    sceIoDevctl("sdstor0:", 5, "xmc-lp-ign-userext", 0x14, WINDOW_BASE+0x10, 0x3FF);
    store(RET, WINDOW_BASE+0x4);

Fixed in 3.61.

Syscall handler doesn't check syscall number (integer overflow)

(2015-07-03) A large syscall number passed in R12 can overflow syscall table and cause an arbitrary function pointer to be dereferenced and executed.

This was patched in 1.61.

Heap use-after-free in sceNetSyscallIoctl

(2016-04-05) sceNetSyscallIoctl is declared as int sceNetSyscallIoctl(int s, unsigned flags, void *umem). When memsz = (flags_ >> 16) & 0x1FFF is in range (0x80; 0x1000], it will use SceNetPs custom malloc to allocate a buffer of that size on the heap. However, the second argument to malloc is 0, meaning that when not enough memory is available instead of returning NULL, it unlocks the global SceNetPs mutex and waits on a semaphore. Then, while malloc is waiting, another thread can free the socket sceNetSyscallIoctl is operating on, causing a use-after-free condition.

When passed proper arguments, sceNetSyscallIoctl will execute a function from the socket's vtable at the end:

      v13 = (*(int (__fastcall **)(int, signed int, unsigned int, char *))(*(_DWORD *)(socket + 24) + 28))(
              socket,
              11,
              flags_,
              mem_);

Fixed in 3.63.

3 kernel exploits on DevKit by TheFloW

2 still to be disclosed by TheFloW.

Patched on 3.68.

kernel stack leak in sceMotionDevGetEvaInfo

This can be used to defeat kernel ASLR on DevKit on FW < 3.68.

uint32_t get_sysmem_base() {
  uint32_t info[0x12];

  // 1) Call a function that writes sp to kernel stack
  sceAppMgrLoadExec(NULL, NULL, NULL);

  // 2) Leak kernel stack
  sceMotionDevGetEvaInfo(info);

  // 3) Get sysmem base
  uint32_t sysmem_addr = info[0] & 0xFFFFF000;
  
  return sysmem_addr;
}

SceNgs design flaws (h-encore kernel exploit)

Discovered on 2018-02-04 by TheFloW and successfully exploited four days later. Released on 2018-06-29 in h-encore 3.65-3.68.

Should be exploitable at least on 3.00 and up to 3.68. Fixed in 3.69.

Some functions in SceNgs take a kernel pointer (xor'ed with a known static value) from the user.

This can be used to partially defeat kASLR and also as an out-of-bounds exploit to get kernel execution.

Writeup and source code.

memcpy bugs (h-encore kernel exploit)

Discovered by TheFloW.

Should be exploitable on any firmware up to 3.69. Could even be vulnerable at other levels (TrustZone?, NS KBL?).

write-up

The 2 following bugs are exploited when using a negative length memcpy in order to use OOB without having a too big copied buffer nor triggering a segmentation fault.

memcpy integer overflow

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 later in the code 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.

memcpy length comparizon as signed integer

At some point in memcpy function, the length is compared as signed integer. Hence a negative length will simply bypass the copy loop.

Non-secure Boot Loader (NSBL)

Ensō

(2017-04-30) A logic flaw related to error code propagation in NSBL allows for a buffer overflow in the data section and early code execution on ARM in non-secure privileged mode.

It was patched in 3.67.

yifan's write-up

enso source code

Secure World (TrustZone)

SMC 0x12F does not validate arguments -> TrustZone level arbitrary code execution

(2017-01-01) SMC 0x12F (sceSblSmSchedGetStatusMonitorCall) takes two unchecked arguments: sm_handle and shared_mem_index.

sm_handle is a pointer to TrustZone memory in the form of (tz_addr >> 0x01) and shared_mem_index is an integer value calculated as ((shared_mem_blk_addr - shared_mem_base_addr) / 0x80).

By passing the right value as sm_handle, SMC 0x12F will read 0x08 bytes from (tz_addr + 0x28) and return them at (shared_mem_base_addr + index * 0x80) which translates to a TrustZone arbitrary memory leak (0x08 bytes only).

By passing the right value as shared_mem_index it is also possible to write the leaked data into an arbitrary TrustZone memory region. The Non-secure Kernel sees the shared memory region at 0x00400000 (size is 0x5000 bytes) and the Secure Kernel sees the exact same memory region at 0x00560000, thus making it possible to plant data inside the Non-secure Kernel's region and having the SMC copy this data somewhere into TrustZone memory (e.g.: SMC table).

This results in TrustZone level arbitrary code execution.

It was patched somewhere around after 1.80 before 2.10.

A 1.80 TrustZone modules imports/exports list is available there.

Example code exploiting this vulnerability:

void tz_memcpy_8(uintptr_t dst, const void *src)
{
	memcpy((void *)0x00400028, src, 8);

	uintptr_t sm_handle = 0x00560000 >> 1;
	uintptr_t shared_mem_index = (dst - 0x00560000) / 0x80;

	asm volatile(
		"mov r0, %0\n\t"
		"mov r1, %0\n\t"
		"mov r12, #0x12F\n\t"
		"smc #0\n\t"
		: : "r"(sm_handle), "r"(shared_mem_index) : "r12"
	);
}

Hardware

Crypto engine allows partial AES key overwrite

(2017-02-01) The Dmac5 crypto engine, accessible from the kernel, allows writing 4 bytes of key material at a time. This makes it possible to recover plaintext AES keys via bruteforce.

F00D Processor

octopus exploit

(2017-02-18) To be disclosed.

https://twitter.com/pomfpomfpomf3/status/832806488221446145

octopus exploit

                            .---.         ,,
                 ,,        /     \       ;,,'
                ;, ;      (  o  o )      ; ;
                  ;,';,,,  \  \/ /      ,; ;
               ,,,  ;,,,,;;,`   '-,;'''',,,'
              ;,, ;,, ,,,,   ,;  ,,,'';;,,;''';
                 ;,,,;    ~~'  '';,,''',,;''''  

(I copied the octopus from an ASCII art page: http://ascii.co.uk/art/octopus)

To be disclosed

(2017-02-23) To be disclosed.

Petite Mort

(2018-07-27) Because We Know Real French Words(TM)