
AMD PSP: Firmware TPM Remote Code Execution via Crafted EK Certificate - transpute
http://seclists.org/fulldisclosure/2018/Jan/12
======
JepZ
Yeah, while it seems that every modern CPU is affected by the recently
discovered vulnerabilities, Intel and AMD still refuse to release their source
code for the ME and PSP. Therefore, everybody on this planet has to run
hardware with a lot (by all odds) of unpublished zero-day vulnerabilities.

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/](https://danluu.com/cpu-
bugs/)

This year is going to be fun...

------
Scaevolus
I think "remote" here means "host to TPM chip". Which is still bad, but not on
the level of "install a rootkit on a powered-off machine" like some of the
Intel ME exploits.

------
userbinator
AMD PSP is basically their equivalent to Intel's ME, so this is not
surprising... but then it says

 _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?

~~~
mtgx
The PSP is already quite long in the tooth. I think AMD will switch to ARM's
recently announced "SecurCore" soon, just like Qualcomm did for the Snapdragon
845:

[https://developer.arm.com/products/processors/cortex-m/sc300...](https://developer.arm.com/products/processors/cortex-m/sc300-processor)

~~~
iancarroll
That "processor" has been out for at least ten years.

------
nimbius
The Platform Security Processor (PSP) is built in on all Family 16h + systems
(basically anything post-2013), and controls the main x86 core startup. PSP
firmware is cryptographically signed with a strong key similar to the Intel
ME. If the PSP firmware is not present, or if the AMD signing key is not
present, the x86 cores will not be released from reset, rendering the system
inoperable.

The PSP is an ARM core

------
jwilk
Timeline with a sane date format:

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.

------
phyller
Looks like it's already fixed.

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

------
moby_click
For a while, I was pretty excited about secure enclaves, as a tool before
homomorphic encryption reaches practicality. If remote code execution on the
PSP means broken remote attestation, that hope goes down the drain, quickly.

Maybe, the keys in the PSP are still protected by secure computing technology,
like ARM TrustZone…

~~~
gatmne
Until a vulnerability is found in ARM TrustZone.

------
jhiska
Oh, god. At this point I no longer trust ANY computer for mission-critical
business at my company.

We're going back to pen and paper. The extra safety makes the hassle worth it.

~~~
madez
If you stay with a system that is as open as possible from the lowest levels
of the hardware to the highest level of the software, and if you airgap, and
audiogap, and RF-gap the system permanently until it ceases to exist, you are
pretty fine.

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.

~~~
conradev
> JavaScript and WebAssembly

Isn't WebAssembly a huge step forward in the ability to distribute portable,
high-performance, sandboxed code?

~~~
madez
Code, that is unreviewed, unaccounted and executed automatically. Now it shall
be high-performance, too? Does the sandbox work? Does it really work? Are
there no side channels? Are you sure? How do you make sure you don't take part
in a DDoS attack or mine cryptocurrencies for somebody else? These are just
points I can come up with spontaneously.

Besides that, the appification of the web is bad because it leads ultimately
to dependency on software that is outside of the users control.

~~~
the_duke
This is all already true for Javascript, wasm doesn't change that much here.

~~~
madez
It makes the use-case for this type of code deployment wider and it's more
effective at what it's already used for.

These are two reasons why developing and supporting WebAssembly is finally
against the interest of the users.

~~~
CyberDildonics
How does it do that exactly? Anything you can do in wasm you can do in
JavaScript, only was can do it faster. This freak out that some people have
over wasm is bizarre to me on a technical level. I think it comes down to lots
of JavaScript devs being threatened by more difficult languages being useful
for web pages.

~~~
madez
I don't program in JavaScript.

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

~~~
CyberDildonics
> It's faster and more flexible

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.

~~~
madez
It's irrelevant if it's just faster, or has other technical merits, too. What
those specifically are is irrelevant, as the political and societal
consequences of advancing that way of code deployment are bad independently of
that. My whole point is solely based on these consequences.

~~~
CyberDildonics
You keep making that assertion, but you haven't really backed it up by
anything. If you are talking about obfuscation, javascript can be obfuscated
just as much as webasm. Again, all IO must happen in javascript anyway and
anyone can look at a text representation of webasm.

------
m-p-3
And AMD were confident the same issue from Intel ME would happen to them.

Glad someone proved them wrong, and that hopefully we'll get a proper
killswitch for these backdoors.

------
xchip
>Fix is ready. Vendor works on a rollout to affected partners.

------
merb
not sure why somebody would want to use a fTPM over a dTPM. Especially since
most computers now have a dTPM. (well my cheap 80 € mainboard can switch
between fTPM and dTPM.)

------
thrillgore
2018 is going to be a great year for zero day exploits.

~~~
Tharkun
Hopefully 2018 will be the year where CPU manufacturers finally start taking
security seriously.

------
zython
damnit AMD, you're supposed to be the undedog who came out victorious after
this whole mess

