Switch System Flaws: Difference between revisions
m Flesh out detail on Splatoon 3 report based on HackerOne summary. |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 1,180: | Line 1,180: | ||
| November 2021? | | November 2021? | ||
| January 19, 2026 | | January 19, 2026 | ||
| [[User:Yellows8|yellows8]] | |||
|- | |||
| [[NFC_services|nfc]] Initialize buffer overflow | |||
| All Initialize* cmds for nn::nfc::detail::IUser (nfc:user), nn::nfc::detail::ISystem (nfc:sys), nn::nfp::detail::IUser (nfp:user), nn::nfp::detail::ISystem (nfp:sys), nn::nfp::detail::IDebug (nfp:dbg), nn::nfc::mifare::detail::IUser (nfc:mf:u): these copy the input array into _this, without validating the array count. | |||
The data is copied to obj_impl+0x8+0x28, with each entry being 0x20-bytes. The event handle returned by AttachAvailabilityChangeEvent is at obj_impl+0x8+0xB8+0x14 (Same with nfc/nfp interfaces). This therefore means +0xA4 in the input buffer will overwrite the handle returned by that cmd, allowing one to leak any handle with the specified value. This can be done with count=0x6. The object is large enough that this count will only overwrite data within the current object. However during the dtor it will use ptrs which were corrupted with this (located before the event), so one must avoid closing the session unless the input data included valid ptrs. | |||
This can be exploited by just using a 0xC0-byte (array_count=0x6) input buffer with Initialize where each u32 is the target nfc handle value, then using cmd GetAvailabilityChangeEventHandle to leak the handle. | |||
[22.0.0+] This was fixed by clamping the count to a maximum of 0x4. | |||
| OOB datacopy into object state. Allows leaking arbitary [[NFC_services|handles]], including on [S2] (such as process-handle, sm, fsp-srv (remaining services can also be used via sm)). | |||
| [[22.0.0]] | |||
| [[22.0.0]] | |||
| November 2021 | |||
| March 17, 2026 | |||
| [[User:Yellows8|yellows8]] | | [[User:Yellows8|yellows8]] | ||
|} | |} | ||