Difference between revisions of "Switch System Flaws"

From Nintendo Switch Brew
Jump to navigation Jump to search
(bootloader stage 1 flaw fixed in 3.0.0)
Line 23: Line 23:
  
 
== System software ==
 
== System software ==
−
=== Kernel ===
+
 
 +
 
 +
=== Stage 1 Bootloader ===
 +
{| class="wikitable" border="1"
 +
|-
 +
!  Summary
 +
!  Description
 +
!  Successful exploitation result
 +
!  Fixed in system version
 +
!  Last system version this flaw was checked for
 +
!  Timeframe this was discovered
 +
!  Public disclosure timeframe
 +
!  Discovered by
 +
|-
 +
|  Null-dereference in panic()
 +
|  The Switch's stage 1 bootloader, on panic(), clears the stack and then attempts to clear the Security Engine. However, it does so by dereferencing a pointer to the SE in .bss (initially NULL), and this pointer doesn't get initialized until partway into the bootloader's main(). Thus, a panic() caused prior to SE initialization would result in the SE pointer still being NULL when dereferenced. This would cause a data abort, causing the bootloader to clear the stack and then try to clear the security engine...dereferencing NULL again, over and over in a loop.
 +
 
 +
In 3.0.0, this was fixed by moving the security engine initialization earlier in main(), before the first function that could potentially panic().
 +
|  Infinite clear-the-stack-then-data-abort loop very early in boot, before SBK/other keyslots are cleared. Probably useless for anything more interesting.
 +
|  [[3.0.0]]
 +
|  [[3.0.0]]
 +
|  Early July, 2017
 +
|  July 30, 2017
 +
|  Everyone who diff'd 2.3.0 and 3.0.0 Package1
 +
|-
 +
|}
 +
 
 +
 
 +
=== TrustZone ===
 
{| class="wikitable" border="1"
 
{| class="wikitable" border="1"
 
|-
 
|-
Line 35: Line 63:
 
!  Discovered by
 
!  Discovered by
 
|-
 
|-
−
|  No public Kernel exploits  
+
|  No public ARM TrustZone exploits  
 
|
 
|
 
|
 
|
Line 46: Line 74:
 
|}
 
|}
  
−
=== TrustZone ===
+
=== Kernel ===
 
{| class="wikitable" border="1"
 
{| class="wikitable" border="1"
 
|-
 
|-
Line 58: Line 86:
 
!  Discovered by
 
!  Discovered by
 
|-
 
|-
−
|  No public ARM TrustZone exploits  
+
|  No public Kernel exploits  
 
|
 
|
 
|
 
|
Line 68: Line 96:
 
|-
 
|-
 
|}
 
|}
 +
  
 
=== System Modules ===
 
=== System Modules ===

Revision as of 07:03, 30 July 2017

System Flaws are used to execute unofficial code (homebrew) on the Nintendo Switch. This page is a list of known and public Switch System Flaws.

List of Switch System Flaws

Hardware

Summary Description Fixed with hardware model/revision Newest hardware model/revision this flaw was checked for Timeframe this was discovered Discovered by
No public hardware exploits

System software

Stage 1 Bootloader

Summary Description Successful exploitation result Fixed in system version Last system version this flaw was checked for Timeframe this was discovered Public disclosure timeframe Discovered by
Null-dereference in panic() The Switch's stage 1 bootloader, on panic(), clears the stack and then attempts to clear the Security Engine. However, it does so by dereferencing a pointer to the SE in .bss (initially NULL), and this pointer doesn't get initialized until partway into the bootloader's main(). Thus, a panic() caused prior to SE initialization would result in the SE pointer still being NULL when dereferenced. This would cause a data abort, causing the bootloader to clear the stack and then try to clear the security engine...dereferencing NULL again, over and over in a loop.

In 3.0.0, this was fixed by moving the security engine initialization earlier in main(), before the first function that could potentially panic().

Infinite clear-the-stack-then-data-abort loop very early in boot, before SBK/other keyslots are cleared. Probably useless for anything more interesting. 3.0.0 3.0.0 Early July, 2017 July 30, 2017 Everyone who diff'd 2.3.0 and 3.0.0 Package1


TrustZone

Summary Description Successful exploitation result Fixed in system version Last system version this flaw was checked for Timeframe this was discovered Public disclosure timeframe Discovered by
No public ARM TrustZone exploits

Kernel

Summary Description Successful exploitation result Fixed in system version Last system version this flaw was checked for Timeframe this was discovered Public disclosure timeframe Discovered by
No public Kernel exploits


System Modules

Summary Description Successful exploitation result Fixed in system version Last system version this flaw was checked for Timeframe this was discovered Public disclosure timeframe Discovered by
OOB Read in NS system module (pl:utoohax, pl:utonium, maybe other names) Prior to 3.0.0, pl:u (Shared Font services implemented in the NS sysmodule) service commands 1,2,3 took in a signed 32-bit index and returned that index of an array but did not check that index at all. This allowed for an arbitrary read within a 34-bit range (33-bit signed) from NS .bss. In 3.0.0, sending out of range indexes causes error code 0x60A to be returned. Dumping full NS .text, .rodata and .data, infoleak, etc 3.0.0 3.0.0 April 2017 On exploit's fix in 3.0.0 qlutoo, Reswitched team (independently)
Unchecked domain ID in common IPC code Prior to 2.0.0, object IDs in domain messages are not bounds checked. This out-of-bounds read could be exploited to brute-force ASLR and get PC control in some services that support domain messages. 2.0.0
Retrieved from "https://switchbrew.org/w/index.php?title=Switch_System_Flaws&oldid=1834"