Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Attacking Titan M with Only One Byte

blog.quarkslab.com

Post reply on HN
Print view View original

71–80 of 84 posts

Re: Attacking Titan M with Only One Byte

#71

Post by mastax »

> 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.

Re: Attacking Titan M with Only One Byte

#72

Post by tialaramex »

trhway wrote: post #69
atwood22 wrote: post #66

Earlier quoted context omitted.

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.

It is unrelated. For example the input may be used only as a parameter for reading operations - ie. one can easily imagine a situation where even in a safest language using un-validated input may result in a call/query producing info outside of what would be expected for valid parameters.

You can create special purpose languages which lean on type safety heavily to just outright forbid this sort of error at compilation. "This is an untrusted input byte, those range from 0 to 255, so the rest of the code must work for all values in that range or else that's a build error".

Languages like that aren't going to be suitable for writing a whole web browser or a desktop operating system, but they might well be enough for the Titan chip. This is the sort of work where the compilation is tricky (definitely wouldn't fit on a small ARM core) but the machine code it spits out is much the same except safe.

Re: Attacking Titan M with Only One Byte

#73

Post by atwood22 »

trhway wrote: post #69
atwood22 wrote: post #66

Earlier quoted context omitted.

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.

It is unrelated. For example the input may be used only as a parameter for reading operations - ie. one can easily imagine a situation where even in a safest language using un-validated input may result in a call/query producing info outside of what would be expected for valid parameters.

Yes, one can always imagine such a scenario. However, more often than not, real discovered vulnerabilities (that is, vulnerabilities in the real world, not some hypothetical situation) seem to exploit permissive memory modification in C/C++. In the scenario you describe, even discovering the vulnerability would require deeply understanding the application logic. In the vulnerability discussed here, simply fuzzing was enough to discover the vulnerability because it was easy to detect the invalid memory access.

Re: Attacking Titan M with Only One Byte

#74

Post by thrtythreeforty »

rob_c wrote: post #65
dmitrygr wrote: post #61

Earlier quoted context omitted.

Yes i do. done it. at home. for fun. Which means anyone motivated to do it can easily get it done too..

With data intact after etching a custom PCB for a custom chip? I'd be impressed if that skillset overlaps with someone hacking bytecode

I bet that skillet overlaps more than you think. Especially once you consider motivated teams of two or three.

Re: Attacking Titan M with Only One Byte

#75

Post by [deleted] »

ZeroCool2u wrote: post #2

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 compromisi…

[deleted]

Re: Attacking Titan M with Only One Byte

#76

Post by [deleted] »

2OEH8eoCRo0 wrote: post #4

> 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.

[deleted]

Re: Attacking Titan M with Only One Byte

#77

Post by rob_c »

thrtythreeforty wrote: post #74
rob_c wrote: post #65

Earlier quoted context omitted.

With data intact after etching a custom PCB for a custom chip? I'd be impressed if that skillset overlaps with someone hacking bytecode

I bet that skillet overlaps more than you think. Especially once you consider motivated teams of two or three.

Again this additional step slows down an attack which discourages people from attacking the product. If it achieves this it's a valid step as part of a security strategy.

No single solution/step is 100% secure, if you think that, throw your devices away now because they're probably already compromised.

Stop with the ego pedaling security stuff and live/work in the real world where small changes have real positive impacts.

It's the same with DRM. It doesn't have to be uncrackable, as long as it keeps the sales for the first x-months it's worked. (Not that I think DRM is acceptable but that's another discussion).

Re: Attacking Titan M with Only One Byte

#78

Post by wyldfire »

keepquestioning wrote: post #44
teo_zero wrote: post #36

Earlier quoted context omitted.

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.

Hmm, doesn't ARM have mitigation against Return oriented Programming

There's multiple mitigations, including some compiler passes IIRC. But the pointer auth hardware ones defined by ARM were probably specified after Titan M's original design.

Re: Attacking Titan M with Only One Byte

#79

Post by wyldfire »

ZeroCool2u wrote: post #2

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 compromisi…

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.

[1] https://duo.com/decipher/hack-the-titan-m-get-usd1-million

Re: Attacking Titan M with Only One Byte

#80

Post by dmitrygr »

rob_c wrote: post #77
thrtythreeforty wrote: post #74

Earlier quoted context omitted.

I bet that skillet overlaps more than you think. Especially once you consider motivated teams of two or three.

Again this additional step slows down an attack which discourages people from attacking the product. If it achieves this it's a valid step as part of a security strategy. No single solution/step is 100% secure, if you think that, throw your devices away now because they're probably already compromised. Stop with the ego pedaling security stuff and live/work in the real world where small changes have real positive imp…

Sometimes, idiotic moves like that DRAW people to your product who'd otherwise pass it by. The only reason cypress got publicly embarrassed by their secure rom being completely broken [1] was because the way they talked about it annoyed me.

[1] http://dmitry.gr/?r=05.Projects&proj=23.%20PSoC4

Post reply on HN