4,622
edits
Changes
Jump to navigation
Jump to search
Line 1,005:
Line 1,005: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
→NintendoSDK
| November-December 2019
| November-December 2019
| December 31, 2020
| December 31, 2020
| [[User:Yellows8|yellows8]]
|}
=== Pia ===
This section documents vulnerabilities for Pia.
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in Pia version
! Last Pia version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| nn::pia::session::RelayRouteManageJob::UpdateConnectionReport buffer overflow
| nn::pia::session::RelayRouteManageJob::UpdateConnectionReport() checks that the input size is at least {value}, but there's no max size check. This is used to memcpy from the input to elsewhere - hence buf-overflow if size is too large. The dst buffer is allocated on the pead heap - this buffer is probably small.
Note that there's various requirements before it would actually reach the memcpy, such as <code><nn::pia::session::Mesh::IsHost() const></code> must return true.
In fixed versions immediately after the StationIndex validation it now does: <code>if(statefield+0x10<input_size) return;</code>
This is called from nn::pia::session::MeshProtocol::ParseConnectionReport().
| Heap buffer overflow triggered by a Pia MeshProtocol message sent to a host device.
| Fixed in v5.9.3, exact version unknown.
| v5.9.1/v5.9.3
| November 11, 2022
| November 15, 2022
| [[User:Yellows8|yellows8]]
|-
| nn::pia::lan::LanProtocol::ParseSessionMessage buffer overflow
| nn::pia::lan::LanProtocol::ParseSessionMessage() calls nn::pia::lan::LanSessionMessage::Deserialize() to deserialize the message payload data buffer into the LanSessionMessage object on stack. LanSessionMessage::Deserialize (among other things) memcpys data from the input buffer to the object, using an u32 from the input buffer - there is no size validation in Deserialize itself.
There is a size check immediately after calling Deserialize() to verify <code>payloadsize=={u32val}+{constant}</code>, returning on fail - but this doesn't matter for too-large-size.
In fixed versions Deserialize now does bounds checking, both for the minimum message size and clamping the memcpy size to a constant. An error is thrown if the clamped memcpy size is larger than the message size. The caller now checks the ret properly, previously it was ignored.
Following the size check in ParseSessionMessage() it calls <code><nn::pia::session::Mesh::IsProcessingLeaveMesh() const></code>, returning if ret is false.
Then it calls nn::pia::lan::LanProtocol::ReceivedFragmentData::Receive(), with the memcpy'd buffer/size from the above LanSessionMessage, and other fields from LanSessionMessage. This eventually memcpys the input buffer to object+{offset}+{chunksize_field}*inputu8, there is no validation for size or inputu8 (except for the above size check). Hence, if the u8 is large enough, this would result in a heap buffer overflow.
In fixed versions ReceivedFragmentData::Receive added a bunch of validation before the memcpy.
| Stack/heap buffer overflow triggered by a Pia LanProtocol message.
| Fixed in v5.9.3, exact version unknown.
| v5.9.1/v5.9.3
| November 14, 2022
| November 15, 2022
| [[User:Yellows8|yellows8]]
|-
| nn::pia::session::SessionProtocol::ParseLeaveMeshInvitation buffer overflow
| <code><nn::pia::session::SessionProtocol::ParseLeaveMeshInvitation(nn::pia::transport::ReceivedMessageAccessor const&)></code> This immediately returns if *(ReceivedMessageAccessor+16) is 0. Then the input data is deserialized. The input u64 array is deserialized to stack, the u8 arraycount field from input is not validated.
Hence, stack buffer overlow. Note that there's similar loop code in nearby funcs, which do validate the count properly.
In fixed versions the arraycount field is now validated.
| Stack buffer overflow triggered by a Pia SessionProtocol message.
| Fixed in v5.9.3, exact version unknown.
| v5.9.1/v5.9.3
| November 14, 2022
| November 15, 2022
| [[User:Yellows8|yellows8]]
| [[User:Yellows8|yellows8]]
|}
|}