Live data from Hacker News

AMD PSP: Firmware TPM Remote Code Execution via Crafted EK Certificate

seclists.org

91–99 of 99 posts

Re: AMD PSP: Firmware TPM Remote Code Execution via Crafted EK Certificate

#91
post #83

Earlier quoted context omitted.

What prevents attackers from collecting photos of the papers with nearby phones, security cameras, or even a fleet of tiny drones?

Cost

So it's possible and it's just a matter of optimization. Pens and typewriters leak data acoustically, so let's replace cameras with microphones to reduce costs. Tiny microphones with antennae can be mass produced cheaply and they are easily hidden. Delivery can be automated too, but it's much easier to embed the spy devices in common products people frequently buy.

Re: AMD PSP: Firmware TPM Remote Code Execution via Crafted EK Certificate

#92
post #82

Earlier quoted context omitted.

It looks like they built their own chips for their servers: 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…

Google's code/hardware logic is an opaque binary blob to you. What difference does it make whether the binary blob is a Google chip or a TPM?

Sorry, what I meant to say was that we need those types of verifiable and transparent chips in our own computers rather than ME and PSP

Re: AMD PSP: Firmware TPM Remote Code Execution via Crafted EK Certificate

#94
post #9

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…

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

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

Re: AMD PSP: Firmware TPM Remote Code Execution via Crafted EK Certificate

#95
post #67

Earlier quoted context omitted.

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

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.

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.

Re: AMD PSP: Firmware TPM Remote Code Execution via Crafted EK Certificate

#96
post #67

Earlier quoted context omitted.

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.

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.

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.

Re: AMD PSP: Firmware TPM Remote Code Execution via Crafted EK Certificate

#97
post #96

Earlier quoted context omitted.

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.

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

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

Re: AMD PSP: Firmware TPM Remote Code Execution via Crafted EK Certificate

#98
post #96

Earlier quoted context omitted.

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

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

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.

Re: AMD PSP: Firmware TPM Remote Code Execution via Crafted EK Certificate

#99
post #98

Earlier quoted context omitted.

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

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.

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.
Post reply on HN