Fedora considers deprecating legacy BIOS
Fedora considers deprecating legacy BIOS
Posted Apr 21, 2022 12:12 UTC (Thu) by johannbg (guest, #65743)In reply to: Fedora considers deprecating legacy BIOS by LtWorf
Parent article: Fedora considers deprecating legacy BIOS
Well funded ( law enforcement ) agencies have them in their arsenal to circumwent hard-drive encryption and in covert operation ( confuscating a computer, insert the exploit, release the subject and monitor the subject ) as well as pretending to be hardware sales company that sells drug cartels or other questionable businesses hardware ( used or new ), to infiltrate and monitor their operations while the other "darker" side is using those exploits to extort or otherwise profit from them.
These attacks are very much real and have existed in the wild for over two decades.
There is nothing hypothetical about them at all.
And I'm not sure what you mean by throwing away a perfectly good computer. What do you consider a perfectly good computer?
I'm all for recycling and reuse but the fact is computers dont last forever and computer's longevity is based on, it's usage,the environment it resides in and the quality of the component it's made out of so it can last as little as couple of days or for as long as one or two decades in otherwords people's milage might vary in that regard depending on the manufacture or even just product lines between manufactures.
The fact is distributions cannot be expect having to support old hw forever since it increases it's maintainership and will hinder the adoption of new technologies for those distribution so it's better to just use a distribution that is tailored to such usecases for that target audience.
( like LTS distribution or something like I guess slackware which presumably looks and operate just like it did when it was initally created at least it's website is most certainly from that era )
Posted Apr 21, 2022 13:39 UTC (Thu)
by wtarreau (subscriber, #51152)
[Link] (20 responses)
Yes they've existed, no they're not hypothetical, but they're totally outdated and pointless nowadays when it's both ultra-cheap and effective to develop a browser malware and that this has become by far the most effective way to steal users' information to the point that it's an industry now (look for "malware as a service").
Sorry but I do not want to mess up with that secure boot. It's only as secure as my ability to use it properly, which is basically zero.
We should not force the user to endure pain that is designed to "protect them" against their will from attacks that are not relevant to them. We should instead educate users to where risks are and how to care about what matters. We'd already make a much bigger progress if people stopped reading HTML e-mails...
While I had been seriously considering migrating from Slackware to Fedora a few months ago when slack15 was really longing to come, at least this discusssion just convinced me that it was absolutely not a good idea!
Posted Apr 21, 2022 18:01 UTC (Thu)
by johannbg (guest, #65743)
[Link] (1 responses)
If that happens to be slack good for you, if it happens to be Fedora great, if that happens to be *BSD awesome but please dont fall into this whole "I would have moved to x distro" or worse "If x feature is implemented I stop using the x distro" crowd.
Posted Apr 21, 2022 20:29 UTC (Thu)
by jwarnica (subscriber, #27492)
[Link]
But I will say that if you do have something to hide from law enforcement, then its your problem to get a sufficiently modern system to keep them out.
Posted Apr 21, 2022 22:17 UTC (Thu)
by nix (subscriber, #2304)
[Link] (17 responses)
This is exactly why I'm not using secure boot -- but I note that secure boot works for millions of people perfectly well. I suspect the reason why is simply that they are not systems hackers regularly futzing with early boot (most people aren't). Those people (like us) who *are* systems hackers regularly futzing with early boot should either learn how secure boot works or simply not use it, but that doesn't mean it's not appropriate for the vast majority who aren't routinely doing things like that.
(As for the added security: many of the attacks secure boot protects against are physical, and I'm not worried about those: anyone who can attack systems I care about that way has broken into my house and I have much bigger problems. But I'm not sure what to do about the possibility of remote attackers implanting persistent malware in my UEFI firmware or something. Secure boot would protect against that, but I still have it turned off because it would also make it more likely to turn a moderately bad boot problem into a disastrous one, and frankly the system failing to boot because of UEFI malware *is* a disaster, arguably worse for me than it booting with the malware active would be. It's a tradeoff... how common *is* UEFI malware anyway? Is it even a threat worth worrying about for someone like me who is basically a random boring person and thus unlikely to be of interest to major governments unless they are malware-implanting literally everyone in the population?)
Posted Apr 22, 2022 0:23 UTC (Fri)
by rgmoore (✭ supporter ✭, #75)
[Link]
This makes perfect sense. You have to protect against two kinds of security failures: granting access to people who shouldn't have it and denying access to people who should. Getting locked out of your own system and losing data- or losing a lot of time going through some complicated procedure to recover your data- is a security failure just as surely as letting script kiddies in is. For your personal threat model, losing access is a much bigger danger, so it makes sense to take steps to mitigate it by turning off secure boot, even if that increases your chances of getting pwned.
Posted Apr 22, 2022 0:49 UTC (Fri)
by bartoc (guest, #124262)
[Link]
Heh, come to think of it, my desktop's firmware doesn't really do anything to indicate secure-boot is off, so if someone just went and disabled it I might not know! Same with my laptop. My Surface tablet does indicate this in firmware (the boot-splash gains a huge red warning).
I think secure-boot (implemented well, like you gotta sign the initrd, come on) is probably useful against like, customs officials quickly adding a boot-kit onto your disk though, which is worth defending against for a lot of people.
Posted Apr 22, 2022 15:47 UTC (Fri)
by abatters (✭ supporter ✭, #6932)
[Link] (14 responses)
This was just in the news: Ars Technica: Hackers can infect >100 Lenovo models with unremovable malware.
Posted Apr 22, 2022 20:31 UTC (Fri)
by johannbg (guest, #65743)
[Link] (13 responses)
https://www.dell.com/support/kbdoc/en-is/000188682/dsa-20...
Many of OEM's are using insyde
https://cybersecurityworldconference.com/2022/02/02/exper...
Insyde Software Security Advisory can be found here
Report issued by U.S. Department of Homeland Security (DHS) and Department of Commerce
"Firmware presents a large and ever-expanding attack surface, as the population of electronic
https://www.dhs.gov/sites/default/files/2022-02/ICT%20Sup...
And the list goes on...
Posted Apr 25, 2022 3:17 UTC (Mon)
by wtarreau (subscriber, #51152)
[Link] (12 responses)
These examples just show that the most effective fix against all such problems is to refuse UEFI and revert back to BIOS instead.
Posted Apr 25, 2022 3:26 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Apr 25, 2022 3:40 UTC (Mon)
by mjg59 (subscriber, #23239)
[Link] (10 responses)
Posted Apr 25, 2022 14:09 UTC (Mon)
by khim (subscriber, #9252)
[Link] (6 responses)
I think you should separate the XX century from the XXI century here. I still remember MS-6309.
Year 2000 edition had a nice, simple jumper which made ROM read-only. Yes, certain change in configuration cause complaints at boot, but it was a simple matter of changing its position for one boot and return it back after that. It was as protected from malware as one can imagine. And then version 5 from 2001 (or was it 2002?) which not only lacked jumper in that place, it refused to boot if you short these two numbs which were left in it's place! So, please don't tell about the problematic situation with BIOS. It wasn't problematic when people cared. It is, of course, became problematic when people started thinking only about flexibility and forgot that it's not a good idea to have computers which are trivially bricked.
Posted Apr 25, 2022 14:26 UTC (Mon)
by pizza (subscriber, #46)
[Link] (4 responses)
Meanwhile, the other 99.999% of motherboards lacked that feature, including, as you mentioned, later versions of that same motherboard. One data point does not a generalization make.
BIOS is layered-hacks-on-top-of-layered-hacks built that goes all the way back to 1982. [1] It's long past time to shoot it in the head. And it's also why, to this day, our bleeding edge Ryzen processors still pretend to be a 44-year-old 16-bit i8086 when powering up.
[1] As in when Compaq released PC clones using a clean-room reverse-engineered BIOS.
Posted Apr 25, 2022 15:14 UTC (Mon)
by khim (subscriber, #9252)
[Link] (3 responses)
Sorry, but no. It's most definitely not 99.999%. I know for the fact that you had to replace ROM chips on Risc PC, Amiga (in fact you can still buy a replacement chips) and I have seen "Flash Protect" switch on lots and lots of motherboards made in XX centory. I remember that one specifically because it was a surprise to me that they would remove it. Yes, so what? It works. It's secure (more secure than the XXI century abomination). And easy to provide in virtual environment. EFI is huge mess with the only redeeming quality: it can support >4TB SSDs. That's great, but I'm not sure all that pointless complexity is worth it. Insecure-by-design POS which can not be protected by design — and I'm supposed to use for sake of “security”? Puhlease. Sure, I use EFI when I have no choice, but that doesn't mean it's not POS. So what? One doesn't need that many transistors to implement that more and today there are billions of them on any x86 CPU.
Posted Apr 25, 2022 15:41 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (1 responses)
Note, though, that on all modern x86 hardware platforms, "traditional" BIOS is implemented as a module running atop UEFI; so you get all the vulnerabilities of UEFI, plus extra holes due to the CSM that implements the BIOS interface.
Which, in turn, makes the claims about BIOS being more secure questionable - you're talking about an additional layer atop UEFI, which can have its own vulnerabilities, plus you have the full stack of UEFI beneath it to compromise.
Posted Apr 25, 2022 15:46 UTC (Mon)
by khim (subscriber, #9252)
[Link]
That's very true, sure. I see no reason to use the BIOS interface on the system where it's emulated via CSM. But I don't think it's imlemented that way in virtual systems and other small systems where Linux can still run. Although I wonder how many of these are out there which may not just run Linux, but specifically Fedora. It's pretty heavy novadays.
Posted Apr 29, 2022 15:48 UTC (Fri)
by ms-tg (subscriber, #89231)
[Link]
Posted Apr 25, 2022 18:24 UTC (Mon)
by wtarreau (subscriber, #51152)
[Link]
Many of us have had much more robust than a jumper, an EPROM that required UV light to erase them, and a special programmer delivering 21V to the VPP pin to program them :-) There was no need for a jumper, and as an added bonus, not being upgradable in field tended to make them less bogus (at least they were more tested than my core i7's AMI BIOS).
Posted Apr 28, 2022 12:55 UTC (Thu)
by stock (guest, #5849)
[Link] (2 responses)
Posted Apr 28, 2022 13:47 UTC (Thu)
by pizza (subscriber, #46)
[Link]
The vulnerability is actually with networkd-dispatcher, which is developed (and distributed!) independently from systemd. It's not even widely packaged in distributions! It's not a "systemd vulnerability" any more than a vulnerability in NetworkManager or Apache (or any other random daemon) can be called a "systemd vulnerability."
Meanwhile I see nothing in the article about how this vulnerability can only affect UEFI systems -- it seems to involve relatively run-of-the-mill symlink traversal, and the CVE descriptions are still redacted. Can you point us towards some sort of supporting evidence for your assertion?
Posted Apr 28, 2022 21:09 UTC (Thu)
by johannbg (guest, #65743)
[Link]
Interesting even Keith Richards drugs aren't strong enough to reach that conclusion in otherwords please explain to the audience here on LWN how a security flaw in networkd-dispatcher has anything to do with systemd and it only be happening on uefi hardware.
I eagerly await your response on the matter backing that up...
Posted Apr 22, 2022 0:42 UTC (Fri)
by bartoc (guest, #124262)
[Link] (1 responses)
If you are buying hardware from the FBI (or generally if the actual, no shit, manufacturer of the hw is attacking you) you are completely screwed, even remote attestation won't save you (because it'll attest it is unmodified from what you bought!).
I don't really see what this has to do with removing BIOS, sure, you can do hardware attacks. Even secure boot can't prevent these attacks without robust attestation support, or extreme levels of tivoization. You _definately_ can't if you don't even bother to sign the initrd.
I think many modern systems will verify firmware code before allowing it to be flashed, even code that implements the legacy BIOS interfaces (ofc with physical access and enough sophistication you can just replace whatever is doing that verification or storing those keys, though sometimes this ends up being the entire processor).
In any event without an acute awareness of these kinds of attacks and a whole bunch of supporting infrastructure I don't think most systems will be able to prevent this, as it involves some significant useability (and freedom) tradeoffs to protect against an attack model that is uncommon (and if that model applies to you then you had better be well aware of that fact, otherwise you've already lost).
Posted Apr 22, 2022 1:22 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link]
Not entirely. If you're on Intel and Boot Guard is enabled, the firmware will be measured before it's executed. If you're specifically targeted with modified firmware (even if it's signed appropriately), then those measurements will be different and there'll be reasons to ask questions. Of course, if the vendor just ships backdoored firmware to everyone, that doesn't help (but it does increase the probability that someone will notice the backdoor) - and if Intel is in on it, then obviously all bets are off.
Fedora considers deprecating legacy BIOS
> There is nothing hypothetical about them at all.
However it surely guarantees that I will eventually lose my data when not being able to recover my system after some bugs, crashes or other issues with my machine.
Fedora considers deprecating legacy BIOS
Fedora considers deprecating legacy BIOS
I won't be that guy to say that if you don't have anything to hide then law enforcement will leave you alone.
Fedora considers deprecating legacy BIOS
Fedora considers deprecating legacy BIOS
Secure boot would protect against that, but I still have it turned off because it would also make it more likely to turn a moderately bad boot problem into a disastrous one, and frankly the system failing to boot because of UEFI malware *is* a disaster, arguably worse for me than it booting with the malware active would be.
Fedora considers deprecating legacy BIOS
> how common *is* UEFI malware anyway?
Fedora considers deprecating legacy BIOS
Fedora considers deprecating legacy BIOS
https://www.insyde.com/security-pledge
devices grows. Securing the firmware layer is often overlooked, but it is a single point of failure
in devices and is one of the stealthiest methods in which an attacker can compromise devices at
scale. Over the past few years, hackers have increasingly targeted firmware to launch
devastating attacks."
Fedora considers deprecating legacy BIOS
Fedora considers deprecating legacy BIOS
Fedora considers deprecating legacy BIOS
Fedora considers deprecating legacy BIOS
Fedora considers deprecating legacy BIOS
>Year 2000 edition had a nice, simple jumper which made ROM read-only. Yes, certain change in configuration cause complaints at boot, but it was a simple matter of changing its position for one boot and return it back after that.
> Meanwhile, the other 99.999% of motherboards lacked that feature, including, as you mentioned, later versions of that same motherboard. One data point does not a generalization make.
Fedora considers deprecating legacy BIOS
Fedora considers deprecating legacy BIOS
Fedora considers deprecating legacy BIOS
Fedora considers deprecating legacy BIOS
Fedora considers deprecating legacy BIOS
Fedora considers deprecating legacy BIOS
contrary :
https://www.theregister.com/2022/04/27/microsoft-linux-vu...
which is vulnerability within systemd and only happens on UEFI hardware.
Fedora considers deprecating legacy BIOS
Fedora considers deprecating legacy BIOS
which is vulnerability within systemd and only happens on UEFI hardware.
Fedora considers deprecating legacy BIOS
Fedora considers deprecating legacy BIOS