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

41–50 of 84 posts

Re: Attacking Titan M with Only One Byte

#41

Post by medo-bear »

ZeroCool2u wrote: post #38
medo-bear wrote: post #24

Earlier quoted context omitted.

> perhaps there's some subtle nuance between device keys and other keys in the chip. Thats what im wondering too. particularly this line from mitigations section from the report >> However, we do want to point out an interesting feature that would have made the StrongBox key blob leak impossible. Indeed, an application can create a key that is authentication-bound, specifying setUserAuthenticationRequired(true) when…

Yeah, okay I definitely missed that part. Makes more sense. Still, the bounty seems shockingly low. They probably could've gotten a lot more for it on the open market.

yeah i think its a noteworthy attack and defn worth more than 10K. also google should be more open about how bug bounties are evaluated

Re: Attacking Titan M with Only One Byte

#42

Post by bumbledraven »

ISL wrote: post #13

I'm very happy to see that a vulnerability introduced in a May 2022 was found, diagnosed, and fixed in a June 2022 update. After something went wrong, a bunch of things went right very quickly. Nice to have good news on a Monday morning.

It's a bit confusing to me. The doc says:

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

Re: Attacking Titan M with Only One Byte

#43

Post by IncRnd »

userbinator wrote: post #6

A lot of software can be cracked "with only one byte". Finding which one is the hard part. Don't lose sight of the fact that the purpose of this and other TPM-like devices is to hide secrets from its owner.

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

Re: Attacking Titan M with Only One Byte

#44

Post by keepquestioning »

teo_zero wrote: post #36
vlovich123 wrote: post #10

The one bit I didn’t understand was how they bypassed W/RX. How did they manage to get the new code to be marked as RX after writing? I thought I read the whole thing. Did I miss that explanation?

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

Re: Attacking Titan M with Only One Byte

#45

Post by NovemberWhiskey »

medo-bear wrote: post #30
NovemberWhiskey wrote: post #27

Earlier quoted context omitted.

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.

is isb access an issue? your phone could get stolen

Sure; but it's a sliding scale, right? Zero-click network exploits are more severe than interactive exploits are more severe than those which require physical access etc.

Re: Attacking Titan M with Only One Byte

#46

Post by nyanpasu64 »

IncRnd wrote: post #43
userbinator wrote: post #6

A lot of software can be cracked "with only one byte". Finding which one is the hard part. Don't lose sight of the fact that the purpose of this and other TPM-like devices is to hide secrets from its owner.

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

SafetyNet and "authenticating the platform" is used for remote attestation, so app authors can deny phones access to apps and services if they're running root/kernel-level CPU code chosen by the user (or also an attacker without access to the phone's OS signing keys) rather than by the phone's manufacturer.

Re: Attacking Titan M with Only One Byte

#47

Post by IncRnd »

nyanpasu64 wrote: post #46
IncRnd wrote: post #43

Earlier quoted context omitted.

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

SafetyNet and "authenticating the platform" is used for remote attestation, so app authors can deny phones access to apps and services if they're running root/kernel-level CPU code chosen by the user (or also an attacker without access to the phone's OS signing keys) rather than by the phone's manufacturer.

That's a great example. Thanks!

Re: Attacking Titan M with Only One Byte

#48

Post by dmitrygr »

rob_c wrote: post #25

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

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.

Re: Attacking Titan M with Only One Byte

#49

Post by pmalynin »

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

Yeah some devices support PAC use that feature to sign return pointers. But not everyone uses it (even when available), and there exist methods to bypass PAC— from attacking the micro architecture to finding signing oracles.

Re: Attacking Titan M with Only One Byte

#50

Post by solmanac »

shadowtamperer wrote: post #37
ClumsyPilot wrote: post #18

Earlier quoted context omitted.

thats literally worth billions, and could be sold to many governments. If thr right people don't buy these zero-days, yhe wrong people will.

Quoted post unavailable.

Probably an error-shift-encoded one-time pad scheme. The post is the publicly distributed ciphertext.
Post reply on HN