Changes

Jump to navigation Jump to search
144 bytes added ,  06:17, 12 August 2018
→‎Boot ROM: Better sighax description
Line 133: Line 133:  
| Everyone
 
| Everyone
 
|-
 
|-
| sighax: Boot9 improper PKCS #1 v1.5 signature validation
+
| sighax: Boot9 improper validation of FIRM partition RSA signatures
| The [[Flash_Filesystem|FIRM partitions]] are signed with RSA-2048 using SHA-256 and PKCS #1 v1.5 padding.  Boot9, however, does improper validation of the padding in three ways:
+
| The [[Flash_Filesystem|FIRM partitions]] are signed with RSA-2048 using SHA-256 and PKCS #1 v1.5 padding.  Boot9, however, improperly validates the padding in three ways:
# Boot9 permits block type 02, meant for encrypted messages, to be used for signatures.  Only 01, for signatures, should have been permitted.  As a result, a signature block is not required to have a long string of FF bytes as padding, but rather any random values suffice.  While correct for encryption, this severely lessens security of signatures.
+
# Boot9 permits block type 02, meant for encrypted messages, to be used for signatures.  Only 01, for signatures, should have been permitted.  As a result, when using block type 02, a signature block is not required to have a long string of FF bytes as padding, but rather any nonzero random values suffice.
 
# Boot9 does not require that the length of the padding fill out the signature block completely.  As a result, there is considerable freedom in the layout of a signature.
 
# Boot9 does not require that the length of the padding fill out the signature block completely.  As a result, there is considerable freedom in the layout of a signature.
 
# Boot9 fails to do bounds checking in its parsing of the DER-encoded hash algorithm type and hash value; the length values given in DER are permitted to point outside the signature block.
 
# Boot9 fails to do bounds checking in its parsing of the DER-encoded hash algorithm type and hash value; the length values given in DER are permitted to point outside the signature block.
 
Flaw 3 allows the DER encoding to be such that boot9 believes that the signature's hash value is outside the range of the block itself, somewhere on the stack.  This can be pointed at the correct hash value it computes.  Boot9 then memcmp's the calculated hash against itself, and thinks that the hash is valid.
 
Flaw 3 allows the DER encoding to be such that boot9 believes that the signature's hash value is outside the range of the block itself, somewhere on the stack.  This can be pointed at the correct hash value it computes.  Boot9 then memcmp's the calculated hash against itself, and thinks that the hash is valid.
   −
When all three flaws are combined, a brute force in a reasonable amount of time can find a signature that passes all checks.
+
As a result of the above, we estimate that one in 2<sup>43</sup> (~8.8 trillion) random fake signatures will be considered by Boot9 to be valid.  This is well within the range of brute force, particularly with an optimized GPU implementation.  An Nvidia GTX 1080 Ti would take about one week to find a match.
 
| None
 
| None
 
| New3DS
 
| New3DS
119

edits

Navigation menu