iQue Player System Flaws

From iQueBrew
Revision as of 00:28, 29 April 2018 by SciresM (Talk | contribs) (Secure Kernel: memes)

Jump to: navigation, search

Hardware

Summary Description Timeframe this was discovered Discovered by
No known hardware exploits

Secure Kernel

Summary Description Successful exploitation result Timeframe this was discovered Discovered by
psychic paper: Secure Kernel could incorrectly consider a self-signed certificate chain as valid The function for verifying certificate chains at 0x9FC028BC is passed an array of pointers to certificates.

For the first 5 elements, it checks to see if the certificate was issued by Root, if so it checks if the certificate was signed by the hardcoded Root public key (and returns immediately with the result).

If the certificate wasn't signed by Root, it checks if the certificate was signed by the public key of the next certificate in the array.

If all 5 certificates verified correctly, the function will return success.

Assuming this function can be called with an attacker-controlled array of certificates, self-signing of certificates (and thus, arbitrary code execution, with full non-Secure Mode privileges)

(This is not the case for Secure Applications, the code in SK for verifying those sets up a hardcoded array on the stack for the certificate verification function)

April 2018 Riley
skcPrepareCMDAndTik and skc04 leave CMD in memory if its signature does not verify The function called by skcPrepareCMDAndTik (and skc04) at 0x9FC00BAC verifies ticket and CMD, and decrypts the titlekey.

After verifying the ticket signature, it copies the CMD to another place in memory, derives the titlekey encryption key, decrypts the titlekey with the titlekek, then verifies the CMD signature.

If the CMD signature does not verify successfully, the function just returns an error, leaving the unsigned CMD in place.

Most of the code that uses a CMD in SK uses the CMD in that place in memory that this function copies the CMD to, and trusts that whatever data is there has been verified already.

The entire CMD is covered by the ticket signature anyway, so this isn't that useful really, besides potentially making psychic paper easier to exploit.

With existing code execution with access to skcPrepareCMDAndTik or skc04 and some other SKC that uses SK's internal CMD copy (only non-test SAs have this level of access), and the ability to sign a ticket but not a CMD:

Allowing the use of an unsigned CMD by SK, potentially leading to privilege escalation (by specifying arbitrary allowed hardware access/allowed SKCs).

April 26, 2018 Riley
skcStartContent does not check content hash if recrypt flag is set in CMD skcStartContent calculates the SHA1 hash of the content and compares it to the value in the CMD, returning an error if the hash doesn't match. This entire block of code is jumped over if the recrypt flag is set in the CMD. With plaintext of an application with the recrypt flag set in its CMD, arbitrary code execution (via, for example, implementation of the attack described in pocorgtfo17) Early 2018? Everyone
skcVerifySignature signature pointer not validated skcVerifySignature takes in a u8 pointer to a signature to verify, but does not actually validate this pointer is valid before treating the memory it points to as an RSA/ECC signature. Causing the Secure Kernel to data abort -- possibly usable as an infoleak, depending on the provided cert chain April 29, 2018 SciresM

System Applications

Summary Description Successful exploitation result Exploitable System Applications Timeframe this was discovered Discovered by
No known System Application exploits