Editing Vulnerabilities
Jump to navigation
Jump to search
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.
| Latest revision | Your text | ||
| Line 1: | Line 1: | ||
= | = Kernel = | ||
== | == PSP kernel exploits == | ||
sceNetMCopyback kexploit by qwikrazor87 and AcidSnake (ARK-4): PSP ?.?? | |||
https://github.com/PSP-Archive/ARK-4/blob/main/loader/live/kernel/rodumper/main.c | |||
sceNetMPulldown (also called ifhandle 6.60) kexploit by davee (PROCFW, Chronoswitch, Infinity): PSP 6.60-6.61 | |||
sceHttpStorageOpen kexploit, 0xFFFFFFFFailSploit, write -1 to anywhere by some1 (Chronoswitch): PSP 6.38-6.39 | |||
sceUtilityPowerRegisterCallback kexploit by TN and davee with sceKernelUtilsMd5BlockInit kexploit to keep the data dynamic (TN-HEN, Chronoswitch): PSP 6.20, 6.31, 6.35 | |||
= | ifhandle 5.70 race condition by davee: PSP <= 5.70, patched on PSP 6.20 | ||
= | sceDRMInstallGetFileInfo memset anywhere (also called psheet 5.03) kexploit by davee, lack of k1 checks (ChickHEN): PSP <=5.03 | ||
= | registry error store: PSP <=2.80 | ||
LoadExec buffer overflow: PSP <=2.60 | |||
reused index.dat key: PSP 2.00, 2.01 | |||
= | swaptrick/kxploit: PSP <=1.50 | ||
kernel flagged ELF: PSP <=1.00 | |||
== | == PS Vita ePSP kernel exploits == | ||
kernel execution using encrypted UID planting Type Confusion kexploit by qwikrazor87 (Trinity, ARK-4): PS Vita 3.60-3.74 | |||
https://theofficialflow.github.io/2019/06/18/trinity.html#type-confusion | https://theofficialflow.github.io/2019/06/18/trinity.html#type-confusion | ||
kernel read using sceNpCore_8AFAB4A0 Double-fetch Race Condition kexploit by qwikrazor87 (Trinity): PS Vita 3.70 | |||
https://theofficialflow.github.io/2019/06/18/trinity.html#double-fetch-race-condition | https://theofficialflow.github.io/2019/06/18/trinity.html#double-fetch-race-condition | ||
VPL kexploit: PS Vita 3.00-3.52 | |||
sceKernelDeleteThread kexploit: PS Vita <=3.50 | |||
sceVideocodec kexploit: PS Vita 3.30-3.36 | |||
= | _sceSdGetLastIndex kexploit (TN-X, TN-V): PS Vita <=3.20 (works on 3.18-3.20) | ||
_sceLoadCertFromFlash kexploit (TN-V): PS Vita <3.18 | |||
sceWlanGetEtherAddr kexploit: PS Vita 1.61-1.80 | |||
_sceG729EncodeTermResource kexploit: PS Vita FW unk | |||
sceWlanDrv kexploit: PS Vita FW unk | |||
= iplloader = | = Lib-PSP iplloader = | ||
== NMI Backdoor == | == NMI Backdoor == | ||
| Line 1,039: | Line 62: | ||
Applicable to: None | Applicable to: None | ||
Vulnerable: iplloader (all | Vulnerable: Lib-PSP iplloader (all bootrom versions, 0.7.0 and newer Kbooti versions, PS Vita's PSP emulator bootrom) | ||
The iplloader bootrom (present within Tachyon's IC package) as well as iplloader versions 0.7.0 and onward feature a NMI/Interrupt handler backdoor (most likely used internally for debugging purposes) in its loader part at the very first instructions of the bootrom. | The Lib-PSP iplloader bootrom (present within Tachyon's IC package) as well as Lib-PSP iplloader versions 0.7.0 and onward feature a NMI/Interrupt handler backdoor (most likely used internally for debugging purposes) in its loader part at the very first instructions of the bootrom. | ||
This backdoor allows anyone in control of the memory location address 0xBC100000 to perform a jump to an arbitrary location defined in coprocessor register $9 | This backdoor allows anyone in control of the memory location address 0xBC100000 to perform a jump to an arbitrary location defined in coprocessor register $9 | ||
If value at address 0xBC100000 is not equal to 0 and coprocessor register $9 is set, iplloader will jump to the address set in the register very early in the code (by the 8th instruction). Else (if value at address 0xBC100000 is equal to 0), coprocessor register $9 will be reset back to 0. | If value at address 0xBC100000 is not equal to 0 and coprocessor register $9 is set, Lib-PSP iplloader will jump to the address set in the register very early in the code (by the 8th instruction). Else (if value at address 0xBC100000 is equal to 0), coprocessor register $9 will be reset back to 0. | ||
Below are the relevant pieces of code: | Below are the relevant pieces of code: | ||
| Line 1,060: | Line 83: | ||
</pre> | </pre> | ||
This backdoor may allow an attacker performing a hardware based attack to set those values and gain iplloader time code execution. | This backdoor may allow an attacker performing a hardware based attack to set those values and gain Lib-PSP iplloader time code execution. | ||
== Arbitrary IPL Load Address == | == Arbitrary IPL Load Address == | ||
| Line 1,072: | Line 95: | ||
Fixed: Partially in Tachyon 0x00600000. The CPU scratchpad (0xA0010000 uncached; 0x80010000 cached) range is now blacklisted, whilst all other addresses remain allowed. | Fixed: Partially in Tachyon 0x00600000. The CPU scratchpad (0xA0010000 uncached; 0x80010000 cached) range is now blacklisted, whilst all other addresses remain allowed. | ||
iplloader will not control the location at which it will load/copy the block. It will happily attempt to perform a memcpy (at a rate of 1 DWORD per cycle) to whatever load address is specified in the IPL header, assuming that the header passes the checks (Kirk cmd 1, Kirk cmd 1 ECDSA, Kirk cmd 0x6C SHA1 (on Tachyon 0x00600000 and later), ...). This allows to write a payload at arbitrary locations. | Lib-PSP iplloader will not control the location at which it will load/copy the block. It will happily attempt to perform a memcpy (at a rate of 1 DWORD per cycle) to whatever load address is specified in the IPL header, assuming that the header passes the checks (Kirk cmd 1, Kirk cmd 1 ECDSA, Kirk cmd 0x6C SHA1 (on Tachyon 0x00600000 and later), ...). This allows to write a payload at arbitrary locations. | ||
== Arbitrary IPL Entrypoint Address == | == Arbitrary IPL Entrypoint Address == | ||
| Line 1,082: | Line 105: | ||
Applicable to: IPL time code execution on 01g and 02g, used in Pandora | Applicable to: IPL time code execution on 01g and 02g, used in Pandora | ||
Fixed: iplloader 2.6.0 | Fixed: Lib-PSP iplloader 2.6.0 | ||
iplloader will jump to any location specified in the last IPL block's entrypoint. This allows arbitrary execution. This was used in conjunction with the Kirk time-attack to craft a block and gain execution from at address 0xBFD00100 in the Pandora hack, and thus allowed to craft a "valid" block in a more timely fashion. | Lib-PSP iplloader will jump to any location specified in the last IPL block's entrypoint. This allows arbitrary execution. This was used in conjunction with the Kirk time-attack to craft a block and gain execution from at address 0xBFD00100 in the Pandora hack, and thus allowed to craft a "valid" block in a more timely fashion. | ||
Note: The vulnerability is also present on Tachyon 0x00600000 and later, but cannot be exploited by itself due to an ECDSA signature (Kirk cmd 17) check. | Note: The vulnerability is also present on Tachyon 0x00600000 and later, but cannot be exploited by itself due to an ECDSA signature (Kirk cmd 17) check. | ||
== No minimum IPL block size == | == No minimum IPL block size == | ||
| Line 1,100: | Line 121: | ||
Fixed: Tachyon 0x00600000. Bootrom now requires a minimum IPL block size of 0x100. | Fixed: Tachyon 0x00600000. Bootrom now requires a minimum IPL block size of 0x100. | ||
iplloader will not control the block size. This allows to craft a small, favorable for time-attack, IPL block. | Lib-PSP iplloader will not control the block size. This allows to craft a small, favorable for time-attack, IPL block. | ||
== Lib-PSP iplloader assumes a block with the checksum 0 is the first IPL block == | |||
== iplloader assumes a block with the checksum 0 is the first IPL block == | |||
Found by: C+D/Prometheus - Earliest discovery: 2006 Q4 | Found by: C+D/Prometheus - Earliest discovery: 2006 Q4 | ||
| Line 1,114: | Line 133: | ||
Fixed: indirectly since Tachyon 0x00600000 as no IPL that run on Tachyon 0x00600000 and onwards have a block that uses a previous block checksum of 0 other than block #0 itself. | Fixed: indirectly since Tachyon 0x00600000 as no IPL that run on Tachyon 0x00600000 and onwards have a block that uses a previous block checksum of 0 other than block #0 itself. | ||
This implementation fault has been exploited to create a memory hole in VRAM that could be filled with our own payload to gain execution and dump iplloader. | This implementation fault has been exploited to create a memory hole in VRAM that could be filled with our own payload to gain execution and dump Lib-PSP iplloader. | ||
== iplloader do not perform the XOR step when running in Jig/Service mode == | == Lib-PSP iplloader do not perform the XOR step when running in Jig/Service mode == | ||
Found by: Mathieulh - Earliest discovery: 2019 Q1 | Found by: Mathieulh - Earliest discovery: 2019 Q1 | ||
Introduced: iplloader 3.5.0 | Introduced: Lib-PSP iplloader 3.5.0 | ||
Applicable to: Code execution on 3.5.0 iplloader without previous knowledge of the XOR key. | Applicable to: Code execution on 3.5.0 Lib-PSP iplloader without previous knowledge of the XOR key. | ||
Fixed: probably never as 3.5.0 is the last known iplloader revision for Development Tool | Fixed: probably never as 3.5.0 is the last known Lib-PSP iplloader revision for Development Tool | ||
This is not so much a vulnerability as a poor design implementation. | This is not so much a vulnerability as a poor design implementation. | ||
To allow service centers to use a unique Memory Stick for multiple PSP models during servicing, iplloader deliberately disables the XOR step, allowing a non XORed IPL to run from Memory Stick. This is done so that the IPL can run on all systems from 01g to 11g. This is also presumably done because XOR keys may differ in between Tachyon revisions. | To allow service centers to use a unique Memory Stick for multiple PSP models during servicing, Lib-PSP iplloader deliberately disables the XOR step, allowing a non XORed IPL to run from Memory Stick. This is done so that the IPL can run on all systems from 01g to 11g. This is also presumably done because XOR keys may differ in between Tachyon revisions. | ||
This allows a potential attacker with the ability to enable Jig mode on a targeted PSP to bypass the XOR step and thus not requiring to know the XOR key to gain execution at IPL time assuming that all other checks (Kirk cmd 1, Kirk cmd 1 ECDSA, Kirk cmd 0x6C SHA1 (on Tachyon 0x00600000 and later), ...) are passed. | This allows a potential attacker with the ability to enable Jig mode on a targeted PSP to bypass the XOR step and thus not requiring to know the XOR key to gain execution at IPL time assuming that all other checks (Kirk cmd 1, Kirk cmd 1 ECDSA, Kirk cmd 0x6C SHA1 (on Tachyon 0x00600000 and later), ...) are passed. | ||
== iplloader clears the XOR key after doing a cache sync during normal execution == | == Lib-PSP iplloader clears the XOR key after doing a cache sync during normal execution == | ||
Found by: Proxima - Earliest discovery: 2020-01-27 | Found by: Proxima - Earliest discovery: 2020-01-27 | ||
Introduced: iplloader 3.5.0 | Introduced: Lib-PSP iplloader 3.5.0 | ||
Applicable to: Dumping the iplloader 3.5.0 XOR key from Jig mode execution when used in conjunction with the arbitrary load address vulnerability | Applicable to: Dumping the Lib-PSP iplloader 3.5.0 XOR key from Jig mode execution when used in conjunction with the arbitrary load address vulnerability | ||
Fixed: probably never as 3.5.0 is the last known iplloader revision for Development Tool | Fixed: probably never as 3.5.0 is the last known Lib-PSP iplloader revision for Development Tool | ||
3.5.0 iplloader clears the XOR key after doing a cache sync during normal execution. This allows to retrieve the key from the uncached memory at address 0xA001088C. | 3.5.0 Lib-PSP iplloader clears the XOR key after doing a cache sync during normal execution. This allows to retrieve the key from the uncached memory at address 0xA001088C. | ||
In Jig mode execution, the key is cleared much earlier, however resulting in the cache being synced once the key is already gone. This allows to easily retrieve the key using a XORed IPL block loaded at address 0xBFE01000. | In Jig mode execution, the key is cleared much earlier, however resulting in the cache being synced once the key is already gone. This allows to easily retrieve the key using a XORed IPL block loaded at address 0xBFE01000. | ||
While it may be possible that Tachyon 0x00600000 and later iplloader fix this issue, it is irrelevant because the code should remain accessible as part of the Tachyon bootrom at address 0xBFC00000) | While it may be possible that Tachyon 0x00600000 and later Lib-PSP iplloader fix this issue, it is irrelevant because the code should remain accessible as part of the Tachyon bootrom at address 0xBFC00000) | ||
== Faulty ECDSA Hash Comparison == | == Faulty ECDSA Hash Comparison == | ||
| Line 1,158: | Line 177: | ||
Fixed: never | Fixed: never | ||
Starting with Tachyon 0x00600000, iplloader XORs each IPL block hash as they are loaded, and then uses this final XOR to verify the signature. | Starting with Tachyon 0x00600000, Lib-PSP iplloader XORs each IPL block hash as they are loaded, and then uses this final XOR to verify the signature. | ||
This means that inserting two identical blocks in the chain will cancel the XOR change and the signature will remain valid. | This means that inserting two identical blocks in the chain will cancel the XOR change and the signature will remain valid. | ||
NOTE: For this to work, the block checksum of the inserted blocks has to be "forged" so that it matches the one of the previous block checksum | NOTE: For this to work, the block checksum of the inserted blocks has to be "forged" so that it matches the one of the previous block checksum | ||