AMD PSP: Firmware TPM Remote Code Execution via Crafted EK Certificate
seclists.org
seclists.org
And to make matters worse at least for Intel we have indications that those security wholes are the result of a calculated risk to afford a higher development velocity: https://danluu.com/cpu-bugs/
This year is going to be fun...
This function is called from TPM2_CreatePrimary with user controlled data - a DER encoded [6] endorsement key (EK) certificate stored in the NV storage.
If I understand correctly, this is related to SecureBoot and to do such operations with the keys and certificates, the user has to have physical access to the BIOS/UEFI setup already, correct?
https://developer.arm.com/products/processors/cortex-m/sc300...
It’s a joint venture between ARM, Gemalto and a few other companies iirc.
*Trusted Execution Environment
AMD hasn't really had any hardware for the enterprise for a long time so they are quite behind on many things.
This is their free remote admin tool : https://community.amd.com/community/devgurus/dmtf-dash/blog/...
It can basically do quite a few things, change firmware, boot an image, redirect USB input and likely quite a few of other undocumented things.
With Ryzen Pro launching soon I guess AMD would release a new suite of remote management software.
With this flaw, someone can just stick a bootable USB stick in your computer to mirror the LUKS/bitlocker disk drive and get access to the keys in the TPM which protect that drive.
The PSP is an ARM core
2017-09-28 - Vulnerability reported to AMD Security Team.
2017-12-07 - Fix is ready. Vendor works on a rollout to affected partners.
2018-01-03 - Public disclosure due to 90 day disclosure deadline.
"Timeline ======== 09-28-17 - Vulnerability reported to AMD Security Team. 12-07-17 - Fix is ready. Vendor works on a rollout to affected partners. 01-03-18 - Public disclosure due to 90 day disclosure deadline."
Maybe, the keys in the PSP are still protected by secure computing technology, like ARM TrustZone…
We're going back to pen and paper. The extra safety makes the hassle worth it.
I'm happy because it's gonna have to change. Whole stack revisited. Eventually. These things speed it up. On the long run, the thing that holds most value, in my opinion, is information. Not physical things, not energy, information. Bitcoin is a big step in that direction but I don't just mean cryptocurrencies. If you can't keep your information secret the value is destroyed.
I see two paths. One, we do a huge refactoring of how do we do computations. Super clear assumptions and provably building simple layers on top of that. I'd like that. The other one is that we keep this whole messy legacy. And security will become based on more and more layers and heuristics. Which would eventually become AIs competition. Brr.
Just some random ponderings, I'm not a security expert.
We've done more or less that several times in computing: At first the code just ran on the computer and had full access to everything. Soon we got memory protection, privileged instructions, and operating systems. Then we got rings of security, virtual memory, virtual machines, etc.
We can do it again.
I used to believe this kind of thing, but now I think you greatly underestimate human indifference and interest in effort conservation (uncharitably called "laziness").
Look at Intel's response to Spectre/Meltdown. Are they going back and redesigning their microarchitecture with new hardware-enforced safety rings [that actually enforce, lol] and new ways to block timing attacks without sacrificing performance? Seriously doubt it. From LKML it sounds like they're just going to hardware-accelerate IBRS/IBPB to make it faster to shut down branch prediction in risky situations and leave the rest of the shebang as-is.
Even when the forecasted apocalyptic events occur, it's amazing how little anyone cares, or how little gets recognized. Surely there are people who've speculated (ha!) attacks like Spectre/Meltdown, given the knife's edge nature of hardware virtualization on x86, and advised against multi-tenancy. Surely there are people who have paid attention over the last ten years to the dozens of sandbox escape attacks that already exist without exploiting the microarchitecture! Are they getting their due? Is anyone asking why people didn't consider these possibilities or listen to the people who warned them? Nope, because they just don't want to hear that. It's all "Oh gee how could Intel have done this to us?!" when "How could you have acted like this was safe" is an at least equally valid question.
TPMs, again, are another example of exactly the same thing. Major exploits in them are 100% routine by now. Does anyone care? Google is quietly working to remove them from their own machines but it doesn't seem like anyone is going to get any real headway outside of that. Do freedom advocates like RMS get their due? Nope, they just get told "Bugger off with your 'I told you so'."
Have you ever spent months or years warning your bosses about something, only to have that thing happen, and watch them hand-wave it away and get extremely irritable after you mention that they had fair warning? Most semi-aware engineers probably have, because this happens constantly.
Admitting, realizing, and honestly correcting our mistakes is just not a thing that people do, unless they feel substantial direct and personal pain that the brain decides greatly exceeds the forecasted effort expenditure to correct the issue. Such negative force cannot be applied over an industry at large unless there is a very specific and coordinated demand from the handful of people at the tippy-top, as in the case of Spectre/Meltdown, since in the age of cloud computing, those exploits fundamentally jeopardize the profitability of every major tech company.
Let me answer that for you. In the period of the last 10 years, the world has all but switched to mobile devices. Mobile devices that make windows look like a secure operating system. In theory vendors promise 2 years of "safe" operation, and I am unaware of a single case where they actually shipped phones without major security vulnerabilities (and known, to at least some of their development team).
Internationally, iPhones do not matter. They're like 10% of the market, so I'm focusing on android phones here. And it's not like iPhones don't have exploits for them, it just means a few more years, something more like 4 year, until they're exploitable.
It is regularly reported that 40% of all android phones are vulnerable to individual vulnerabilities. At least half of all active android phones do not receive security updates, even in the case of serious vulnerabilities (and that patched "half" technically is described as anyone who ever got at least a single security update). How many of the total amount of android phones are trivially hackable if you run an app on them ? I'm going to say at least 75%, and at least including all phones more than 2 years since they were released.
So no. Nobody cares. We all know how bad the wintel situation is, and android is worse.
We need a global security disaster to happen so totally that regulators intervene and hold these vendors accountable.
If we are to change behavior of consumers, we have to work with their natural motivation. I think the most realistic plan is to subsidize core infrastructure with enough high-quality opensource software and hardware to drive commercial interest out of all security-sensitive components.
It's like when Wikipedia is subsidized by its editors to provide the common good of education. Opensource can be similarly subsidized by developers to provide the common good of security.
Are you referring to Chromebooks or Google's cloud server hardware? Are the TPMs being replaced with a proprietary hardware enclave?
https://cloudplatform.googleblog.com/2017/08/Titan-in-depth-...
Notable quote:
"Google designed Titan's hardware logic in-house to reduce the chances of hardware backdoors. The Titan ecosystem ensures that production infrastructure boots securely using authorized and verifiable code."
This is what we need. Authorized and verifiable code, none of this opaque binary blob BS.
If you by some circumstances had a terrific clean and tidy system in a functional language, wouldn't that offer a higher level of possible "primitive" operations?
Also, more practically, two computers with different ISA and underlying hardware that compute the exact same high level semantics, that don't know each other but transparently share the necessary hardware (for example hardware random number generator), talking to the world through a simple electronic checker, that stops the system if both computers don't communicate exactly the same information bit by bit, is also pretty safe, even if you use backdoored computers. Just make sure both computers don't contain identical backdoors (which is not that difficult).
High and sufficient security in computer systems is practically possible. We just don't work at it. Instead we work on JavaScript and WebAssembly and proprietary hardware and software.
It's the complexity of everything that we do with computers that needs to be addressed, not just the quality of software and hardware testing and exploit mitigation. Mitigation techniques can't stop every unknown exploit, just some of them; in a sufficiently complex system there always will be a way to break the system in an unexpected and conceptually new way. Besides, they are additional layers of complexity on their own, and you can't fight complexity with complexity.
See also the responses: https://news.ycombinator.com/item?id=16083256
Especially "613.pdf" linked by NickPSecurity.
Isn't WebAssembly a huge step forward in the ability to distribute portable, high-performance, sandboxed code?
Besides that, the appification of the web is bad because it leads ultimately to dependency on software that is outside of the users control.
These are two reasons why developing and supporting WebAssembly is finally against the interest of the users.
> Anything you can do in wasm you can do in JavaScript, only was can do it faster.
It's faster and more flexible because it can easily be targeted by compilers. That is the problem. This might sound surprising. Allow me use an analogy to explain it.
Let's assume some new technology was invented to more easily breed cattle for meat production. I completely understand why some people would want that, and develop it. I think breeding and killing cows and bulls just to eat a steak is unethical. So, I would absolutely refuse to work on the technology, and I'd expect the same of everybody that cares about being ethical.
Now, coming back to JavaScript and wasm, it is used to deploy code in a way that takes the control of the software from the users to the developers. The deployed code is unreviewed, unaccounted, unsigned and executed automatically. I consider unsafe in the computing sense. So, I consider code execution on the web unacceptable. Since, wasm makes that easier and more efficient, I'm opposed to it.
On top of that I consider JavaScript a bad language. I'm worried by how much it's pushed as a teaching language.
I can see where you are getting confused. It is actually just faster. Again, there is nothing you can do is wasm that you can't already do it javascript.
> The deployed code is unreviewed, unaccounted, unsigned and executed automatically. I consider unsafe in the computing sense. So, I consider code execution on the web unacceptable.
All of these things apply to javascript.
> On top of that I consider JavaScript a bad language. I'm worried by how much it's pushed as a teaching language.
This has absolutely nothing to do with anything in this thread. It is pretty clear that you have biases and frustrations that have nothing to do with technical merits.
I'm also not enthusiastic about how it's more secure from governmental snooping to mail a hard drive than it is to send its content over the Internet.
I've read that, several years ago, parts of the Russian security establishment switched to mechanical typewriters.
https://www.theguardian.com/world/2013/jul/11/russia-reverts...
Even in Germany high officials hinted at using mechanical typewriters:
https://www.theguardian.com/world/2014/jul/15/germany-typewr...
Luckily, the politicians in Germany and Europe wake up. They want to build up European chip and hardware facilities to have the full chain in Europe. Also they plan to demand certification and customer visible labels. Finally!
https://www.heise.de/newsticker/meldung/Prozessor-Luecken-Me...
This is the same Thomas de Maizière that backed a law that allows German law enforcement agencies to order companies to insert back doors in their products:
So far similar efforts by EU were rather underwhelming - but this one is probably the most important. I believe EU is the only global actor that can achieve the goal of creating reliable hardware and software. The still decentralized nature of EU means that no partner can afford any unilateral action (like backdoors) - and a conspiracy on the level of whole EU is impossible.
And of course it needs to be Open Source.
I think that anyone who has worked professionally understands that it's a miracle we make it through life with the relatively limited quantity of exposures and accidents that we have. Things like Spectre/Meltdown usually don't get the notice of people who care to expose it publicly until they've been privately theorized, discussed, and practiced in some form for many years.
Personally I believe that if Spectre had come out 10 years prior, the likely response from Linus et al would've been "How about instead of crippling useful CPU speed optimizations, we just don't let random people feed instructions to our CPUs." Obviously, with cloud computing underpinning so much critical profit/surveillance-- uh, I mean, infrastructure-- these days, that won't fly. (Meltdown is a different story since the CPU is supposed to be protecting that.)
Computers are very complex systems designed by people. Work with more than 5 people and you quickly learn how much trust is warranted in complex systems designed by people (hint: very little).
I absolutely believe that relying on the security properties of the physical world, particularly "this item cannot exist in more than one place at a time, nor can it be replicated and transmitted across the earth in under one second", is much more reliable than any computer security.
Pen and paper is the only way to go for the truly paranoid.
So it's not unknown. But as a counterpoint I had a shocking moment in the 90's when I learned that Faraday Cages (to prevent TEMPEST attacks) were being designed with a second Faraday cage inside them to protect the light bulbs.
Seems that the interference between a CRT and a fluorescent bulb are sufficient that you can detect information on the power lines leading into the room. So they caged the bulbs to keep them magnetically isolated from the computers.
However, side channels exist. If you write classified information on a correspondence pad, then the pad itself becomes a classified item, too. Obviously.
What if there is a fire? Do you keep a copy of the files somewhere? How do you control access to those?
On the other hand, also the bad part is that pen and paper require actual physical access to read ;)
A data breach would be catastrophic for us. We lose less money this way.
Can a business that runs on pen and paper compete in 2018? Have you included lost revenue due to inefficiency?
Want my job?
Glad someone proved them wrong, and that hopefully we'll get a proper killswitch for these backdoors.