3DS System Flaws: Difference between revisions
No edit summary |
|||
| Line 470: | Line 470: | ||
derrek's original 32c3 presentation for memchunkhax2 commented that a GPU-based attack was possible, but would be difficult. However, memchunkhax2.1 showed that it was possible to do fairly reliably. | derrek's original 32c3 presentation for memchunkhax2 commented that a GPU-based attack was possible, but would be difficult. However, memchunkhax2.1 showed that it was possible to do fairly reliably. | ||
| ARM11 kernel code execution | | ARM11 kernel code execution | ||
| | | [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA. | ||
| [[ | | [[11.0.0-33|11.0.0-X]] | ||
| | | | ||
| derrek, aliaspider | | derrek, aliaspider | ||
|- | |- | ||
| memchunkhax2 | | memchunkhax2 | ||
| | | When allocating a block of memory, the "next" pointer of the [[Memory_Management#MemoryBlockHeader|memchunkhdr]] is accessed without being checked after being mapped to userland. | ||
This allows a race condition, where the process can change the next pointer just before it's accessed. By pointing the next pointer to a crafted memchunckhdr in the kernel SlabHeap, some of the SlabHeap is allocated to the calling process, allowing to change vtables of kernel objects. | |||
| ARM11 kernel code execution | | ARM11 kernel code execution | ||
| [[10.4.0-29|10.4.0-X]] (partially) | | [[10.4.0-29|10.4.0-X]] (partially, see memchunkhax2.1) | ||
| [[10.4.0-29|10.4.0-X]] | | [[10.4.0-29|10.4.0-X]] | ||
| | | | ||