Live data from Hacker News

CosmicStrand: The discovery of a sophisticated UEFI firmware rootkit

securelist.com

41–50 of 125 posts

Re: CosmicStrand: The discovery of a sophisticated UEFI firmware rootkit

#41

Furious searches for BIOS only era hardware are taking place on ebay as we speak. To use with a modified Linux kernel that emulates a bog standard Thinkpad uefi environment of course. EDIT: I forgot to phrase this as a question - besides missing a QubesOS or KickSecure on top, is this a decent plan for airgapped stuff?

Just run your OS in a VM.

Re: CosmicStrand: The discovery of a sophisticated UEFI firmware rootkit

#42
post #2

> The most striking aspect of this report is that this UEFI implant seems to have been used in the wild since the end of 2016 – long before UEFI attacks started being publicly described. This discovery begs a final question: if this is what the attackers were using back then, what are they using today? I always marvel at the ingenuity and technical complexity of these kinds of attacks, but this is also something that…

You know what'll help? Pluton. The future of computing is a signed code path from power on to end-user application code with multiple layers of sandboxing in between. With so many hostile actors, from script kiddies to government agencies out there, "general purpose computing" (which, from a security standpoint, is just arbitrary code execution) just isn't viable anymore. We need provable attestation that no layer of the software stack has been tampered with.

Re: CosmicStrand: The discovery of a sophisticated UEFI firmware rootkit

#43

My hopes of large volume fully open source systems died when I learned that beefy RISC V boards will ship with UEFI.

You can implement something else, riscv is a young isa

yup, RISC-V happily boots with just uboot

Re: CosmicStrand: The discovery of a sophisticated UEFI firmware rootkit

#44
post #7

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

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.

Re: CosmicStrand: The discovery of a sophisticated UEFI firmware rootkit

#45
post #26

Earlier quoted context omitted.

Yeah, I assume that either everything is infected and backdoored and there's no way to detect it until it's too late, or almost nothing is infected because doing so would be the cross platform compatibility nightmare of all nightmares. I don't know which one it is.

Definitely the first. Beacons have better cross-platform support than most Microsoft products.

Microsoft sets an extrememly low bar as they only want one platform, theirs.

Re: CosmicStrand: The discovery of a sophisticated UEFI firmware rootkit

#46

My hopes of large volume fully open source systems died when I learned that beefy RISC V boards will ship with UEFI.

UEFI can work open source no problem. You'll still need binary blobs for memory initialisation and such, because no open systems exist for that, but the boot process isn't really closed.

Aside from open source UEFI setups like Tiano, you can also use CoreBoot or LinuxBoot where UEFI doesn't work for you.

Re: CosmicStrand: The discovery of a sophisticated UEFI firmware rootkit

#47
post #42
post #2

> The most striking aspect of this report is that this UEFI implant seems to have been used in the wild since the end of 2016 – long before UEFI attacks started being publicly described. This discovery begs a final question: if this is what the attackers were using back then, what are they using today? I always marvel at the ingenuity and technical complexity of these kinds of attacks, but this is also something that…

You know what'll help? Pluton. The future of computing is a signed code path from power on to end-user application code with multiple layers of sandboxing in between. With so many hostile actors, from script kiddies to government agencies out there, "general purpose computing" (which, from a security standpoint, is just arbitrary code execution) just isn't viable anymore. We need provable attestation that no layer of…

As long as we control each layer this sounds great. What are you thinking, some sort of physical switches on the computer that turns on and off access to the layers from software so you can control them individually? That's the tricky part, how to switch those layers on and off so you can work with them in a non-software controlled way.

Re: CosmicStrand: The discovery of a sophisticated UEFI firmware rootkit

#48
post #2

> The most striking aspect of this report is that this UEFI implant seems to have been used in the wild since the end of 2016 – long before UEFI attacks started being publicly described. This discovery begs a final question: if this is what the attackers were using back then, what are they using today? I always marvel at the ingenuity and technical complexity of these kinds of attacks, but this is also something that…

Most modern exploits on this level are extremely difficult to get onto users machines - without any conspiracy at play, you would have to essentially get users to run untrusted code, and for general use case there are a whole bunch of blockades against this. For private entities seeking financial gain, its completely pointless to burn a zero day like this for the return that you would get.

Really ? On some of my computers the UEFI partition is a FAT32 partition writable by anyone by default.

Re: CosmicStrand: The discovery of a sophisticated UEFI firmware rootkit

#49
post #42
post #2

> The most striking aspect of this report is that this UEFI implant seems to have been used in the wild since the end of 2016 – long before UEFI attacks started being publicly described. This discovery begs a final question: if this is what the attackers were using back then, what are they using today? I always marvel at the ingenuity and technical complexity of these kinds of attacks, but this is also something that…

You know what'll help? Pluton. The future of computing is a signed code path from power on to end-user application code with multiple layers of sandboxing in between. With so many hostile actors, from script kiddies to government agencies out there, "general purpose computing" (which, from a security standpoint, is just arbitrary code execution) just isn't viable anymore. We need provable attestation that no layer of…

So you will have backdoored SW but you will not be able to replace it because it is "secure".

Re: CosmicStrand: The discovery of a sophisticated UEFI firmware rootkit

#50
post #7

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

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.

Post reply on HN