Changes

148 bytes added ,  22:31, 10 December 2014
no edit summary
Line 42: Line 42:  
!  Summary
 
!  Summary
 
!  Description
 
!  Description
 +
!  Successful exploitation result
 
!  Fixed in system version
 
!  Fixed in system version
 
!  Last FIRM version this was flaw was checked for
 
!  Last FIRM version this was flaw was checked for
Line 50: Line 51:     
However, this would require patching the kernel .text or modifying SVC-access-control. Even if you could get these to execute, they would still jump to memory that isn't mapped as executable.
 
However, this would require patching the kernel .text or modifying SVC-access-control. Even if you could get these to execute, they would still jump to memory that isn't mapped as executable.
 +
|
 
|  None
 
|  None
 
| [[9.3.0-21|9.3.0]]
 
| [[9.3.0-21|9.3.0]]
Line 56: Line 58:  
|  [[SVC|svcBackdoor (0x7B)]]
 
|  [[SVC|svcBackdoor (0x7B)]]
 
|  This backdoor allows executing SVC-mode code at the user-specified code-address. This is used by Process9, using this on the ARM11(with NATIVE_FIRM) requires patching the kernel .text or modifying SVC-access-control.
 
|  This backdoor allows executing SVC-mode code at the user-specified code-address. This is used by Process9, using this on the ARM11(with NATIVE_FIRM) requires patching the kernel .text or modifying SVC-access-control.
 +
| See description
 
|  None
 
|  None
 
| [[9.3.0-21|9.3.0]]
 
| [[9.3.0-21|9.3.0]]
Line 61: Line 64:  
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory
 
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory
 
| The ARM11 kernel-mode 0xEFF00000/0xDFF00000 virtual-memory(size 0x100000) is mapped to phys-mem 0x1FF00000(entire DSP-mem + entire AXIWRAM), with permissions RW-. This is used during ARM11 kernel startup, this never seems to be used after that, however.
 
| The ARM11 kernel-mode 0xEFF00000/0xDFF00000 virtual-memory(size 0x100000) is mapped to phys-mem 0x1FF00000(entire DSP-mem + entire AXIWRAM), with permissions RW-. This is used during ARM11 kernel startup, this never seems to be used after that, however.
 +
|
 
| None
 
| None
 
| [[9.3.0-21|9.3.0]]
 
| [[9.3.0-21|9.3.0]]
Line 67: Line 71:  
|  
 
|  
 
|  
 
|  
 +
| When combined with other flaws: ARM11-kernelmode code execution
 
| [[9.3.0-21|9.3.0]]
 
| [[9.3.0-21|9.3.0]]
 
|  
 
|  
Line 73: Line 78:  
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions
 
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions
 
| Originally the ARM11-kernel didn't check permissions for PXI input/output buffers for commands. Starting with [[6.0.0-11|6.0.0]] PXI input/output buffers must have RW permissions, otherwise kernelpanic is triggered.
 
| Originally the ARM11-kernel didn't check permissions for PXI input/output buffers for commands. Starting with [[6.0.0-11|6.0.0]] PXI input/output buffers must have RW permissions, otherwise kernelpanic is triggered.
 +
|
 
| [[6.0.0-11|6.0.0]]
 
| [[6.0.0-11|6.0.0]]
 
|  
 
|  
Line 85: Line 91:     
* The kernel now also checks whether the srcaddr/dstaddr (+size) is within userland memory (0x20000000), the kernel now (with [[6.0.0-11]]) returns an error when the address is beyond userland memory. Using an address >=0x20000000 would result in the kernel reading from the process L1 MMU table, beyond the memory allocated for that MMU table(for vaddr->physaddr conversion).  
 
* The kernel now also checks whether the srcaddr/dstaddr (+size) is within userland memory (0x20000000), the kernel now (with [[6.0.0-11]]) returns an error when the address is beyond userland memory. Using an address >=0x20000000 would result in the kernel reading from the process L1 MMU table, beyond the memory allocated for that MMU table(for vaddr->physaddr conversion).  
 +
|
 
| [[6.0.0-11]]
 
| [[6.0.0-11]]
 
|  
 
|  
Line 96: Line 103:  
* Integer overflows on (addr0+size) are now checked that previously weren't (this also applies to most other address checks elsewhere in the kernel).
 
* Integer overflows on (addr0+size) are now checked that previously weren't (this also applies to most other address checks elsewhere in the kernel).
    +
|
 
| [[5.0.0-11]]
 
| [[5.0.0-11]]
 
|  
 
|  
Line 103: Line 111:     
If the two words at threadlocalstorage+0x180 could be overwritten with controlled data this way, one could then use a command with a buffer-header of <nowiki>((size<<14) | 2)</nowiki> to write arbitrary memory to any RW userland memory in the destination process.
 
If the two words at threadlocalstorage+0x180 could be overwritten with controlled data this way, one could then use a command with a buffer-header of <nowiki>((size<<14) | 2)</nowiki> to write arbitrary memory to any RW userland memory in the destination process.
 +
|
 
| [[5.0.0-11]]
 
| [[5.0.0-11]]
 
|  
 
|  
Line 115: Line 124:     
(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)
 
(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)
 +
|
 
| [[5.0.0-11]]
 
| [[5.0.0-11]]
 
|  
 
|  
Line 121: Line 131:  
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions
 
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions
 
| svcControlMemory with MemoryOperation=MAP allows mapping the already-mapped process virtual-mem at addr1, to addr0. The lowest address permitted for addr1 is 0x00100000. Originally the ARM11 kernel didn't check memory permissions for addr1. Therefore .text as addr1 could be mapped elsewhere as RW- memory, which allowed ARM11 userland code-execution.
 
| svcControlMemory with MemoryOperation=MAP allows mapping the already-mapped process virtual-mem at addr1, to addr0. The lowest address permitted for addr1 is 0x00100000. Originally the ARM11 kernel didn't check memory permissions for addr1. Therefore .text as addr1 could be mapped elsewhere as RW- memory, which allowed ARM11 userland code-execution.
 +
|
 
| [[4.1.0-8]]
 
| [[4.1.0-8]]
 
|  
 
|  
Line 127: Line 138:  
| [[RPC_Command_Structure|Command]] input/output buffer permissions
 
| [[RPC_Command_Structure|Command]] input/output buffer permissions
 
| Originally the ARM11 kernel didn't check memory permissions for the input/output buffers for commands. Starting with [[4.0.0-7]] the ARM11 kernel will trigger a kernelpanic() if the input/output buffers don't have the required memory permissions. For example, this allowed a FSUSER file-read to .text, which therefore allowed ARM11-userland code execution.
 
| Originally the ARM11 kernel didn't check memory permissions for the input/output buffers for commands. Starting with [[4.0.0-7]] the ARM11 kernel will trigger a kernelpanic() if the input/output buffers don't have the required memory permissions. For example, this allowed a FSUSER file-read to .text, which therefore allowed ARM11-userland code execution.
 +
|
 
| [[4.0.0-7]]
 
| [[4.0.0-7]]
 
|  
 
|  
Line 133: Line 145:  
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions
 
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions
 
| Originally the kernel only checked the first page(0x1000-bytes) of the src/dst buffers, for svcReadProcessMemory and svcWriteProcessMemory. There is no known retail processes which have access to these SVCs.
 
| Originally the kernel only checked the first page(0x1000-bytes) of the src/dst buffers, for svcReadProcessMemory and svcWriteProcessMemory. There is no known retail processes which have access to these SVCs.
 +
|
 
| [[4.0.0-7]]
 
| [[4.0.0-7]]
 
|  
 
|