NIST Publishes Draft Guidelines For Server BIOS Protection

hypnosec writes "The U.S.'s National Institute of Standards and Technology has come up with a set of proposed guidelines for security of server BIOSes— the mechanism on which most modern day computers rely during boot up. Recently quite a few instances of malware have been known to persistently infect computer systems, and cannot be removed even on OS re-installs. NIST is proposing a set of measures through which the BIOS can be made more secure and resistant to such firmware manipulating attacks. Mebromi is one such Trojan. NIST published the draft guidelines [PDF] earlier this week and has proposed four different features through which the server BIOSes can be made more secure: authenticated update mechanism; secure local update mechanism (optional); firmware integrity protections; and non-bypassability features."

Comments

Stupid and wrong

[jmorris42]

Locking the BIOS with signed updates and crap is exactly the wrong way to go. It means there will still be bugs to exploit. But the forces seeking to lock down the PC will advance yet another step under cover of security theater.

The correct solution is to give the machine a one way gate so that after POST the BIOS can't be updated, period. Electrically impossible. That would require an updater in the BIOS and either storing the extended config now flashed into the same chip with the BIOS to either go elsewhere or the flash chip to be smart enough to have a protected area and an unprotected area and only the protected area be unrevokable without a full reboot. It also should go without saying that the BIOS can't look at the unprotected area before the big switch to prevent buffer overflow attacks from getting into the BIOS while the flash is writable and/or stopping the user from invoking a clear extended data function.

A minimal rescue program in mask ROM would be gravy of course. Lets see the leet warez doodz get past that one. Wouldn't put anything past the NSA though.

Re:Stupid and wrong

[dgatwood]

The correct solution is to give the machine a one way gate so that after POST the BIOS can't be updated, period.

That would likely prevent BIOS updates from being provided by your OS vendor, which might not be the best idea. The correct solution would be to require that every BIOS update provided after POST be signed, while still allowing unsigned updates to be installed by the user manually from within a menu in the BIOS UI prior to booting.

Re:Stupid and wrong

[dgatwood]

Actually, it's not easy. A trojan horse can draw the same UI, write the same file to the flash drive, and a naïve user would probably dutifully follow the instructions because the user would not know any better. Your "solution" is no better than the status quo.

Allowing a power-user (someone who knows how to hold down the magic keys and isn't afraid of the BIOS UI) to install an unsigned update explicitly and manually is one thing. Such a user can be assumed to know enough about what he or she is doing to understand the risks of downloading a BIOS update from an untrusted source. Allowing unsigned BIOS updates to be installed by average users as a part of their normal day-to-day update process, however, is another thing entirely, and is a very bad idea.

Re:Stupid and wrong

[msauve]

That would require an updater in the BIOS and either storing the extended config now flashed into the same chip with the BIOS to either go elsewhere or the flash chip to be smart enough to have a protected area and an unprotected area and only the protected area be unrevokable without a full reboot.

Let me change that from something completely unparsable, to something simple.

All that's needed is a jumper on the motherboard which must be closed in order to modify the BIOS.

Re:Stupid and wrong

[VortexCortex]

... And how is this different from secure boot?

Re:Stupid and wrong

[dgatwood]

I suppose updating your BIOS is not extremely common in the Windows world, though I've done more than one BIOS update over the years despite having used only a single-digit number of devices that actually have a BIOS, so it isn't that rare. And I would agree that updating the BIOS on server hardware is particularly exceptional.

The problem is that whatever standard somebody comes up with for servers is liable to trickle down into consumer goods. We'd be better off deciding on a single set of good, sane standards that everyone can live with, including consumer product makers. Coming from the Mac world, where nearly every piece of hardware has seen at least one EFI or SMC update, making it "almost impossible" seems like a very bad idea for general-purpose hardware.

Re:Stupid and wrong

[fustakrakich]

Yeah, my first thought was, if you want protected BIOS, I suggest it be read only, put it in a socket, and if needs an update, you have one shipped, or go to your local store and get one. Damned if the socket won't be bigger than the whole machine pretty soon...

Re:Stupid and wrong

[jmorris42]

You could still allow lights out. Most servers support boot over net so the BIOS is required to have a partial IP stack. Just allow bringing in the new BIOS via tftp from the IPMI remoted BIOS console if nobody is available to insert a USB stick and you don't want to allow reading it out of a FAT partition on the primary drive.. It could print an SHA-256 sum of what it downloaded to ensure you weren't hit by a man in the middle. Hell, it could even check a signature against a key in the current BIOS and warn if it was signed by someone else. Lots of possibilities. But if it is electrically possible to write the BIOS after the bootloaded is executed security isn't really possible.

Re:Stupid and wrong

[chmod a x mojo]

I don't know about where you work / what shady operations you run with, but we don't let clueless idiot users either reboot or have physical access to our servers - you know, what the article is talking about- in any of the places I contract to. Either you are vetted to know WTF you are doing or you don't get to so much as SEE the machines.

Re:Stupid and wrong

[crispytwo]

Along the same logic, I would argue, why do we need to have the bios have built in writable flash memory these days? So many simple options to solve this come to mind, but if I really wanted to update the bois - which is incredibly rare - couldn't we be a little more hands on and use a USB key for example?
here's a possible solution:
- I could pull out a small USB drive/key from the special slot on the mobo
- stick it into my USB slot on a running computer
- write a new bios to it with my fancy updater tool - simple so far
- stick it back into the mobo (it could even lock in with a clip for those who vibrate a lot)
- (re)boot
- new bios is read from the -special- USB.

bonuses:
- if something goes wrong - place in a new different USB drive/key
- test with a different USB drive/key to see if the update is better, then update the special one
- I can think of others too!

what I mean by "special USB", is that it is only accessed and read by a booting bios, so doesn't have pass through or presence to the OS. It may be especially small.

I seem to remember somewhere that we don't really need much of a BIOS since the kernels do all the probing for themselves a second time anyway, so in many respects we have 2 boots, once (slowly) in BIOS, which is promptly thrown away, and another in whatever OS you might load.

Re:Stupid and wrong

[sumdumass]

It depends on if you use the computer for simple file shares and word processing or if it is used for different things like application servers and so on. Drivers have bugs in them all the time. Some bugs simply cannot be worked around. Changes in the Kernel for windows XP service pack 2, ended up with quite a few bios updates and driver fixes (especially for printers) needing to be made. I've seen applications that caused memory issues that bios updates fixed too.

It's like the old saying for microsoft office where 80% of the people will only used 20% of the features or something like that. The vast majority of people will not notice problems in what the bios and or driver update fixes. Manufacturers don't really create and release BIOS updates or diver fixes because they want to keep an idle team of programers busy for a while. It's generally to fix something and that something has caused someone problems.

Re:Stupid and wrong

[Joce640k]

We have a movement towards lights out datacenters, but even so, some things should just have to be done in person.

What you need is a physical switch on the front of the machine and a robot to go and flip it for you.

The robot can be padlocked when not in use.

Re:Stupid and wrong

[SuricouRaven]

Secure boot works using a cryptographic signing system: The board will only boot code signed by one of the Powers That Be - an organisation big enough for motherboard vendors to bother including the public key for, like Microsoft. This places smaller, niche players at a serious disadvantage. Which is probably the idea. An alternative non-market-distorting approach would be fingerprinting: The BIOS/EFI hashes the MBR (plus however many additional sectors the MBR specifies in an agreed-upon location). If the result doesn't match a stored fingerprint, it can generate a warning and refuse to boot until the user either restores from a matching backup or else selects the 'I intentionally changed the OS' button - in which case the newly-computed hash replaces the stored one.

If Secure Boot were really about security, that is how it would work. But it isn't. It's about creating a barrier in the market which can only be overcome with a pile of cash or good business connections, something that poses only the slightest inconvenience to Microsoft but a major difficulty to linux.

Re:Stupid and wrong

[hairyfeet]

I have, there was a BIOS update that I had to apply that gave me better support for faster RAM on my laptop. That said don't forget we are talking servers here and server BIOS is a lot more complex than your average desktop.

Re:Stupid and wrong

[fustakrakich]

Security or convenience... Pick one

Re:Stupid and wrong

[evilviper]

I demand both.

Step one?

[girlintraining]

Step one: Kill UEFI with fire.
Step two (optional): Everything else.

I'm perfectly serious -- If you have UEFI, it doesn't matter how secure everything else is, you're screwed, and you're screwed because Microsoft asked the companies making the motherboards to screw you for the sake of adding yet another failed DRM attempt to their next operating system: Windows 8, "Explode On Launchpad Edition".

Re:Step one?

[Microlith]

UEFI is not the problem.

The problem is that the security architecture that was added to UEFI was designed by Microsoft and (obviously) favors them completely. Unfortunately, they're the only OS level software developer in the UEFI Promoters group so they pretty much get whatever they want and, I suspect, can overrule complaints from "Contributors."

A real fair solution would have had such keys administered by the UEFI Foundation and included the ability to auto-add keys from read-only media.

Re:Step one?

[Aryeh Goretsky]

Hello,

A list of OS software developers who are members of UEFI:

• Apple
• Canonical
• Cisco
• Cray
• Fujitsu
• Hewlett-Packard
• IBM
• Microsoft
• NEC
• Novell
• Oracle
• Red Flag
• Red Hat

And there are also other companies who work in the same neighborhood (CPU manufacturers, firmware developers, etc.). Source: UEFI Membership List.

While I understand (and, to some extent, sympathize with) the desire to hold Microsoft solely responsible for every activity in the computing industry, this is clearly a joint effort across the industry to replace a two decade-old invention whose time has come. And as far as I know, the largest installed base of UEFI firmware—albeit an older version of the standard—is Apple, a company not precisely known for having a cordial relationship with Microsoft.

Regards,

Aryeh Goretsky

Re:Why NIST?

[Anonymous Coward]

I would say that an organization called the National Institute of Standards and Technology is exactly the type of organization that would set standards for computer BIOSes. Doesn't mean you have to follow them, if you're worried about it.

All NIST publications are open and available, so it's not like they're going to sneak something in that no one knows about.

Management Port anyone?

[Igot1forya]

I think for high-end hardware for servers and stuff, an RS232 serial port only accessible when enabled for updates should be the only conduit for installing BIOS updates. Think of it as a management port. Us network guys do this already via SSH, Telnet and TFTP and you guessed it, SERIAL already. I don't know of any virus's able to jump a physical divide like a serial port.

Servers are different

[Esteanil]

To put it very simply, servers need to be able to resist things like Blue Pill and other advanced persistent threats.
This is vital for secure data processing and storage, and therefore needed by many organisations, businesses and governments.

I can't wait until the first good, fairly inexpensive servers come with this option. That's the point at which I'm changing career paths over to Sales ;-)

Guarenteed-clean factory reset

[davidwr]

Computers, especially servers, need a guarenteed-clean factory reset procedure.

How it might work:
IF you boot with a certain jumper set, an immutable "rescue BIOS" boots the computer into a "recovery mode." This may be as simple as booting off of a specific location, such as the first n sectors of whatever is on SATA drive 0. The "rescue BIOS" doesn't need to be any more complicated than a read-only copy of the real BIOS using factory-default settings instead of the "BIOS settings" the user or virus set.

IF you have a known-clean, preferably but not necessarily digitally-signed boot disk attached, you will be able to clean your BIOS, and, once that is clean, the rest of your system. Presumably the vendor would supply a bootable DVD or CD for this purpose.

Re:Easy solve

[NemoinSpace]

A physical jumper would cost extra money. How about a NON FLASHABLE bios? - we used to have them. We used to have non shitty programmers that could write code that didn't have to be updated every 6 months. There was a time a flashable bios was justified. Now it's just a cross between laziness and DRM.
Seeing this article reveals we have some very stupid people in some very high places in the IT world.

Phrack citation

[cachimaster]

I find interesting that the draft cites a Phrack issue. If a NIST cite do not legitimize a journal, I don't know what it does.

Re:Easy solve

[cachimaster]

A physical jumper would cost extra money. How about a NON FLASHABLE bios?

No, sorry that's crazy. BIOS updates are essential to fix security bugs. A non-flashable bios would make your system *more* insecure.

The physical jumper would help in some situations, but not all, let me explain: I'm one of the guys cited on that draft, we made a pretty generic bios rootkit that worked fine. One of our attack scenarios inclueded having physical access to the device before the victim, I.E. you receive an already rootkited laptop/PC. A jumper wont help in that case, only a signed BIOS would. It sucks because it smells a lot like DRM but very often security and freedom are mutually exclusive.

Re:Sounds good to me!

[Grave]

Except that when it comes to servers, the differences are far fewer. Target just a few different variations of a Dell or HP motherboard, all with very similar architecture, and the potential for havoc is great.

Easier

[Weaselmancer]

You should only update your BIOS when you mean to. I'm of the opinion that it's something that you should mean to do, not something that should just happen automatically ever. So it doesn't need to be writable 99.999% of the time. So how about a switch that toggles the write enable pin to your bios flash on the front panel of your box?

Want to update your bios? Power down box. Insert CD or USB key. Flip write enable switch. Power up. Flash bios then power down. Flip switch to write disable. Boot.

And for an added measure, don't let the thing ever boot from an MBR if the switch is in "write" mode.

Easy peasy.

Re:Easier

[SuricouRaven]

It doesn't need to be a hardware switch. It can be a simple non-writeable flag, the hardware designed such that once set it can never be un-set short of a power cycle. All the BIOS/EFI need do is set the flag prior to booting the OS. If you want to update the firmware, you'd need to do it through the setup screen, which runs before the OS. You'd still need physical access (Or at least a network KVM device) which is the only real way to ensure security for something this low level, but that seems to be a small price to pay. This isn't something that needs to be done to servers routinely, it's a once-every-few-years thing at most, and it doesn't even need them taken out the rack or opened up.

Signed updates?

[Weaselmancer]

Signed updates make 100% total sense.

Because keys never get leaked or cracked, right? That never happens. Now if you'll excuse me I'm off to go watch a blu-ray movie on my Linux box.