Hacker News Reader

Comment by userbinator | Hacker News Reader

Here's another reason why using a free BIOS like Coreboot is a great idea - if malware attempts to reflash it with an infected copy of presumably the original proprietary BIOS, it will be very, very obvious.

Another "tamper detection" idea, if you're OK with using proprietary BIOS and/or Coreboot isn't supported, is to add a small piece of code to the existing BIOS that simply hashes the ROM contents and prints out a human-readable string to the boot screen based on that. If it goes missing or changes, then you can suspect something happened. Of course, the trick is to not have everyone doing this with the same code, or backdoors will just detect and spoof it. I modded the BIOS of an old machine I have to do this, it prints out "Customised by {my handle}".

View on HN

This is an interesting idea, but don't try and expect humans to notice some random string (i.e. fingerprint, checksum). Instead, using something like OpenSSH's "randomart"[1]. It can be made such that any small change makes a totally different blob pattern (BIG bonus points for using COLOR!).

Possibly, this could even be chained into the background of the main OS load sequence, such that you see something like a Perlin-style colorful noise pattern during the longest part of the boot sequence. This could even hash other parts of the loader besides the BIOS, too.

The idea being that you (probably) won't notice if

    801EF9B138222F39EB2907634BC7FD47F9151919

changes to

    40AE7CE2796FB14526ABB92B67BC0F1423B85B96

Almost everybody would notice if the boot sequence wallpaper that you've seen for months/years

http://cs263.markaoyama.com/img/p5_abs_perlin_5_gens.PNG

changes into

http://cs263.markaoyama.com/img/p5_perlin_5_gen.PNG

(images taken from a very brief GIS of random Perlin noise articles)

There are many alternatives. The key here is to engage the human visual system. Proof of why this work: the popularity of font-lock-mode.

[1] http://superuser.com/questions/22535/what-is-randomart-produ...

TBH, I don't think this would be very effective at all. I manage hundreds of servers for businesses, and if I ever see a Dell splash screen it's purely by accident. With basically everyone using virtualization, it's a long time between reboots for physical servers to begin with. And when I do need to reboot the physical server, I'm usually sitting at home in my underwear, not looking at the console. We can manage most of the BIOS-level settings through Dell-provided tools, so even when we change BIOS settings, we don't go into the BIOS.

In my IT experience, anything requiring manual human checking basically doesn't get done after the first handful of iterations. If it needs to be reliable, it needs to be automated. My best guess is, you can install a package from Dell to enable BIOS info to be pulled via WMI (Dell OMCI I think). You can set all of your BIOS asset tags to some unique value (per machine) and if it changes, your monitoring software will see it and alert you. I'm not sure how easy this would be to spoof though. It might be trivial.

Fortunately, most of the models they mention have been out of warranty for some years now, and most businesses choose to upgrade to a supported model. For businesses who chose not to upgrade to supported models, it's usually a reflection of the immature management in charge of the business, meaning they make poor decisions in many areas, so a BIOS hack is way down the list of potential problems for them.

> In my IT experience, anything requiring manual human checking basically doesn't get done

I fully agree - that why I like this idea; it doesn't rely on humans actively doing something, and instead engages the subconscious. Because our brain is constantly making predictions about everything we perceive, we tend to notice (without trying) if something subtly violates those predictions. We see this effect when people describe how they felt something was "off" or "wrong" before some big event. They probably did see something important, but not enough to recognize it or parse it consciously.

Engaging the warning system that our fight-or-flight reflexes - which is very effective at processing visual sense input - is probably one of the more practical ways of getting past in this "humans won't bother" category.

Also, a visual-hash isn't really trying to be perfect anyway. It's just a trick that would be very easy to implement. It won't get anywhere close to catching all attacks. It would probably catch more than our current strategy of doing nothing. When you start from 0, any improvement helps. The only reason not to do this kind of scheme would be if it raised the costs, but I doubt that would be a problem given how much headroom we have in modern hardware.

This is nearly a good idea, except that by adding a random string and hashing it a few times, you can get an image that is approximately the same. Its might be reasonable to assume the NSA gets 100,000 to 1,000,000 attempts at low expense, of which at least a few hundred will be a similar color, and one of those will have a similar-enough pattern that people are less likely to notice.

It does create another level of protection for the user, and another hurdle for the attacker, but it still requires user diligence.

Seeing as we are starting from 0 (no verification at all), any improvement would be a benefit. This would simply be a cheap and easy way to catch "some" attacks.

Also, see my response to halfcat in a neighboring post.

Hello, I've put quick ASCII to Pixels converter http://sergeykish.com/randomart

Already looks fun, yet image magic depixelizer makes it awesome. I think once converted to custom tag it may gain adoption <fingerprint>05:1e:1e:c1:ac:b9:d1:1c:6a:60:ce:0f:77:6c:78:47</fingerprint>

I actually don't know how this would become obvious. Do you look at your server screens while they boot? Any attempt to checksum the BIOS from the operating system could be easily bypassed by simply regurgitating the OEM BIOS if anyone reads it.

Do you look at your server screens while they boot?

Long enough to see the POST screen where I put the message:

    Award Modular BIOS v4.51PG ==Customised by XXXXXXXX==

is pretty hard to not notice, especially if it suddenly changed back to string in the OEM BIOS. The code I inserted basically computes my string by "encrypting" the original string with some constants derived from the whole BIOS image, so if the BIOS was only partially modified it turns into rubbish, and if it was replaced, then the string reverts to the original one. The point is that the BIOS on that machine is globally unique, has a feature that I can easily identify, and would be difficult if not impossible to forge by an attacker with only the OEM BIOS. I came up with this shortly after the infamous CIH virus emerged.

Ditto for the NSA trying to flash a backdoored Coreboot: they would have to know exactly the customisations I made to my BIOS to replicate them, and if they did, then I'm probably pwned anyway. Backdoors in an offboard option ROM would certainly avoid modifying the BIOS, but I guess a similar mechanism could be used to customise one to easily detect its modification.

If the NSA are targeting your systems they will use a backdoor'd version of Coreboot.

And in this case the malware is lurking in the RAID cards expansion ROM, so you wouldn't even notice a change at boot anyway.

Please, continue...

Coreboot is a great idea, and I actually considered using it, but the project looks woefully under-powered for the role it hopes to play: the list of supported devices is very sparse and consists of really old models, mostly; even the supported systems have issues and/or untested functionality. http://www.coreboot.org/Supported_Motherboards

I haven't looked into the relationship Chromebooks have with Coreboot: supposedly, Chromebooks use Coreboot, but how is it possible that they restrict the usage of OS to a signed one: do Chromebooks use modified Coreboot? And why is some models' status listed as "Unknown" in Supported Motherboards list?

So, I would love to use Coreboot and would actually consider going into some reasonable trouble to make it work on my hardware (including actually picking hardware that it supports), but I really don't see how it would be usable even for an enthusiast, and I don't see the situation changing anytime soon.

They restrict use to a signed OS through their payload. coreboot only does hardware initialization, then passes control to other software in flash that handles loading the OS and policy surrounding it.

As for the "Supported Motherboards" list, it's automatically generated from reports that are sent in through a tool. Google doesn't do that (yet?), so they're not listed as supported. Still better than our old, manually maintained list, that got stale fast (with false positives, which are much more annoying from a support standpoint than false negatives)

Chromebooks/Chromeboxes use a forked Coreboot:

https://chromium.googlesource.com/chromiumos/third_party/cor...

Most of the Chromebook/box devices have a physical write-protect that can be removed allowing re-flashing with modified firmware.

ok, so it means that even for a Chromebook, Coreboot support is not a given.

All x86 Chromebooks (except for the CR48 prototype) use coreboot.

For ARM Chromebooks the situation is more complicated - coreboot's ARM support was developed by the Chromebook firmware developers but it seems they missed a deadline or two (no surprise with an architecture bringup), so some of those devices ship with u-boot while coreboot does have support for them.

In "Latest known good" column in "Supported Motherboards/Laptops" it says "Unknown" for 5 Intel x86 Chromebooks. http://www.coreboot.org/Supported_Motherboards#Laptops

I understand it means that to the best of Coreboot developers' knowledge (and who knows better than them, right?) noone ever tried to run open-source builds of Coreboot on these models. Consequently, it is overwhelmingly likely that Coreboot (the open-source version that we have access to, not the one in the Googleplex) won't work. Am I mistaken?

I considered using C720 Chromebook with open-source Coreboot, but, alas, it says "Unknown" for it, too.

No, it means that noone bothered to send in reports.

http://johnlewis.ie/ provides non-Google coreboot images for many Chromebooks. They claim having tested each of their binaries and from looking at the support forums, they have a fair share of users.

Also, the "Googleplex version" of coreboot can be found at https://chromium-review.googlesource.com/#/q/project:chromiu... (though it can be hard to pinpoint any given released firmware to a concrete commit there - they're working on it)

If noone bothered to send in reports, we cannot assume it is really working, can we? After all, without testing, software most certainly doesn't work.

Who is this John Lewis guy and why isn't his work the part of the official Coreboot images?

There are no official coreboot images.

John's images are kind of a coreboot distribution, as is libreboot (http://www.libreboot.org/)

What you really need is

- A piece of hardware under the user's control that provides cyptographically secure key material that allows the BIOS to boot.

- Attestation by the booted thing that it is intact and untampered with.

Both of these need to be inspectable by the user. For the former you can use a dongle with a key on it, and this is probably testably secure by an end-user (we can talk about trusting silicon and your tools, but if you use multiple platforms and toolsets for verification that's probably pretty reasonable).

Knowing that the "enemy side" (the BIOS) hasn't been suborned is pretty hard and requires hardware-level support that you're not going to see outside of video game consoles.

For the truly paranoid, your best bet is to use a computer that has no physically attached peripherals that you can't monitor (e.g., USB). So, USB-attached network adapters and so forth.

This stuff is hard.

Why would the malware not hash the current BIOS and show you the same hash?

Reply on news.ycombinator.com