4
edits
Changes
Jump to navigation
Jump to search
Line 1:
Line 1: − + − + − + − + − + − + Line 22:
Line 22: − + + + + + + + + + + + + + + + + − === ioctlvhax - ioctlv TOCTOU ===+ − Line 35:
Line 49: + + + + − === 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.+ + + + +
no edit summary
==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].
'''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.
==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.