9 ms·

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, t

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.

vorpalhex 4y ago
"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.
- fguerraz 4y ago
  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.
  - hulitu 4y ago
    Alert fatigue is much worse than silent rootkit.
  - vorpalhex 4y ago
    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.
BiteCode_dev 4y ago
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
- fguerraz 4y ago
  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.
  - hedora 4y ago
    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).
    - doubled112 4y ago
      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.
dhx 4y ago
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-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-v1p05p_r14_pub.pdf https://trustedcomputinggroup.org/wp-content/uploads/PC-Clie... [2] Example: 2540 pages at https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9...
- fguerraz 4y ago
  > 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.
- Avamander 4y ago
  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.
  - lmm 4y ago
    > 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.
Avamander 4y ago
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.
- fguerraz 4y ago
  I was being a bit provocative with Pluton :-) I know it presses people's buttons...
- Harvesterify 4y ago
  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 https://docs.clip-os.org/clipos/boot_integrity.html, but it's really "for the masses" :(
iforgotpassword 4y ago
> 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.
- belthesar 4y ago
  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.
  - hulitu 4y ago
    Compare that with having boot settings on a UEFI partition. Partition gone, boot not possible.
  - userbinator 4y ago
    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.
deleted 4y ago
[deleted]
cryptonector 4y ago
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.
jabbany 4y ago
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.
eikenberry 4y ago
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.
deleted 4y ago
[deleted]
andrekandre 4y ago
> 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
userbinator 4y ago
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?
fuzzfactor 4y ago
>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.

vorpalhex 4y ago

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

fguerraz 4y ago
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.
- hulitu 4y ago
  Alert fatigue is much worse than silent rootkit.
- vorpalhex 4y ago
  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.

BiteCode_dev 4y ago

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

fguerraz 4y ago
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.
- hedora 4y ago
  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).
  - doubled112 4y ago
    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.

dhx 4y ago

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-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-v1p05p_r14_pub.pdf https://trustedcomputinggroup.org/wp-content/uploads/PC-Clie... [2] Example: 2540 pages at https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9...

fguerraz 4y ago
> 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.
Avamander 4y ago
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.
- lmm 4y ago
  > 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.

Avamander 4y ago

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.

fguerraz 4y ago
I was being a bit provocative with Pluton :-) I know it presses people's buttons...
Harvesterify 4y ago
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 https://docs.clip-os.org/clipos/boot_integrity.html, but it's really "for the masses" :(

iforgotpassword 4y ago

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

belthesar 4y ago
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.
- hulitu 4y ago
  Compare that with having boot settings on a UEFI partition. Partition gone, boot not possible.
- userbinator 4y ago
  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.

deleted 4y ago

[deleted]

cryptonector 4y ago

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.

jabbany 4y ago

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.

eikenberry 4y ago

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.

deleted 4y ago

[deleted]

andrekandre 4y ago

> 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

userbinator 4y ago

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?

fuzzfactor 4y ago

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