Line 972: |
Line 972: |
| | January 2, 2023 | | | January 2, 2023 |
| | October 17, 2023 | | | October 17, 2023 |
| + | | [[User:Yellows8|yellows8]] |
| + | |- |
| + | | [[PSC_services|ovln:snd]] OpenSender unvalidated count |
| + | | ovln:snd OpenSender has a count param. This count is used to allocate the specified number of objects in a linked-list for storing the data from Send. If count is 0, the linked-list is left empty, with ptrs to itself within the ISender object. |
| + | |
| + | ISender Send when the above linked-list is empty, runs a switch-statement with <code>(inval>>8)&0xFF</code>. This uses another linked-list where the ptrs are initially {within ISender obj}. |
| + | No space is allocated in the ISender obj for the linked-list object-data. Therefore using Send with val 1<<8 or 2<<8 (other values throw error) results in the specified input struct being copied into the ISender obj, which then overwrites heap data OOB. |
| + | If for example one used OpenSender again right after the first OpenSender usage, then used Send as described above, this would corrupt the second ISender which includes overwriting the vtable. |
| + | If one would use Send twice in a row like this, the second one would use a corrupted linked-list (written from the first Send). If the linked-list ptrs would be valid (no crash triggered) this would allow one to copy the input data to a controlled addr, though it's restricted with the linked-list usage. |
| + | |
| + | Using GetUnreceivedMessageCount afterwards is of no interest. |
| + | |
| + | Besides ovln, the only other allocs on this heap is from IPmModule Initialize. This heap is also used for psc:* services (object allocs). |
| + | |
| + | In theory (untested) it may be possible to also use this to obtain infoleaks, however it would only return the high-u32 of ptrs not the low u32. Essentially, one would trigger object allocations so that ExpHeap has layout: {ISender} -> {RF chunk from freeing an object} -> {module object from IPmModule Initialize}. Then one would use the Send vuln to corrupt the RF chunk, changing the size to a larger value. Then one would trigger an object allocation (probably same object which was previously freed), then another object for overwriting the module object (ISender would work) with ptrs at the target offsets in the module object. Then once IPmModule GetRequest is used, the returned u32s would be the high-u32 from ptrs. Due to alignment requirements with each allocation, it isn't possible to shift the allocations in order to leak ptr low-u32. |
| + | |
| + | [17.0.0+] Now throws an error if the input count for OpenSender is 0. |
| + | | [[PSC_services|psc]]-sysmodule heap memory corruption ([[NS_services|ns]]-sysmodule on pre-8.0.0). |
| + | | [[17.0.0]] |
| + | | [[17.0.0]] |
| + | | January 13, 2023 |
| + | | October 20, 2023 |
| | [[User:Yellows8|yellows8]] | | | [[User:Yellows8|yellows8]] |
| |} | | |} |