4
edits
Changes
no edit summary
Line 1:
Line 1:
+=== ioctlvhax - ioctlv TOCTOU ===+=== IOS_CreateThread unchecked memset ===+This system call will fill the stack of the newly created thread with a predefined constant (0xFA5A5A5A) without validating the passed stack address.+
==PPC userspace exploits==
==PPC userspace exploits==
===RenderArena use-after-free===
===RenderArena use-after-free===
−'''Application''': [[Internet Browser]]
+'''Present in system versions''': 2.0.0-5.1.0
−'''Present in system versions''': 2.0.0-5.1.0
+'''Publicly exploited''': Yes (libwiiu)
−'''Public in libwiiu''': Yes
+'''Discovered by''': libwiiu team (Marionumber1, TheKit, Hykem, Relys and Mathew_Wi)
An iframe is removed from its parent in a beforeload event and freed, but accessed for a vtable call later. Using Javascript, a vtable pointer is sprayed, occupying the frame's previous memory. A forged vtable referred to by the pointer is also sprayed. When WebKit attempts the virtual call, it goes to the forged vtable, which starts a ROP chain. More information [https://code.google.com/p/chromium/issues/detail?id=226696 here].
An iframe is removed from its parent in a beforeload event and freed, but accessed for a vtable call later. Using Javascript, a vtable pointer is sprayed, occupying the frame's previous memory. A forged vtable referred to by the pointer is also sprayed. When WebKit attempts the virtual call, it goes to the forged vtable, which starts a ROP chain. More information [https://code.google.com/p/chromium/issues/detail?id=226696 here].
===JSStringJoiner heap overflow===
===JSStringJoiner heap overflow===
−'''Application''': [[Internet Browser]]
+'''Present in system versions''': 5.1.1-5.3.2 (possibly older versions, too)
−'''Present in system versions''': 5.1.1-5.3.1 (possibly older versions, too)
+'''Publicly exploited''': Yes (libwiiu, 5.3.2 only)
−'''Publicly exploited in: ''': libwiiu (5.3.2 only)
+'''Discovered by''': libwiiu team (Marionumber1, Hykem and Mathew_Wi)
When joining an array of strings, the lengths of the strings are summed to calculate the needed storage space. This summation is vulnerable to an integer overflow, which enables a heap overflow. As a result, a sprayed value from Javascript ends up as a vtable pointer, which can be used with a forged vtable to start a ROP chain. More information [http://googleprojectzero.blogspot.com/2014/07/pwn4fun-spring-2014-safari-part-i_24.html here].
When joining an array of strings, the lengths of the strings are summed to calculate the needed storage space. This summation is vulnerable to an integer overflow, which enables a heap overflow. As a result, a sprayed value from Javascript ends up as a vtable pointer, which can be used with a forged vtable to start a ROP chain. More information [http://googleprojectzero.blogspot.com/2014/07/pwn4fun-spring-2014-safari-part-i_24.html here].
Line 22:
Line 22:
'''Present in system versions''': 2.0.0-5.4.0
'''Present in system versions''': 2.0.0-5.4.0
−'''Publicly exploited in: ''': libwiiu
+'''Publicly exploited''': Yes (libwiiu)
+'''Discovered by''': libwiiu team (Marionumber1, TheKit, Hykem, comex, Relys and Mathew_Wi)
The Cafe OS kernel implements a structure called an OSDriver, which can hold a 0x1000-byte cross-process data area. Accessing this data area is done through the CopyToSaveArea() and CopyFromSaveArea() [[Cafe OS Syscalls|syscalls]]. However, no lock on the OSDriver is held during the copy, allowing the save area to be freed and reallocated while the copy is taking place. With all 3 PPC cores, it is possible to copy over an OSDriver structure, and create a save area that points at the syscall table, giving PPC user mode code access to it. More information [http://gbatemp.net/threads/osdriver-kernel-exploit-a-technical-description.395444/ here].
The Cafe OS kernel implements a structure called an OSDriver, which can hold a 0x1000-byte cross-process data area. Accessing this data area is done through the CopyToSaveArea() and CopyFromSaveArea() [[Cafe OS Syscalls|syscalls]]. However, no lock on the OSDriver is held during the copy, allowing the save area to be freed and reallocated while the copy is taking place. With all 3 PPC cores, it is possible to copy over an OSDriver structure, and create a save area that points at the syscall table, giving PPC user mode code access to it. More information [http://gbatemp.net/threads/osdriver-kernel-exploit-a-technical-description.395444/ here].
+
+===GX2 unchecked memory read/write===
+'''Present in system versions''': 2.0.0-5.5.1
+
+'''Publicly exploited''': Yes (libwiiu)
+
+'''Discovered by''': libwiiu team (Marionumber1, Hykem and Mathew_Wi)
+
+The Wii U GPU (the GX2) has direct access to RAM for various operations. Using raw GPU commands it is possible to read/write memory in the PPC kernel heap, which is not blocked from GPU access. By redirecting the "next pointer" in the kernel heap into userspace it becomes possible to create a new OSDriver structure in userpsace and set it's save area to the kernel syscall table. From that point on, the OSDriver race attack can be reused.
==IOSU module exploits==
==IOSU module exploits==
+===ioctlv TOCTOU (ioctlvhax)===
+'''Present in system versions''': 1.0.0-5.2.0
+
+'''Publicly exploited''': Yes
−'''Discovered by''': naehrwert and plutoo
−'''Present in system versions''': ???-5.2.0
This flaw technically is in the kernel, but it can be used to exploit a usermode module.
This flaw technically is in the kernel, but it can be used to exploit a usermode module.
Line 35:
Line 49:
==IOSU kernel exploits==
==IOSU kernel exploits==
+===IOS_CreateThread unchecked memset===
+'''Present in system versions''': 1.0.0-5.5.1
+
+'''Publicly exploited''': No
−'''Discovered by''': naehrwert, Hykem (independently)
−'''Present in system versions''': ???-latest
−The IOS_CreateThread system call fills the stack of a newly created thread without validating the passed stack address.
+In older firmware versions (pre 5.x.x) this memset was done using a null constant (0x00000000). Considering that every IOSU module can call this system call, compromising the IOSU userspace and calling IOS_CreateThread allowed to arbitrarily patch the IOSU kernel with NOP instructions (0x00000000 is interpreted as NOP in ARM) and, therefore, build a NOP sled in the IOSU kernel.
+In recent firmware versions (5.x.x) a constant was added to the unchecked memset (0xFA5A5A5A), sucessfully rendering it useless.
+However, if a new thread is created as "detached" (detached state set to true), the top 0x24 bytes of the thread's stack are memset back to null.
+By creating several new detached threads and aligning their stacks carefully, it becomes possible to build a NOP sled again.