
Hacking BIOS chips isn't just the NSA's domain anymore - mseri
http://www.wired.com/2015/03/researchers-uncover-way-hack-bios-undermine-secure-operating-systems/
======
caligastia
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.

~~~
zby
"It might be argued that the human race would never be foolish enough to hand
over all the power to the machines. But we are suggesting neither that the
human race would voluntarily turn power over to the machines nor that the
machines would willfully seize power. What we do suggest is that the human
race might easily permit itself to drift into a position of such dependence on
the machines that it would have no practical choice but to accept all of the
machines decisions. As society and the problems that face it become more and
more complex and machines become more and more intelligent, people will let
machines make more of their decision for them, simply because machine-made
decisions will bring better result than man-made ones. Eventually a stage may
be reached at which the decisions necessary to keep the system running will be
so complex that human beings will be incapable of making them intelligently.
At that stage the machines will be in effective control. People won't be able
to just turn the machines off, because they will be so dependent on them that
turning them off would amount to suicide."

~~~
doublextremevil
is that from the unabomber manifesto?

~~~
Cyranix
For those wondering whether parent comment is hyperbole: yes, that is quoting
Ted Kaczynski's manifesto.

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

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

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

------
DennisP
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
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...](https://blogs.gnome.org/hughsie/2015/03/03/updating-firmware-on-
linux/))

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.

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

------
peatmoss
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
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
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
CMOS NVRAM addresses 256 bytes (minus 16 for the clock).

Unfortunately that's not enough. Maybe things could be stored smarter, given
that the data should have some structure, but the raw format is ~2000 bytes,
IIRC.

------
mehycombo
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)

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

------
TerryADavis
These are really stupid people who want to fight God, LOL.

Guess who wins when you fight God?

~~~
sobkas
No one, because God doesn't exist.

~~~
btzll
_tips fedora_

~~~
sobkas
your preference for linux distributions is unrelated to my comment

