17 ms·
Attacking Titan M with Only One Byte
- userbinator 4y agoA 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.
- tialaramex 4y ago> hide secrets from its owner. 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.
- ClumsyPilot 4y agowell there are cases where owner and current user aren't one and the same. Like an ATM terminal, or when someone else is using your computer. The whole security landscape seems to have many catch-22's
- IncRnd 4y ago> 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.
- nyanpasu64 4y agoSafetyNet 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.
- IncRnd 4y agoThat's a great example. Thanks!
- ZeroCool2u 4y agoThis 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?
- posnet 4y agoRemote 0-day onto all google internal infra?
- ClumsyPilot 4y agothats literally worth billions, and could be sold to many governments. If thr right people don't buy these zero-days, yhe wrong people will.
- shadowtamperer 4y ago
- solmanac 4y agoProbably an error-shift-encoded one-time pad scheme. The post is the publicly distributed ciphertext.
- google234123 4y agoBillions? couldn’t a government just get a person affiliated with them hired by google?
- saagarjha 4y ago
- lnyng 4y agoFor a moment I thought this is something related to the anime
- Stevvo 4y agoMyself pulled in hoping for a historical tale of attacking vulnerabilities in Titan ICBMs.
- flyaway123 4y agoJust curious - if the usage of acronym here a soft-euphemism? (So that only those who knew or care to know gets it) edit: Thanks for the clarifications. That helps. I'm asking for 2 reasons: 1. Discussing "nukes" openly where I come from would raise some eyebrows. 2. I see acronyms used on HN frequently - sometimes ambiguously even considering the context.
- HideousKojima 4y agoI don't think so, people could just say "nukes" but there are plenty of nukes that aren't capable of hitting targets halfway around the world. ICBM seems like the fastest way of saying "nukes that can hit stuff really far away" while also making a distinction from sub launched and cruise missile launched nukes.
- tialaramex 4y agoThe payload on the missile doesn't need to be a nuclear weapon of any sort. The important thing about the ICBM is that being further away doesn't stop it. Nuclear weapons are the obvious choice because it's hard to imagine why you want to strike something so very far away, at such great expense, with conventional explosives. The German V2 rocket from World War II has a maximum range of about 320km. So you literally can't fire one from say Berlin to London. They were actually launched from coastal sites in the Netherlands and other occupied countries, and as the Allies took territory after Overlord, the targets changed to cities nearer Germany because the launchers were pulled back.
- 2OEH8eoCRo0 4y ago> 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 4y ago[deleted]
- vlovich123 4y agoThe 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?
- deleted 4y ago[deleted]
- teo_zero 4y agoAIUI, they didn't inject code, just mangled the stack to hijack the execution flow towards specific code fragments ("gadgets") already in the executable memory.
- keepquestioning 4y agoHmm, doesn't ARM have mitigation against Return oriented Programming
- pmalynin 4y agoYeah 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.
- muricula 4y agoPAC (pointer signing) & Branch Target Identification are not available on 32 bit arm chips, and judging by the assembly in the blog post the Titan M is a 32 bit chip.
- saagarjha 4y agoThere's a new PAC specification for ARMv8-M: https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/armv8-1-m-pointer-authentication-and-branch-target-identification-extension https://community.arm.com/arm-community-blogs/b/architecture...
- deleted 4y ago[deleted]
- ISL 4y agoI'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.
- bumbledraven 4y agoIt'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…
- rob_c 4y agoVery 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...
- nickzana 4y agoIsn'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.
- rob_c 4y agoThen sell a dev unit surely, not a consumer grade device...
- dmitrygr 4y agoIf 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.
- deleted 4y ago[deleted]
- trhway 4y agoSounds 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.
- atwood22 4y agoMost 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.
- trhway 4y agoIt 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.
- tialaramex 4y agoYou 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.
- atwood22 4y agoYes, 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.
- alexbakker 4y agoThis is amazing work! 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.
- mastax 4y ago> 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.
- sedatk 4y agoThey missed the opportunity to call the article "Attack on Titan M".