TCG TPM2.0 implementations vulnerable to memory corruption | Hacker News Reader

TCG TPM2.0 implementations vulnerable to memory corruption

kb.cert.org

106 pointstodsacerdoti24 comments

It took 4 years to notice a memory corruption bug in the reference implementation of the main security solution deployed in 1 billion+ computers...

you can assume in good faith that this is barely used feature generally but also most implementations are not really vulnerable so they might have checked but couldn't find anything actually wrong, so there might have been a tremendous amount of effort to actually secure most implementation, on the other hand...

Got it why I was downvoted. But honestly don't get why parent is the most voted comment on this thread. Maybe I am just super dumb ...

I guess they should've written in rust.

If nothing else, arguing about "unsafe" between managers, or even lawyers, between orgs, would be fruitful in new ways.

TPM 2.0 first appeared on the market in 2014. Rust first appeared in 2015. And Rust took a while to become a mature system. TPM 2.0 was also an improved version of TPM 1.2, which came out in 2009.

So... maybe if Rust was a decade earlier.

Announced then, sure, that's a fine cutoff date. It did show clear promise before then in servo.

Rust can still be a standard going forward.

Better tools, better programs, Rust lang.

For something like TPM, IMO, using a memory safe architecture should be table stakes nowadays. I would go further: the design should be as simple as possible to achieve its requirements, and the implementation should be formally verified.

Interesting article if light on technical detail. I wonder how long until this becomes used for either (a) DRM key extraction (Good!) (b) horrible, semi-permanent rootkits, (c) for unwitting fde key extraction scheme, or (d) to further push Microsoft's über-DRM-HSM Pluton even further.

Most TPM chips are unaffected. Those that are will get new firmware. Virtual TPMs are affected because those are implemented using a TPM simulator based on the TCG code that has this bug. In all cases any compromise should be of the local host, not of other things unless those things are accessed using keys stored on the affected TPM. In any affected cases where the TPM can be replaced then the simplest recovery method starts with replacing the TPM and rebuilding the host then re-running any enrollment protocols that need to be re-run, otherwise flashing a compromised TPM while running on a system that can have been rootkitted is a problem.

By virtual TPM you mean the implementation on modern Intel and Ryzen platforms in the cpu correct? If so does that mean that a firmware/bios/microcode update will be able to patch the vulnerability on those machines?

I would not assume so as these are firmware implementations and as such would not use the simulator directly

edit: also look at the link you can see clearly that Intel is not effected but AMD is unknown...

No, I mean a swtpm running in a hypervisor and presented to a VM as a discrete TPM.

>horrible, semi-permanent rootkits,

TPM (read: SecureBoot) or no, the only proper response to a computer exposed to even the possibility of a rootkit that can't be removed is wholesale replacement.

TPMs are used for Measured Boot, not Secure Boot (although the Secure Boot configuration is one of the things that's measured). Secure Boot exists on platforms that don't have TPMs.

Maybe we'll see the return of "Trusted Third Party" schemes.

In a way, this is a nice balance for everyone (:P / /s / I'm sorry to say). Corporate interests get "good effort" security, almost something you could legal distinguish and prosecute for bypassing. And hobbyist users get repeatable workarounds.

It's impressive in attempted scope. I imagine this doesn't affect google's chromebook boot chain. It's really hard to coordinate across vendors.

Apple phone jailbreaks were easy on the iPhone 3, and have slowly gotten harder since then. TPM3 will be stronger than TPM2, but the only way we get there is by making mistakes and learning from them.

For someone doing related work in the open (and least remarkably in the open), Oxide Computer told some storied about the difficulty of bring up of a new motherboard, and mentioned a lot of gotcha details and hack solutions for managing their AMD chip.

They talked about their bring up sequence, boot chain verification on their motherboard, and designing / creating / verifying their hardware root of trust.

I heard mention of this on a podcast recently, trying to find the reference. I'm pretty sure it was [S3]

- "Tales from the Bringup Lab" https://lnns.co/FBf5oLpyHK3

- or "More Tales from the Bringup Lab" https://lnns.co/LQur_ToJX9m

But I found again these interesting things worth sharing on that search.

- https://oxide.computer/blog/hubris-and-humility, see https://github.com/oxidecomputer/hubris as some of their key enabling software/firmware, custom written—-tradeoffs discussed in podcast.

- Search 1 [S1], Trammell Hudson ep mentioning firmware (chromebook related iirc) https://lnns.co/pystdPm0QvG.

- Search 2 [S2], Security, Cryptography, Whatever podcast episode mentioning Oxide and roots of trust or similar. https://lnns.co/VnyTvdhBiGC

Search links:

[S1]: https://www.listennotes.com/search/?q=oxide+tpm

[S2]: https://www.listennotes.com/search/?q=oxide%20and%20friends%...

[S3]: https://www.listennotes.com/search/?q=oxide%20and%20friends%...

Not all implementations are actually vulnerable as there are dependencies on implementation details.

Hard to gage whether on Windows one has access to these APIs without being an Administrator.

I’m a total security noob, but I’d wager that privilege escalation is a piece of cake relative to key extraction from a TPM.

Not on fully secured Windows with Device Guard, Credential Guard, HVCI and mitigations on it is not.

The defaults are lax garbage though.

The article says "authenticated user".

How many implementations out there are actual just copy paste of the reference c code?

Reply on news.ycombinator.com