Hacker News Reader

Comment by fguerraz | Hacker News Reader

That's why things like the Pluton processor and TPMs are useful.

(A rain of downvotes falls on me)

Seriously, even good old BIOS is susceptible to rootkits, there has been tons of them. So no crying over UEFI please.

We need a fully signed and auditable chain of trust for booting OSes.

Of course all this crap needs to be open source but it needs to be locked down to prevent not trusted binaries as much as possible.

And for the 1% of people who are going to bang about their right own the hardware and run Linux and what not (I'm definitely one of those), we need to be able to do it but in an obvious way (computer should boot but display a clear message that it's been tinkerer with).

I really like software freedom, but the fact that I can disable secure boot on pretty much any computer I have physical access to and that the user will never know about it is not okay.

View on HN

I would argue that the complexity of TPMs[1] and UEFI[2] leads to a larger attack surface with more bugs present, making it easier to launch attacks such as the one described. The opaqueness of these technologies and inability for and difficulty of security researchers to investigate and debug implementations of these technologies does not help either. There is no chance of a typical system owner having the time and skill to understand TPM and UEFI technologies in enough detail to know whether their systems are vulnerable or compromised.

[1] Example: 176 pages at https://trustedcomputinggroup.org/wp-content/uploads/PC-Clie...

[2] Example: 2540 pages at https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9...

> There is no chance of a typical system owner having the time and skill...

Hence the suggestion to make it tamper obvious.

As for the attack surface, it is true, but it's a separate problem. You don't have to bloat your firmware to make it trusted.

In theory yes, more functionality means more surface, but then some aspects are fundamentally designed to be less exposed or dangerous. We will keep on finding a bunch of bugs in those implementations, but I suspect the end result is better than what we could've ever had with BIOS.

I don't think there was any chance for a typical system owner to have the time or skill or even the foundation required to understand if their machine's BIOS is vulnerable or compromised. UEFI provides some basis to actually start with that process.

I also think there is a real opportunity to write open-source versions of these components in safe/verifiable languages. That way we could have our cake and eat it too.

> I suspect the end result is better than what we could've ever had with BIOS.

I would take that bet, if there were any way to objectively assess. The surface area of BIOS is just so much smaller.

> I also think there is a real opportunity to write open-source versions of these components in safe/verifiable languages.

In theory yes. In practice they're always going to be giant blobs of C written by hardware makers, massaged just enough to get Windows to boot.

The problem with pluton is not the tech. It's that:

- it's proprietary

- it's controlled by entities that have a terrible track record

- it's going to be, as usual, forced upon everybody without consent

I have argued the same as you, it needs to be open source to fix the first two points.

For the third one, nobody is forcing you to buy a specific product, but yes, it will be hard to avoid.

But like for vaccines, individual consent is at odds with the greater good. Society needs computing that it can trust.

Maybe the solution is a healthier hobbyist market where you can buy "use at your own risk" unlocked computers? Maybe we need laws to force manufacturers to make such models? I don't know. But most people, from my mom to my CEO need a computer that will run what it is supposed to run.

It's not 1990 any more, PCs do way too important things.

This would be comparable to vaccines if Bill Gates had actually hidden tracker/kill-switch chips in each dose...

There's no reason to think a large, opaque computing base that's been forced into the market by a monopoly power is trustworthy. I'd argue that "boot sector tampering with physical access" is pretty low on the list of computer-related real-world attacks against society; it's certainly lower than zero-days caused by implementation errors in baroque computer software / hardware.

Also, suggesting you can avoid having a computer (or phone) at this point is ludicrous. It's like suggesting you can avoid using credit cards and cash. Some would argue it is actually easier to give up living under a roof than to give up owning a cell phone (and make exactly that tradeoff).

You can choose not to use them. Most of the ways people got things done in the past haven't disappeared, although some are more difficult to find now.

My mother does not have an Internet connection. Or a computer. Or a cell phone.

She definitely prefers to live under a roof. She's just not interested in any of the above.

>Society needs computing that it can trust.

The playbook that is unfolding right now with pluton is the exact opposite.

> Society needs computing that it can trust.

Then it shouldn't mess with trust. Closed source tricks is not trust. And MS lost its credibility long ago. Every closed system on a computer inspires distrust.

> For the third one, nobody is forcing you to buy a specific product, but yes, it will be hard to avoid.

Yes it is being forced. We have single digit years before participation in society becomes impossible without a device that attests that it is not under the control of the owner. First it will be banks, then government services, then access to the social graph, and so on.

> But like for vaccines, individual consent is at odds with the greater good. Society needs computing that it can trust.

So not under the control of centralised corporations that get paid when they successfully manipulate you into doing something you wouldn't otherwise, and have a proven track record of unaccountable censorship.

"I'm sorry but your computer is not running Genuine Windows 11:tm:. You may not be secure." will be the new "An application is attempting to make changes to your computer..."

Alert fatigue is real.

Alert fatigue is real but silent rootkits are way worse.

Also, it's not just about booting windows or the OS, it's about the UEFI, which even fewer people are going to want to tinker with.

Alert fatigue is much worse than silent rootkit.

I actually disagree. Silent rootkits in the bios are relatively rare, but alert fatigue is horrifically common.

It's not just the severity of harm but also it's frequency.

> Seriously, even good old BIOS is susceptible to rootkits, there has been tons of them.

Were there? I couldn't find anything, but then again Google is garbage nowadays if you want to find older stuff.

To my understanding, the limitations of the old BIOS world would've made it much harder to hack on it other than maybe enabling hidden menus.

The UEFI world is so much larger, more powerful and already offers plenty of abstractions and services. You can probably write a relatively portable rootkit that works across a plethora of different Mainboards and Chipsets. And then you come in and try to fix it with secure boot, and when secure boot isn't good enough anymore you add pluton and then what?

And what's your threat model anyways? "Professional Hackers" nowadays are in it for the money. Why would they want to custom tailor a rootkit for your BIOS? Why would they want to target you with a generic UEFI rootkit? Apparently, crypto ransomware is perfectly capable of infecting a user on windows with secure boot enabled. No need for a rootkit.

Who is going to be interested in rootkitting you besides a government backed hacking op? And in that case, I fully trust them to be able to get around any secure boot measures either with yet another exploit, or because they have access to the signing keys one way or the other.

A buddy of mine installed some crapware he downloaded off of a warez site back in the mid-2000's which reflashed his BIOS to a very hackers-esque bootsplash that prevented boot. Fortunately, he had a Gigabyte board which ran a dual-BIOS config, so he was one jumper change away from getting back to his system and cleaning stuff up. I'm not sure it was ever intended to do anything more than punish someone, but the capability of doing plenty even on that tiny ROM was there.

Compare that with having boot settings on a UEFI partition. Partition gone, boot not possible.

but the capability of doing plenty even on that tiny ROM was there.

That sounds more like he just got the BIOS erased and replaced with something else entirely, rather than something intended to parasitically coexist.

Also, for a while, they had write-protect jumpers.

I mean we already have this with AMD PSB. Basically a vendor key is physically burned into the CPU that validates the vendor firmware (BIOS/UEFI) and if the signature doesn't check out, the CPU just refuses to run.

I think physical access overriding digital security should largely be fine though, because we have a lot of tamper-evident devices for identifying physical access but you largely can't do that for digital.

Like, I can imagine a more consumer friendly PSB using a physical "key" plugged into the motherboard that's essentially a ROM board but using human visible solder pads for the bits of the key. And you could order your own key pair that comes with signing keys from the CPU vendor if you want to sign your own authenticated firmware.

I'm not certain this is where Pluton or a TPM could've helped much (individually), it's more the task of Secure Boot, Secure Launch(/DRTM) and Trusted Boot.

I'd love to see a similar effort at ensuring boot integrity for Linux, but way too many distros can't even handle Secure Boot with Nvidia/DKMS. Though even more practical features, one being (f)TPM-backed FDE, are very cumbersome and underutilised.

I was being a bit provocative with Pluton :-) I know it presses people's buttons...

Without more infos on the initial infection vector, it's difficult to assess the impact of those mitigations (Secure Boot, Secure Launch and Trusted Boot). Qutoing from the report:

"Looking at the various firmware images we were able to obtain, we assess that the modifications may have been performed with an automated patcher. If so, it would follow that the attackers had prior access to the victim’s computer in order to extract, modify and overwrite the motherboard’s firmware. This could be achieved through a precursor malware implant already deployed on the computer or physical access"

While Secure Boot + BitLocker with TPM and PIN would have prevented an Evil Maid attack (at least would have triggered a PCR change and a Windows Recovery prompt), a preliminary infection (I understand by it a supply chain attack before it reaches the user for the first time, but maybe I'm extrapolating a bit what the report is saying) would have stayed undetected in most scenarios (depending on how Intel Boot Guard is configured).

Regarding the Linux part, ANSSI did a pretty great job with their CLIP OS implementation: https://docs.clip-os.org/clipos/boot_integrity.html, but it's really "for the masses" :(

Does anyone else find it really too coincidental that the anti-Pluton article goes under, and not long after, this one appears with such comments?

All I can hypothesise is that some entity with huge vested interests is now trying to do damage control.

to prevent not trusted binaries

"trusted" by who? The faceless bureaucracy that wants to control every bloody aspect of your life?

TPMs would not have helped here. The problem is that some boot code must come first. That bit of boot code, if it can be rooted, can lie about the code it's loading, and so the TPM can't help.

The only way a TPM could help is if it was the boot loader. But that can't be, not unless the TPM were a firmware TPM running in tight cooperation with the ME.

As long it is implemented so the end user has complete control of the system in one way or another then these things are great ideas. Hard to think of how they'd do that given they seem designed more for central control than security, but if they did it'd be interesting to see what developers could do with it.

  > Of course all this crap needs to be open source

slightly pedantic maybe, but i would just add that without being able to replace said software/hardware (while maintaining a root of trust of course) just being open source (you can look but don't touch) isn't enough

>even good old BIOS is susceptible to rootkits

Those common rootkits were not in the BIOS firmware, they were just malicious code on the hard drive. But the code was written on drive space not used by the file system so it withstood malware scanning of the volume and often reformatting/restoration too.

The Master Boot Record (fist 440 bytes of sector 0) would often need to be renewed from trusted media, and the malicious code zeroed using a raw disk editor which can address sectors which are not within the file system.

Or the shotgun approach could be taken and the whole HDD zeroed.

Reply on news.ycombinator.com