Hacker News Reader

Comment by keyme | Hacker News Reader

As stated in the article, some researchers have managed to unpack it, and it can now be dissembled.

You can't (and hpefully won't) be able to execute your own code there.

There are 2 good reasons for this:

1) As per the article, to actually prevent ring -3 malware. The implemented signature is the best way to do this. If we could run our own "libre" code there, so could the attacker.

2) I bet this firmware controlls stuff like wether your CPU is "really" a Core i3 or Core i7, how many cores are activated, etc. Basically, its reasonable to assume that the silicon is the same, but what you pay determines the actual "unlocked" performance.

View on HN

> 1) As per the article, to actually prevent ring -3 malware. The implemented signature is the best way to do this. If we could run our own "libre" code there, so could the attacker.

Why can't computers have physical switches that enable/disable writing the memory that this piece of software is located in?

Good question. Why don't phones have physical switches on GPS and microphones?

In this case, the RSA sig is still better, though. Imagine that anyone sitting between the Intel plant and your local computer parts supplier could flip the switch.

It's a weak argument, I admit. There should be both protections at the same time.

There are phones that do have these switches.

Care to elaborate?

Asked from my N900, the only one I am aware of.

That is actually slightly less secure - sometimes people do have physical access to your machines.

For example, the NSA intercepted deliveries of switches and installed their malware on them. Would be easy if there is a physical switch. Not so easy if you need signed firmware (I'm sure the NSA could still do it, but it would definitely be harder).

If they have physical access, it's over regardless of what authentication mechanisms are employed.

I'd argue that not being able to modify software subjects you to a higher risk because you wont be able to fix security vulnerabilities yourself.

Software and hardware outlive the companies that produce them.

The NSA could just produce their own chips, and put them onto your system.

> As per the article, to actually prevent ring -3 malware. The implemented signature is the best way to do this.

No. If the thing has no persistent storage in it then just removing power from the machine would remove any such malware, and if it does have storage then it should have a "reset to factory" jumper somewhere that has the same effect.

There is no excuse for not letting the machine's owner replace any code on the machine.

"You can't (and hpefully won't) be able to execute your own code there."

You don't have to beat the encryption scheme to executed code. You just need to jail break the signed code. If the code is complex there will be bugs and likely security holes. One sufficiently wide hole is all it takes to jail break a system.

edit: This is an example of breaking in to a jail rather than out of one.

> As per the article, to actually prevent ring -3 malware. The implemented signature is the best way to do this. If we could run our own "libre" code there, so could the attacker.

That's completely false; allowing the execution of libre software doesn't worsen security, and the security-by-obscurity model doesn't improve it.

Codesigning is "security-by-obscurity" now?

No, not that, the rest of it. I meant the fact that it's a binary blob which hasn't (recently) been subject to review by users.

The rest of it is covered by my second argument. They don't want you to see it due to highly proprietary stuff running there.

And if you agree about code signing, do you really believe that letting everyone see it, but then not allow anyone else to change it, is a good idea?

It's better than not letting anyone see it, and also not allowing it to be changed.

At least in the case where the code can be inspected, it can be checked for vulnerabilities, backdoors, etc.

That is better than nothing, especially if the vendor can be asked for a fix.

> allowing the execution of libre software doesn't worsen security

It does if I get temporary physical access to your machine and flash something that can spy on you, or if the method of flashing it can be done via your OS and I hack that. Those are two HUGE flaws.

If I have physical access, I can install malware in the firmware of your WiFi card, or I can replace the whole CPU with a malicious one.

Once physical access is gained, everything is over.

Of course you can execute your own code, you just send a National Security Letter to Intel; or did you mean "you can't execute your own code unless you're the NSA"?

IME is on the motherboard chipset, not the CPU. The i3 vs i5 is controlled by fuses set at manufacturing time on the CPU itself.

That's interesting, since the trend seems to be many of the functions motherboard did in the past (memory controller) are being moved into the cpu. Is there some reason why ME is outside the cpu? Is it really so for the newest processors?

> 1) As per the article, to actually prevent ring -3 malware. The implemented signature is the best way to do this. If we could run our own "libre" code there, so could the attacker.

If the code can be updated by $company, then it should also be allowed for users to update it. It's the same as the UEFI argument (though you should use CoreBoot). If it was impossible to update, then it wouldn't be a problem from a free software perspective. From a security perspective it should still be free software.

In many cases there will be manufacturing defects resulting in errors if you try to upgrade via firmware, especially early in a products lifetime when the defect rate is high. But of course there will still be many cases where you're able to upgrade without problems.

Reply on news.ycombinator.com