8 ms·

Hacking BIOS chips isn't just the NSA's domain anymore

84 points by mseri 12y ago

paralelogram 12y ago
In my opinion it isn't a bad thing because in the future, when Microsoft disallows disabling secure boot, using BIOS vulnerabilities will be the only way to install an unsigned operating system.
- XorNot 12y ago
  Bingo: I'm far more afraid of hardware that's actually unhackable. Down that road lies the slow death of start ups, activism, DIY programming etc. I'm actually really happy the tablet revolution didn't pan out as predicted since it leads to the same conclusion: computers where you can't just start coding on them, without which I would never have gotten started.
  - pdkl95 12y ago
    The War On General Purpose Computing continues. Far too many people are content to sacrifice their future in exchange for a few shiny beads^H^H^H^H^H"smart" devices. As for tablets: they may not have been the revolution that some people hoped for, but the lock-in to a walled garden happened anyway with the iphone. Apple has done more long-term damage to the computer industry than anybody else by convincing way to many software authors - who should really know better - that paying to write and publish software is sane. Instead of fighting this when it was small, we are now faced with a future where even the hardware can work against the user who wants a true General Purpose Computer. We've already seen BIOS lockouts such as the recent thinkpad "boot guard" idiocy. It will get really bad once we start to see Intel "SGX" and the "trusted execution environment" it is intended to enable[1]. So now we get to fight at the hardware level, too. As for using vulnerabilities to root the device - that is not a strategy to fight this, and merely cedes the fight to the people that are afraid of what it means to be "turing complete". Unfortunately, I suspect that we are too late. Fighting this trend now requires sacrifice. Stop giving any money to any business that uses these anti-user technologies. Yes, that includes Intel and many others. Stop writing software or making embedded products that rely on these kinds of features. Yes, this might mean quitting a nice job. No, I expect instead that the people that should know better will continue supporting the enemy by buying their products. I expect they will stay on as collaborators. [1] this should scare anybody that wants a future where that still has general purpose computers: http://www.arm.com/images/GP_Standardization_500.png http://www.arm.com/images/GP_Standardization_500.png
    - kuschku 12y ago
      TPM /could/ be nice, if you personally would control it, instead of some company burning the signing keys into the processor – because then you would be able to make a safe system.
      - pgeorgi 12y ago
        Except for the Enrollment Key, that's how TPMs work. And the EK is not so much an issue of "control", but of "privacy" - and as long as you control the OS, access to that key (or any other) can be mediated properly.
    - indians_pro 12y ago
      As someone who is a novice to computer architectures, is there some consensus in the research community about what will be a good replacement for the von neumann machines we are currently running? I mean, if you think about it, if we truly want to take control, shouldn't we attempt to break free, at a ground level, from all the technologies coming from (or dominated by) corporate structures (and government agencies)? x86 (and _64) and even ARM are all primarily developed by govt-influenced companies like Intel, yes? So what are the possibilities of us, all programmers and electronic engineers who want to support personal computing, to get together and develop a crowd-researched, crowd-designed, and (maybe) crowd-funded architecture to last the future. Of course, writing software for that architecture could take decades-centures (unless someone writes a perfect x86 emulation layer on that architecture), but at least that gives us a hope for the future, a backup to fall to if Intel pulls a full on 'google' on us. So are these just big dreams or is there an actual possibility of something like this happening? Especially if the community secures the funding of some visionary who's rich as Bill Gates (maybe the man himself) and on the side of the public? That way we'll be able to actually build a system from the ground up that is libre and transparent, without having to muck about with reverse engineering on the 'enemy's ground', so to speak, like corebook does.
      - pgeorgi 12y ago
        The problem isn't so much in architectures, but in silicon processes. HomeCMOS (http://homecmos.drawersteak.com/wiki/Main_Page http://homecmos.drawersteak.com/wiki/Main_Page) is notable in being the relatively rare project to look at this layer in the computing stack at all. Once you can do your own processors, the architecture is alright. To avoid running into licensing issues all the time, projects like RISC-V (http://riscv.org/ http://riscv.org/) can help - or open cores like Leon (SPARCv8), OpenSPARC-T1/2 (SPARCv9), openRISC and several more. The problem is, the silicon processes were optimized for investment heavy, large scale operations. To ensure the livelihood of general purpose computing we need a "3D printer for logic gates" (for lack of better term), even if it's economically and technologically less efficient (but not too much, obviously).
- joosters 12y ago
  That's a terrible position to take. We don't have to choose between security and freedom (to pick an OS). We can have both. Don't settle for lese!
- RaleyField 12y ago
  > it isn't a bad thing What isn't a bad thing? Shitty security in BIOS chips? Instead of reformatting your disk you have to detach eeprom chip that holds bios from mobo and connect it to another system to inspect it for infections / changes. I'm not sure this is even possible for most mobos and it doesn't cost nothing like reformatting disk costs nothing. EDIT: > using BIOS vulnerabilities will be the only way to install an unsigned operating system. Then I would rather not use those systems. Android phones are already at this level - I could run CyanogenMod but I'd have to first run a random blob I refuse run because there is no way to verify what that blob does. I'm screwed both ways. At these moments I remember Stallman wasn't completely crazy and wish Linux was licensed under GPLv3 so that the phone I bought wasn't tivoized.
  - ghaff 12y ago
    >At these moments I remember Stallman wasn't completely crazy and wish Linux was licensed under GPLv3 so that the phone I bought wasn't tivoized. In which case Google would most likely simply have used a BSD variant as Apple did.
    - indians_pro 12y ago
      Ha. The strange thing about stallman is that his words of 'craziness' magically convert to words of wisdom, but there is always a delay in that process, which can go up to decades. This happens _always_. Joke's on us, despite knowing about this phenomenon, we never adjust for it.
  - userbinator 12y ago
    but I'd have to first run a random blob I refuse run because there is no way to verify what that blob does There's always reverse-engineering... an option which I believe could be far more powerful, and Stallman should've argued for; the ability (and right) to figure out what some software does and modify it is the fundamental key to the freedom he argues for, and while having the source code can certainly help, it's not the only possibility. The power of RE comes from the fact that, while it's very easy to not release source code, it's nearly impossible to prevent someone from reading the binary on a general-purpose computer regardless of what the legal situation is.
- xvilka 12y ago
  It sounds very wise, after this: http://arstechnica.com/information-technology/2015/03/windows-10-to-make-the-secure-boot-alt-os-lock-out-a-reality/ http://arstechnica.com/information-technology/2015/03/window...
TerryADavis 12y ago
These are really stupid people who want to fight God, LOL. Guess who wins when you fight God?
- deleted 12y ago
  [deleted]
- smorrow 12y ago
  Upvoted because Terry Davis.
  - jacquesm 12y ago
    Don't upvote it because it's Terry, upvote it when he contributes in a positive way to the conversation (which he has done on occassion).
- deleted 12y ago
  [deleted]
- kuschku 12y ago
  The House. The House always wins.
- sobkas 12y ago
  No one, because God doesn't exist.
  - btzll 12y ago
    tips fedora
    - sobkas 12y ago
      your preference for linux distributions is unrelated to my comment
caligastia 12y ago
Automated discovery and exploitation of architectural flaws is merely the next step in the evolution of software. For the past few years we have been witness to a 'whack-a-mole' type of dynamic in the field of computational security. Exploits are published, a day later they become a Metasploit module, and a day after that anybody in the world can use it on everyone else in the world at the click of a mouse. If you are a full time sys-admin plugged into all the advisory mechanisms you may, for a time, be able to keep your systems patched, but the machines never sleep, they never blink, they never forget, and apparently, they never die. In the race against time, it is fair to say at this point that the machines have won. It may not be completely obvious yet, in the way that a tidal wave out at sea is only a small hump under your individual ship, but when it comes ashore, when the confluence of terrain and massive liquid power becomes manifest, then, of course, it is obvious. What appears to be happening is a kind of terra-forming activity, a new software layer is spreading, one that has the keys to everything - our social lives, our morning cup of coffee, our cars.. our nukes. This has an end condition, of course - and that is the total loss of control over our technological infrastructure.
- dguido 12y ago
  > Automated discovery and exploitation of architectural flaws is merely the next step in the evolution of software. > This has an end condition, of course - and that is the total loss of control over our technological infrastructure. Why can't you use the same technology to defend your software?
  - EthanHeilman 12y ago
    Agreed. If you had a tool which could detect all of a particular class of exploits in your software one could just add it to your compiler so it would throw an error. Of course this assumes that automated discovery is not very computationally intensive, which in some cases it appears to be. The search space of a program is enormous. Instead one possible world is one in which exploits can be found automatically, but discovery requires massive computational effort. This seems extremely likely to me because exploits that don't require massive computational effort will be found and limited quickly eliminating the low hanging fruit.o Thus governments with the best algorithms and the most money/powerplants/datacenters/fabs have an advantage because they can patch their own software while developing exploits for other peoples software. The strategy comes in at: 1. how many exploits do you keep in reserve given a particular rate of discovery, and how and when do you use exploits? 2. How do you handle the case when you and the target are using the same software? If you start to patch it, the exploit might leak to the target. If you use the exploit before patching, the target might use it against you. Operationally protecting exploits from spies seems hard. A government with a technical advantage might well be a disadvantage to a less technically savvy government with a human intelligence advantage. To quote the Honey Badger video: >"You do all the work for us, honey badger, and we'll just eat whatever you find, how's that? What'daya say, stupid?" To avoid this a government might use the exploit development capability only defensively in peace time, keeping no reserve of exploits, until they have an immediate need. Of course this might weaken deterrence. tl;dr cyber
DennisP 12y ago
I'm reasonably technical but had no idea I was supposed to be security-patching my BIOS. I googled and found that (1) most of the articles about updating BIOS don't mention security, (2) finding BIOS updates for your hardware isn't necessarily trivial, and (3) applying the update is a fairly involved process with some risk of bricking your computer. Is there any way hardware manufacturers could make it as easy as OS updates?
- pgeorgi 12y ago
  The mainboard I use has an autoupdater in the setup screen. Connects to LAN (DHCP), requests updates, installs them. UEFI also allows updating from within the OS, and it looks like they formalized things a bit more, so that can be streamlined. (see https://blogs.gnome.org/hughsie/2015/03/03/updating-firmware-on-linux/ https://blogs.gnome.org/hughsie/2015/03/03/updating-firmware...) Then again, this is only necessary because UEFI is more complex than some operating systems, and thus provides the attack surface that they then have to defend like that.
1xtjjlunab 12y ago
In my view this is a result of hardware not actually being "hard". It would be far better to have a bug that comes back after a cold boot, as part of a known starting state, than to have a mechanism for "updates" (running software) that is inaccessible to the user/programmer. A static bug can be worked around, but a moving target is harder to compensate for, particularly if it is not viewed as user-programmable (for lack of documentation, or license, etc). To me, this demonstrates that the proper place for security is in software, at as high a level as possible for the purpose. Even secure boot is too low. Boots should be insecure, but repeatable. Turning a computer on should give full control - only then can you lock it down (whatever that means to the user...). Secure boot, if you want it, should just be a bootloader that verifies a payload, thereby protecting itself - not a BIOS-integrated feature, where the BIOS is opaque. A feature-full BIOS would only makes sense if it were immutable (and even then, there would be disadvantages), or (at the other end of the spectrum) if it were as programmable as the rest of the system - but until then, any unnecessary complexity or "features" are downright harmful.
- morcheeba 12y ago
  To do that, you'd also have to harden everything - including the hard drive's firmware - so you get the proper boot sector. Not all bios bugs can be worked around in firmware -- if the memory controller isn't initialized correctly, all processing is suspect. And if the manufacturer can't fix a bios, then it falls on the shoulders of the OS writers -- who do not have neither the motivation to fix 100's of board-specific problems. Worse yet, if I wanted to inject malware, I would pretend to be a motherboard manufacturer and submit bad kernel code to beleaguered OS people.
peatmoss 12y ago
Naive question: Is Core Boot in any way a potential remedy for the sad, sorry situation we're in here? I wonder when there will become a market for manufacturers to start releasing devices with hardware DIP switches or jumpers that need to be bridged for flashing purposes.
- pgeorgi 12y ago
  coreboot has a very different architecture, and we try to avoid having it parse external data (except for hardware registers). It also has next to no presence during the runtime of the OS (no API for the OS to call into, and to exploit) - which is part of the "no external data" approach. It's also much smaller: A minimum UEFI for QEmu that can barely boot into Linux loaded from SATA is 120kloc, coreboot (plus payload) for the same purpose are about 20kloc. These differences should stop some of the exploit approaches right from the start. Regarding the switches/jumpers, hardware is now complex enough to set up that a wakeup after suspend requires more data than what CPUs can store by themselves to revive memory without data loss. That data ends up in flash, so something needs to change in that area before a flash chip could be write protected with a jumper. (Disclosure: I'm a coreboot developer and no fan of UEFI)
  - userbinator 12y ago
    Motherboards were produced with flash write-enable jumpers around the end of the last century, but my guess is that the cost savings of omitting the part and not requiring users to physically move the switch whenever reflashing BIOS, combined with what seems to be now perpetually buggy BIOSes needing constant updates, made them disappear. I think it's still a good idea, however. Regarding the switches/jumpers, hardware is now complex enough to set up that a wakeup after suspend requires more data than what CPUs can store by themselves to revive memory without data loss. That data ends up in flash, so something needs to change in that area before a flash chip could be write protected with a jumper. How much data is this? I thought it'd be stored in the CMOS NVRAM, which could be a better design.
    - pgeorgi 12y ago
AC__ 12y ago
Are these vulnerabilities exclusive to UEFI BIOS? The more I learn about UEFI, I am left with the feeling it is nothing but a wide open back-door and a method to "brick" pc's.
- pgeorgi 12y ago
  UEFI is designed to scale up - servers that can boot from network, which brings a certain baseline complexity. It doesn't help that the designers didn't want to set any rules and run everything through a central, extensible function call dispatch. The effect is that UEFI can load and run executables (from flash, disk, network), has a network stack and things like openssl (when did you last update your firmware's SSL implementation? :-) ), all of which process lots of ingress data - while maintaining a larger degree of control over the system than the OS that comes after it. So, it's not UEFI-specific per-se, but UEFI's design was optimized for the large scale (it pretty much started on Itanium, so there) and at a time when security wasn't much of a priority. Now they sit in that corner and look for ways out. Such as signature checks on executables (Secure Boot).
WalterBright 12y ago
A lot of these reflashable ROM exploits can be prevented with the simple addition of a physical switch or jumper that controls the write signal. With the writes physically disabled, no exploit would survive rebooting the system. Device makers can add such switches as a simple way to advertise being secure. I'd pay a few dollars extra for such, for example, hard disk drives that cannot have their firmware altered, and car computers that cannot be altered, etc.
mehycombo 12y ago
so...I see a nice thread here without a link to the researcher's actual work... speculate and bloviate much? http://legbacore.com/Research.html http://legbacore.com/Research.html

84 points by mseri 12y ago

In my opinion it isn't a bad thing because in the future, when Microsoft disallows disabling secure boot, using BIOS vulnerabilities will be the only way to install an unsigned operating system.

XorNot 12y ago
Bingo: I'm far more afraid of hardware that's actually unhackable. Down that road lies the slow death of start ups, activism, DIY programming etc. I'm actually really happy the tablet revolution didn't pan out as predicted since it leads to the same conclusion: computers where you can't just start coding on them, without which I would never have gotten started.
- pdkl95 12y ago
  The War On General Purpose Computing continues. Far too many people are content to sacrifice their future in exchange for a few shiny beads^H^H^H^H^H"smart" devices. As for tablets: they may not have been the revolution that some people hoped for, but the lock-in to a walled garden happened anyway with the iphone. Apple has done more long-term damage to the computer industry than anybody else by convincing way to many software authors - who should really know better - that paying to write and publish software is sane. Instead of fighting this when it was small, we are now faced with a future where even the hardware can work against the user who wants a true General Purpose Computer. We've already seen BIOS lockouts such as the recent thinkpad "boot guard" idiocy. It will get really bad once we start to see Intel "SGX" and the "trusted execution environment" it is intended to enable[1]. So now we get to fight at the hardware level, too. As for using vulnerabilities to root the device - that is not a strategy to fight this, and merely cedes the fight to the people that are afraid of what it means to be "turing complete". Unfortunately, I suspect that we are too late. Fighting this trend now requires sacrifice. Stop giving any money to any business that uses these anti-user technologies. Yes, that includes Intel and many others. Stop writing software or making embedded products that rely on these kinds of features. Yes, this might mean quitting a nice job. No, I expect instead that the people that should know better will continue supporting the enemy by buying their products. I expect they will stay on as collaborators. [1] this should scare anybody that wants a future where that still has general purpose computers: http://www.arm.com/images/GP_Standardization_500.png http://www.arm.com/images/GP_Standardization_500.png
  - kuschku 12y ago
    TPM /could/ be nice, if you personally would control it, instead of some company burning the signing keys into the processor – because then you would be able to make a safe system.
    - pgeorgi 12y ago
      Except for the Enrollment Key, that's how TPMs work. And the EK is not so much an issue of "control", but of "privacy" - and as long as you control the OS, access to that key (or any other) can be mediated properly.
  - indians_pro 12y ago
    As someone who is a novice to computer architectures, is there some consensus in the research community about what will be a good replacement for the von neumann machines we are currently running? I mean, if you think about it, if we truly want to take control, shouldn't we attempt to break free, at a ground level, from all the technologies coming from (or dominated by) corporate structures (and government agencies)? x86 (and _64) and even ARM are all primarily developed by govt-influenced companies like Intel, yes? So what are the possibilities of us, all programmers and electronic engineers who want to support personal computing, to get together and develop a crowd-researched, crowd-designed, and (maybe) crowd-funded architecture to last the future. Of course, writing software for that architecture could take decades-centures (unless someone writes a perfect x86 emulation layer on that architecture), but at least that gives us a hope for the future, a backup to fall to if Intel pulls a full on 'google' on us. So are these just big dreams or is there an actual possibility of something like this happening? Especially if the community secures the funding of some visionary who's rich as Bill Gates (maybe the man himself) and on the side of the public? That way we'll be able to actually build a system from the ground up that is libre and transparent, without having to muck about with reverse engineering on the 'enemy's ground', so to speak, like corebook does.
    - pgeorgi 12y ago
      The problem isn't so much in architectures, but in silicon processes. HomeCMOS (http://homecmos.drawersteak.com/wiki/Main_Page http://homecmos.drawersteak.com/wiki/Main_Page) is notable in being the relatively rare project to look at this layer in the computing stack at all. Once you can do your own processors, the architecture is alright. To avoid running into licensing issues all the time, projects like RISC-V (http://riscv.org/ http://riscv.org/) can help - or open cores like Leon (SPARCv8), OpenSPARC-T1/2 (SPARCv9), openRISC and several more. The problem is, the silicon processes were optimized for investment heavy, large scale operations. To ensure the livelihood of general purpose computing we need a "3D printer for logic gates" (for lack of better term), even if it's economically and technologically less efficient (but not too much, obviously).
joosters 12y ago
That's a terrible position to take. We don't have to choose between security and freedom (to pick an OS). We can have both. Don't settle for lese!
RaleyField 12y ago
> it isn't a bad thing What isn't a bad thing? Shitty security in BIOS chips? Instead of reformatting your disk you have to detach eeprom chip that holds bios from mobo and connect it to another system to inspect it for infections / changes. I'm not sure this is even possible for most mobos and it doesn't cost nothing like reformatting disk costs nothing. EDIT: > using BIOS vulnerabilities will be the only way to install an unsigned operating system. Then I would rather not use those systems. Android phones are already at this level - I could run CyanogenMod but I'd have to first run a random blob I refuse run because there is no way to verify what that blob does. I'm screwed both ways. At these moments I remember Stallman wasn't completely crazy and wish Linux was licensed under GPLv3 so that the phone I bought wasn't tivoized.
- ghaff 12y ago
  >At these moments I remember Stallman wasn't completely crazy and wish Linux was licensed under GPLv3 so that the phone I bought wasn't tivoized. In which case Google would most likely simply have used a BSD variant as Apple did.
  - indians_pro 12y ago
    Ha. The strange thing about stallman is that his words of 'craziness' magically convert to words of wisdom, but there is always a delay in that process, which can go up to decades. This happens _always_. Joke's on us, despite knowing about this phenomenon, we never adjust for it.
- userbinator 12y ago
  but I'd have to first run a random blob I refuse run because there is no way to verify what that blob does There's always reverse-engineering... an option which I believe could be far more powerful, and Stallman should've argued for; the ability (and right) to figure out what some software does and modify it is the fundamental key to the freedom he argues for, and while having the source code can certainly help, it's not the only possibility. The power of RE comes from the fact that, while it's very easy to not release source code, it's nearly impossible to prevent someone from reading the binary on a general-purpose computer regardless of what the legal situation is.
xvilka 12y ago
It sounds very wise, after this: http://arstechnica.com/information-technology/2015/03/windows-10-to-make-the-secure-boot-alt-os-lock-out-a-reality/ http://arstechnica.com/information-technology/2015/03/window...

TerryADavis 12y ago

These are really stupid people who want to fight God, LOL. Guess who wins when you fight God?

deleted 12y ago
[deleted]
smorrow 12y ago
Upvoted because Terry Davis.
- jacquesm 12y ago
  Don't upvote it because it's Terry, upvote it when he contributes in a positive way to the conversation (which he has done on occassion).
deleted 12y ago
[deleted]
kuschku 12y ago
The House. The House always wins.
sobkas 12y ago
No one, because God doesn't exist.
- btzll 12y ago
  tips fedora
  - sobkas 12y ago
    your preference for linux distributions is unrelated to my comment

caligastia 12y ago

Automated discovery and exploitation of architectural flaws is merely the next step in the evolution of software. For the past few years we have been witness to a 'whack-a-mole' type of dynamic in the field of computational security. Exploits are published, a day later they become a Metasploit module, and a day after that anybody in the world can use it on everyone else in the world at the click of a mouse. If you are a full time sys-admin plugged into all the advisory mechanisms you may, for a time, be able to keep your systems patched, but the machines never sleep, they never blink, they never forget, and apparently, they never die. In the race against time, it is fair to say at this point that the machines have won. It may not be completely obvious yet, in the way that a tidal wave out at sea is only a small hump under your individual ship, but when it comes ashore, when the confluence of terrain and massive liquid power becomes manifest, then, of course, it is obvious. What appears to be happening is a kind of terra-forming activity, a new software layer is spreading, one that has the keys to everything - our social lives, our morning cup of coffee, our cars.. our nukes. This has an end condition, of course - and that is the total loss of control over our technological infrastructure.

dguido 12y ago
> Automated discovery and exploitation of architectural flaws is merely the next step in the evolution of software. > This has an end condition, of course - and that is the total loss of control over our technological infrastructure. Why can't you use the same technology to defend your software?
- EthanHeilman 12y ago
  Agreed. If you had a tool which could detect all of a particular class of exploits in your software one could just add it to your compiler so it would throw an error. Of course this assumes that automated discovery is not very computationally intensive, which in some cases it appears to be. The search space of a program is enormous. Instead one possible world is one in which exploits can be found automatically, but discovery requires massive computational effort. This seems extremely likely to me because exploits that don't require massive computational effort will be found and limited quickly eliminating the low hanging fruit.o Thus governments with the best algorithms and the most money/powerplants/datacenters/fabs have an advantage because they can patch their own software while developing exploits for other peoples software. The strategy comes in at: 1. how many exploits do you keep in reserve given a particular rate of discovery, and how and when do you use exploits? 2. How do you handle the case when you and the target are using the same software? If you start to patch it, the exploit might leak to the target. If you use the exploit before patching, the target might use it against you. Operationally protecting exploits from spies seems hard. A government with a technical advantage might well be a disadvantage to a less technically savvy government with a human intelligence advantage. To quote the Honey Badger video: >"You do all the work for us, honey badger, and we'll just eat whatever you find, how's that? What'daya say, stupid?" To avoid this a government might use the exploit development capability only defensively in peace time, keeping no reserve of exploits, until they have an immediate need. Of course this might weaken deterrence. tl;dr cyber

DennisP 12y ago

I'm reasonably technical but had no idea I was supposed to be security-patching my BIOS. I googled and found that (1) most of the articles about updating BIOS don't mention security, (2) finding BIOS updates for your hardware isn't necessarily trivial, and (3) applying the update is a fairly involved process with some risk of bricking your computer. Is there any way hardware manufacturers could make it as easy as OS updates?

pgeorgi 12y ago
The mainboard I use has an autoupdater in the setup screen. Connects to LAN (DHCP), requests updates, installs them. UEFI also allows updating from within the OS, and it looks like they formalized things a bit more, so that can be streamlined. (see https://blogs.gnome.org/hughsie/2015/03/03/updating-firmware-on-linux/ https://blogs.gnome.org/hughsie/2015/03/03/updating-firmware...) Then again, this is only necessary because UEFI is more complex than some operating systems, and thus provides the attack surface that they then have to defend like that.

1xtjjlunab 12y ago

In my view this is a result of hardware not actually being "hard". It would be far better to have a bug that comes back after a cold boot, as part of a known starting state, than to have a mechanism for "updates" (running software) that is inaccessible to the user/programmer. A static bug can be worked around, but a moving target is harder to compensate for, particularly if it is not viewed as user-programmable (for lack of documentation, or license, etc). To me, this demonstrates that the proper place for security is in software, at as high a level as possible for the purpose. Even secure boot is too low. Boots should be insecure, but repeatable. Turning a computer on should give full control - only then can you lock it down (whatever that means to the user...). Secure boot, if you want it, should just be a bootloader that verifies a payload, thereby protecting itself - not a BIOS-integrated feature, where the BIOS is opaque. A feature-full BIOS would only makes sense if it were immutable (and even then, there would be disadvantages), or (at the other end of the spectrum) if it were as programmable as the rest of the system - but until then, any unnecessary complexity or "features" are downright harmful.

morcheeba 12y ago
To do that, you'd also have to harden everything - including the hard drive's firmware - so you get the proper boot sector. Not all bios bugs can be worked around in firmware -- if the memory controller isn't initialized correctly, all processing is suspect. And if the manufacturer can't fix a bios, then it falls on the shoulders of the OS writers -- who do not have neither the motivation to fix 100's of board-specific problems. Worse yet, if I wanted to inject malware, I would pretend to be a motherboard manufacturer and submit bad kernel code to beleaguered OS people.

peatmoss 12y ago

Naive question: Is Core Boot in any way a potential remedy for the sad, sorry situation we're in here? I wonder when there will become a market for manufacturers to start releasing devices with hardware DIP switches or jumpers that need to be bridged for flashing purposes.

pgeorgi 12y ago
coreboot has a very different architecture, and we try to avoid having it parse external data (except for hardware registers). It also has next to no presence during the runtime of the OS (no API for the OS to call into, and to exploit) - which is part of the "no external data" approach. It's also much smaller: A minimum UEFI for QEmu that can barely boot into Linux loaded from SATA is 120kloc, coreboot (plus payload) for the same purpose are about 20kloc. These differences should stop some of the exploit approaches right from the start. Regarding the switches/jumpers, hardware is now complex enough to set up that a wakeup after suspend requires more data than what CPUs can store by themselves to revive memory without data loss. That data ends up in flash, so something needs to change in that area before a flash chip could be write protected with a jumper. (Disclosure: I'm a coreboot developer and no fan of UEFI)
- userbinator 12y ago
  Motherboards were produced with flash write-enable jumpers around the end of the last century, but my guess is that the cost savings of omitting the part and not requiring users to physically move the switch whenever reflashing BIOS, combined with what seems to be now perpetually buggy BIOSes needing constant updates, made them disappear. I think it's still a good idea, however. Regarding the switches/jumpers, hardware is now complex enough to set up that a wakeup after suspend requires more data than what CPUs can store by themselves to revive memory without data loss. That data ends up in flash, so something needs to change in that area before a flash chip could be write protected with a jumper. How much data is this? I thought it'd be stored in the CMOS NVRAM, which could be a better design.
  - pgeorgi 12y ago

AC__ 12y ago

Are these vulnerabilities exclusive to UEFI BIOS? The more I learn about UEFI, I am left with the feeling it is nothing but a wide open back-door and a method to "brick" pc's.

pgeorgi 12y ago
UEFI is designed to scale up - servers that can boot from network, which brings a certain baseline complexity. It doesn't help that the designers didn't want to set any rules and run everything through a central, extensible function call dispatch. The effect is that UEFI can load and run executables (from flash, disk, network), has a network stack and things like openssl (when did you last update your firmware's SSL implementation? :-) ), all of which process lots of ingress data - while maintaining a larger degree of control over the system than the OS that comes after it. So, it's not UEFI-specific per-se, but UEFI's design was optimized for the large scale (it pretty much started on Itanium, so there) and at a time when security wasn't much of a priority. Now they sit in that corner and look for ways out. Such as signature checks on executables (Secure Boot).

WalterBright 12y ago

A lot of these reflashable ROM exploits can be prevented with the simple addition of a physical switch or jumper that controls the write signal. With the writes physically disabled, no exploit would survive rebooting the system. Device makers can add such switches as a simple way to advertise being secure. I'd pay a few dollars extra for such, for example, hard disk drives that cannot have their firmware altered, and car computers that cannot be altered, etc.

mehycombo 12y ago

so...I see a nice thread here without a link to the researcher's actual work... speculate and bloviate much? http://legbacore.com/Research.html http://legbacore.com/Research.html