Line 140: |
Line 140: |
| ! Discovered by | | ! Discovered by |
| |- | | |- |
− | | [[Home Menu]] sdiconhax | + | | Webkit/web-browser bugs |
| + | | spider has had at least three different code-execution exploits. Majority of them are use-after-free issues. See also [[browserhax|here]]. |
| + | | |
| + | | |
| + | | |
| + | | 2013? |
| + | | |
| + | | A lot of people. |
| + | |- |
| + | | Old3DS/New3DS [[Internet_Browser|Browser-version-check]] bypass |
| + | | When the browser-version-check code runs where the savedata for it was never initialized(such as when the user used the "Initialize savedata" option), it will use base_timestamp=0 instead of the timestamp loaded from savedata. This is then used with "if(cur_timestamp - base_timestamp >= <24h timestamp>){Run browser-version-check HTTPS request code}". |
| + | Hence, if the savedata was just initialized, and if the system datetime is set to before January 2, 2000, the browser-version-check will be skipped. This includes January 1, 2000, 00:00, because that's the epoch(timestamp value 0x0) used with this timestamp. |
| + | |
| + | See [http://yls8.mtheall.com/3dsbrowserhax.php here] for bypass usage instructions. |
| + | |
| + | This was fixed with [[10.7.0-32|10.7.0-32]], see [[Internet_Browser|here]] for details. |
| + | | [[10.7.0-32|10.7.0-32]] |
| + | | |
| + | | [[9.9.0-26|9.9.0-26]] |
| + | | February 25, 2016 |
| + | | November 2, 2015 (Exactly one week after the browser version pages were initially updated server-side) |
| + | | [[User:Yellows8|Yellows8]] |
| + | |} |
| + | |
| + | ==Home Menu== |
| + | {| class="wikitable" border="1" |
| + | |- |
| + | ! Summary |
| + | ! Description |
| + | ! Fixed in version |
| + | ! Last version this flaw was checked for |
| + | ! Introduced with version |
| + | ! Timeframe info related to this was added to wiki |
| + | ! Timeframe this was discovered |
| + | ! Discovered by |
| + | |- |
| + | | sdiconhax |
| | This is basically the same as nandiconhax, the vulnerable SD/NAND functions are ''identical'' minus the file-buffer offsets. Exploitation is different due to different heap-buffer location though. Unlike nandiconhax, the icon buffer for SD is located in linearmem(with recent Home Menu versions at least). This is used by [[menuhax]]. | | | This is basically the same as nandiconhax, the vulnerable SD/NAND functions are ''identical'' minus the file-buffer offsets. Exploitation is different due to different heap-buffer location though. Unlike nandiconhax, the icon buffer for SD is located in linearmem(with recent Home Menu versions at least). This is used by [[menuhax]]. |
| | None | | | None |
| | [[11.0.0-33|11.0.0-X]] | | | [[11.0.0-33|11.0.0-X]] |
− | | Maybe v3.0? | + | | [[4.0.0-7|4.0.0-X]] |
| | July 27, 2016 | | | July 27, 2016 |
| | October 23, 2015 | | | October 23, 2015 |
| | [[User:Yellows8|Yellows8]] | | | [[User:Yellows8|Yellows8]] |
| |- | | |- |
− | | [[Home Menu]] [[System_SaveData|NAND-savedata]] Launcher.dat icons (nandiconhax) | + | | [[System_SaveData|NAND-savedata]] Launcher.dat icons (nandiconhax) |
| | The homemenu code processing the titleid list @ launcherdat+8 copies those titleIDs to another buffer, where the offset relative to that buffer is calculated using the corresponding s8/s16 entries. Those two values are not range checked at all. Hence, one can use this to write u64(s) with arbitrary values to before/after this allocated output buffer. See [[Home_Menu|here]] regarding Launcher.dat structure. | | | The homemenu code processing the titleid list @ launcherdat+8 copies those titleIDs to another buffer, where the offset relative to that buffer is calculated using the corresponding s8/s16 entries. Those two values are not range checked at all. Hence, one can use this to write u64(s) with arbitrary values to before/after this allocated output buffer. See [[Home_Menu|here]] regarding Launcher.dat structure. |
| | | |
Line 158: |
Line 194: |
| Home Menu has some sort of fail-safe system(or at least on v9.7) when Home Menu crashes due to Launcher.dat(this also applies for other things with Home Menu): after crashing once, Home Menu resets Launcher.dat to a state where it no longer crashes anymore. However, note that any exploits using this which hang/etc without crashing will still brick the system. '''Hence, attempting anything with this on physnand without hw-nand-access isn't really recommended.''' | | Home Menu has some sort of fail-safe system(or at least on v9.7) when Home Menu crashes due to Launcher.dat(this also applies for other things with Home Menu): after crashing once, Home Menu resets Launcher.dat to a state where it no longer crashes anymore. However, note that any exploits using this which hang/etc without crashing will still brick the system. '''Hence, attempting anything with this on physnand without hw-nand-access isn't really recommended.''' |
| | None | | | None |
− | | [[10.3.0-28|10.3.0-X]] | + | | [[11.0.0-33|11.0.0-X]] |
− | | | + | | [[4.0.0-7|4.0.0-X]] |
| | | | | |
| | May 14, 2015 | | | May 14, 2015 |
| | [[User:Yellows8|Yellows8]] | | | [[User:Yellows8|Yellows8]] |
| |- | | |- |
− | | [[Home Menu]] theme-data decompression buffer overflow ([[menuhax|themehax]]) | + | | Theme-data decompression buffer overflow ([[menuhax|themehax]]) |
| | The only func-call size parameter used by the theme decompression function is one for the compressed size, none for the decompressed size. The decompressed-size value from the LZ header is used by this function to check when to stop decompressing, but this function itself has nothing to verify the decompressed_size with. The code calling this function does not check or even use the decompressed size from the header either. | | | The only func-call size parameter used by the theme decompression function is one for the compressed size, none for the decompressed size. The decompressed-size value from the LZ header is used by this function to check when to stop decompressing, but this function itself has nothing to verify the decompressed_size with. The code calling this function does not check or even use the decompressed size from the header either. |
| | | |
Line 181: |
Line 217: |
| | [[User:Yellows8|Yellows8]], [[User:Myria|Myria]] independently (~spring 2015) | | | [[User:Yellows8|Yellows8]], [[User:Myria|Myria]] independently (~spring 2015) |
| |- | | |- |
− | | [[Home Menu]] shuffle body-data buffer overflow ([[menuhax|shufflehax]]) | + | | Shuffle body-data buffer overflow ([[menuhax|shufflehax]]) |
| | See [[menuhax|here]]. | | | See [[menuhax|here]]. |
| | [[10.6.0-31|10.6.0-X]] | | | [[10.6.0-31|10.6.0-X]] |
Line 190: |
Line 226: |
| | [[User:Yellows8|Yellows8]] | | | [[User:Yellows8|Yellows8]] |
| |- | | |- |
− | | [[Home Menu]] extdata SaveData.dat loading buffer overflow | + | | Extdata SaveData.dat loading buffer overflow |
| | The extdata SaveData.dat file-reading code allocates a fixed-size heap buffer for the expected SaveData.dat filesize, then reads the filedata into this buffer using the actual FS filesize. Before v5.0 the filesize used here wasn't validated, hence if the filesize is larger than alloc_size a buffer overflow would occur. ''After'' doing the file-read it does validate that the actual_readsize matches the alloc_size, but at this point the buffer overflow has already occurred. | | | The extdata SaveData.dat file-reading code allocates a fixed-size heap buffer for the expected SaveData.dat filesize, then reads the filedata into this buffer using the actual FS filesize. Before v5.0 the filesize used here wasn't validated, hence if the filesize is larger than alloc_size a buffer overflow would occur. ''After'' doing the file-read it does validate that the actual_readsize matches the alloc_size, but at this point the buffer overflow has already occurred. |
| | | |
Line 204: |
Line 240: |
| | June 9, 2016 | | | June 9, 2016 |
| | [[User:Yellows8|Yellows8]] | | | [[User:Yellows8|Yellows8]] |
− | |- | + | |} |
− | | Webkit/web-browser bugs
| |
− | | spider has had at least three different code-execution exploits. Majority of them are use-after-free issues. See also [[browserhax|here]].
| |
− | |
| |
− | |
| |
− | |
| |
− | | 2013?
| |
− | |
| |
− | | A lot of people.
| |
− | |-
| |
− | | Old3DS/New3DS [[Internet_Browser|Browser-version-check]] bypass
| |
− | | When the browser-version-check code runs where the savedata for it was never initialized(such as when the user used the "Initialize savedata" option), it will use base_timestamp=0 instead of the timestamp loaded from savedata. This is then used with "if(cur_timestamp - base_timestamp >= <24h timestamp>){Run browser-version-check HTTPS request code}".
| |
− | Hence, if the savedata was just initialized, and if the system datetime is set to before January 2, 2000, the browser-version-check will be skipped. This includes January 1, 2000, 00:00, because that's the epoch(timestamp value 0x0) used with this timestamp.
| |
| | | |
− | See [http://yls8.mtheall.com/3dsbrowserhax.php here] for bypass usage instructions.
| + | The icon data arrays used with {sd/nand}iconhax were added to SaveData.dat/Launcher.dat with [[4.0.0-7|4.0.0-X]], hence the vulnerable functions were added with that same version. |
− | | |
− | This was fixed with [[10.7.0-32|10.7.0-32]], see [[Internet_Browser|here]] for details.
| |
− | | [[10.7.0-32|10.7.0-32]]
| |
− | |
| |
− | | [[9.9.0-26|9.9.0-26]]
| |
− | | February 25, 2016
| |
− | | November 2, 2015 (Exactly one week after the browser version pages were initially updated server-side)
| |
− | | [[User:Yellows8|Yellows8]]
| |
− | |}
| |
| | | |
| ==Useless crashes== | | ==Useless crashes== |