> … the vulnerable firmware was introduced by Google's Pixel security update of May 2022.
However, further down, in the timeline section, the doc indicates that the issue was reported before May 2022, all the way back in March 2022:
> 2022-03-02: Vulnerability reported. Opened issue 222318108 in Google's Issue Tracker, providing a technical description of the bug and a Proof of Concept (PoC) exploit…
> Thanks to the leak functionality that we built with this exploit, we can now read arbitrary memory on the chip. This means we can now have access to any readable address. As a consequence, we can dump the secrets stored in the chip (such as the Root of Trust sent by the Pixel bootloader when the Titan M is updated).
> One of the most interesting consequences of this attack is the ability to retrieve any StrongBox protected key, defeating the highest level of protection of the Android Keystore. Similarly to what happens in TrustZone, these keys can only be used inside Titan M, while they are stored in an encrypted key blob on the device.
I thought the whole point of making a hardware security chip (rather than using a general purpose microcontroller, possibly with crypto acceleration hardware) is that the private keys would be protected by the hardware design. So you could use the private key to e.g. create a digital signature but its impossible to read out the private key itself, outside of potential side-channels.
I was surprised to see that the reward was set at 10k initially. Granted, it was bumped to 75k later, but even that seems on the low side considering the degree of compromise that occurred here.
I may have given up too early during my (fairly brief) research on CVE-2019-9465. I let the lack of firmware source code availability stop me at the time, but in hindsight the presence of
"0dd0adde0dd0adde" in the ciphertext likely indicated a crash in Titan M as well. Perhaps there would have been a similarly interesting path to exploitation there.
I wonder why companies still leave the UART pins accessible. Fine they're on the chip, but just remove the trace and slow down attack evolution is worth the cost of a board revision surely...
Isn't it better to leave them exposed and make it easier for security researchers who genuinely want to test the chip? Someone interested in and capable of developing and using/selling an exploit won't be deterred by needing a special cable to get a UART console, whereas a security researcher might appreciate the simpler access.
So long as it doesn't weaken the actual security model, companies should make their products as easy to analyze as possible imo.
If THAT is your idea of security, i hope you do not work on any hardware whose security matters. First thing anyone would do is find the pins and connect to them. It buys you nothing, and if anything tells me that i should go look for them.
Visible and labeled UART pins tell me that you've (hopefully) thought through the consequences of me having access to them. Hidden UART tells me that most likely nobody ever gave that half a thought.
AIUI, they didn't inject code, just mangled the stack to hijack the execution flow towards specific code fragments ("gadgets") already in the executable memory.
Sounds like an amateur hour at that Google team. While post authors are putting blame on the un-safeness of C, absence of user input validation, like that integer from a message, is a path to a very unhappy place independent of language. The rest of the exploited places of that Titan software seem to be similarly sloppy.
Most languages don't let you (or at least make it hard to) directly convert user input into memory locations though. The scope of the issue in other languages would likely be much more limited.
This is an elegant attack that effectively compromises all Titan M chips. They were even able to dump all securely stored private cryptographic keys, which Google acknowledges in the disclosure timeline.
Even still though, the award Google initially gave was only $10k USD(!). They finally bumped it to $75k USD after complaint and review, but Google's bug bounty program claims up to $1 Million USD.
If fully compromising Google's own security chip to dump all private keys isn't worth the full $1 Million bounty, I honestly don't know what is.
Really, what would, in the mind of those on the internal committee, constitute justification for the $1 Million bounty?
From my point of view, the fact that the exploit required either to run as root on a rooted device (or alternatively direct access to an internal serial bus) is enough to justify not paying at the top level.
These things should probably be more transparent, but I would assume the $1M level would be for exploits that could be deployed on a fresh-from-the-box device with no rooting/mods.
Quoting a random article from when this was initially announced:
> Google says that if researchers manage to find "a full chain remote code execution exploit with persistence" that also compromises data protected by Titan M, they are willing to pay up to $1 million to the bug hunter who finds it.
So a compromise that doesn't require physical access or root, presumably.
Cue also the inevitable discussion that bug bounties are too low.
Google bug bounty program is a sham. When I tried to report critical vulnerability in their authentication system, they told it's a 'feature' and threatened to sue if I disclose.
Then fixed it in two and a half years, and wrote an article on how complicated bug they just found and how proud and secure they are with their pentesters.
This article [1] includes a quote describing a specific vulnerability that would pay the $1 million.
> "We are introducing a top prize of $1 million for a full chain remote code execution exploit with persistence which compromises the Titan M secure element on Pixel devices. Additionally, we will be launching a specific program offering a 50% bonus for exploits found on specific developer preview versions of Android, meaning our top prize is now $1.5 million," Jessica Lin of the Android security team said.
> The Titan M bounty applies to the Google phones that have the chip, which include the Pixel 3 and 3 XL, 3a and 3a XL, and 4.
i would imagine higher bounty would be for extracting device keys. from my reading this exploit would not allow you to extract the key needed to unlock a powered off device. im no security expert so please correct me if im wrong
> As a reminder, there are two conditions to perform this attack. First, we need to be able to send commands to the chip, either from a rooted device (required to use nosclient), or physically accessing the SPI bus.
> Then, we need a way to access the key blobs on the Android file system, which can be done again by being root, or with some exploit to bypass File Based Encryption or the uid access control.
It makes sense to use exactly the same technology even if you are "the owner" unless you are somehow only ever running software you wrote on data you obtained, and maybe not even then if other people are able to influence that data.
Most of use a lot of software we didn't write, to process data we got from some third party who may or may not have our best interests in mind.
> Don't lose sight of the fact that the purpose of this and other TPM-like devices is to hide secrets from its owner.
That's a complete misunderstanding of a TPM's security model. A TPM guards against key theft in a compromised environment by securely storing artifacts and authenticating the platform. The user doesn't enter this threat picture. It is the platform that gets authenticated, not the user.
[+] [-] ISL|3 years ago|reply
After something went wrong, a bunch of things went right very quickly. Nice to have good news on a Monday morning.
[+] [-] bumbledraven|3 years ago|reply
> … the vulnerable firmware was introduced by Google's Pixel security update of May 2022.
However, further down, in the timeline section, the doc indicates that the issue was reported before May 2022, all the way back in March 2022:
> 2022-03-02: Vulnerability reported. Opened issue 222318108 in Google's Issue Tracker, providing a technical description of the bug and a Proof of Concept (PoC) exploit…
[+] [-] mastax|3 years ago|reply
> One of the most interesting consequences of this attack is the ability to retrieve any StrongBox protected key, defeating the highest level of protection of the Android Keystore. Similarly to what happens in TrustZone, these keys can only be used inside Titan M, while they are stored in an encrypted key blob on the device.
I thought the whole point of making a hardware security chip (rather than using a general purpose microcontroller, possibly with crypto acceleration hardware) is that the private keys would be protected by the hardware design. So you could use the private key to e.g. create a digital signature but its impossible to read out the private key itself, outside of potential side-channels.
[+] [-] alexbakker|3 years ago|reply
I was surprised to see that the reward was set at 10k initially. Granted, it was bumped to 75k later, but even that seems on the low side considering the degree of compromise that occurred here.
I may have given up too early during my (fairly brief) research on CVE-2019-9465. I let the lack of firmware source code availability stop me at the time, but in hindsight the presence of "0dd0adde0dd0adde" in the ciphertext likely indicated a crash in Titan M as well. Perhaps there would have been a similarly interesting path to exploitation there.
[+] [-] sedatk|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] rob_c|3 years ago|reply
I wonder why companies still leave the UART pins accessible. Fine they're on the chip, but just remove the trace and slow down attack evolution is worth the cost of a board revision surely...
[+] [-] nickzana|3 years ago|reply
So long as it doesn't weaken the actual security model, companies should make their products as easy to analyze as possible imo.
[+] [-] dmitrygr|3 years ago|reply
Visible and labeled UART pins tell me that you've (hopefully) thought through the consequences of me having access to them. Hidden UART tells me that most likely nobody ever gave that half a thought.
[+] [-] vlovich123|3 years ago|reply
I thought I read the whole thing. Did I miss that explanation?
[+] [-] teo_zero|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] trhway|3 years ago|reply
[+] [-] atwood22|3 years ago|reply
[+] [-] ZeroCool2u|3 years ago|reply
Even still though, the award Google initially gave was only $10k USD(!). They finally bumped it to $75k USD after complaint and review, but Google's bug bounty program claims up to $1 Million USD.
If fully compromising Google's own security chip to dump all private keys isn't worth the full $1 Million bounty, I honestly don't know what is.
Really, what would, in the mind of those on the internal committee, constitute justification for the $1 Million bounty?
[+] [-] NovemberWhiskey|3 years ago|reply
These things should probably be more transparent, but I would assume the $1M level would be for exploits that could be deployed on a fresh-from-the-box device with no rooting/mods.
[+] [-] joshuamorton|3 years ago|reply
> Google says that if researchers manage to find "a full chain remote code execution exploit with persistence" that also compromises data protected by Titan M, they are willing to pay up to $1 million to the bug hunter who finds it.
So a compromise that doesn't require physical access or root, presumably.
Cue also the inevitable discussion that bug bounties are too low.
[+] [-] izacus|3 years ago|reply
Probably something that doesn't require physical access to a key for longer time to extract the keys?
[+] [-] posnet|3 years ago|reply
[+] [-] Svoka|3 years ago|reply
Then fixed it in two and a half years, and wrote an article on how complicated bug they just found and how proud and secure they are with their pentesters.
[+] [-] wyldfire|3 years ago|reply
> "We are introducing a top prize of $1 million for a full chain remote code execution exploit with persistence which compromises the Titan M secure element on Pixel devices. Additionally, we will be launching a specific program offering a 50% bonus for exploits found on specific developer preview versions of Android, meaning our top prize is now $1.5 million," Jessica Lin of the Android security team said.
> The Titan M bounty applies to the Google phones that have the chip, which include the Pixel 3 and 3 XL, 3a and 3a XL, and 4.
[1] https://duo.com/decipher/hack-the-titan-m-get-usd1-million
[+] [-] miohtama|3 years ago|reply
[+] [-] rob_c|3 years ago|reply
[+] [-] medo-bear|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] rurban|3 years ago|reply
[+] [-] 2OEH8eoCRo0|3 years ago|reply
> Then, we need a way to access the key blobs on the Android file system, which can be done again by being root, or with some exploit to bypass File Based Encryption or the uid access control.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] lnyng|3 years ago|reply
[+] [-] Stevvo|3 years ago|reply
[+] [-] its_bbq|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] userbinator|3 years ago|reply
Don't lose sight of the fact that the purpose of this and other TPM-like devices is to hide secrets from its owner.
[+] [-] tialaramex|3 years ago|reply
It makes sense to use exactly the same technology even if you are "the owner" unless you are somehow only ever running software you wrote on data you obtained, and maybe not even then if other people are able to influence that data.
Most of use a lot of software we didn't write, to process data we got from some third party who may or may not have our best interests in mind.
[+] [-] IncRnd|3 years ago|reply
That's a complete misunderstanding of a TPM's security model. A TPM guards against key theft in a compromised environment by securely storing artifacts and authenticating the platform. The user doesn't enter this threat picture. It is the platform that gets authenticated, not the user.
[+] [-] ClumsyPilot|3 years ago|reply
The whole security landscape seems to have many catch-22's