Posted
by
timothyon Friday August 24, 2012 @09:55PM
from the why-stop-with-servers? dept.

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

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.

For not much money, a pre-processor could check the status of the ROM-based bootstrap, then sniff the MBR and where it points to for integrity, then say, yo: CPU, go ahead. If the first X:Y bytes don't read correctly, throw a code and refuse to start. How much are small GPUs and slow ARMs? Gotta be faster than watching Dells and HPs boot these days (go get coffee, we'll be right back at ya)....

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.

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?

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?

Sure would make updating the thousand-odd servers in our datacentres a bit of a pain. Especially the ones we don't have easy physical access to.

So how about a switch that toggles the write enable pin to your bios flash on the front panel of your box?

This sounds like a mess, as it would interfere with organizations rolling out common baseline BIOS versions, and upgrading them in batches,
or make it prohibitively expensive.

It would result in organizations adopting a standard operating procedure: Make sure the Write Enable switch is set to ON,
and Epoxy it into place, to ensure BIOS update doesn't accidentally get broken in the future, by some

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 sma

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.

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.

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.

OK, this is supposed to be for servers, only accessed by authorised IT guys. Simple enough.

Let the hardware vender spend the half cent on a jumper right by the BIOS chip. Shut it down, pull it off the net, unplug the drive cables, etc. Plug in the damned jumper. Boot up, flash the ROM off a verified safe flash drive. Shut down. Pull the damned jumper. Hook the cables back up, hook back to the network, close the box reboot. Nice & safe, rig the BIOS where if the jumper is CLOSED, update is possi

And expediency gives them the excuse to hire maybe 5% of the IT guys they really need? Yeah, it cuts down the overhead when everything is running smooth as butter, but you hire IT guys to fix things when they fuck up. That's the whole point of having them there to begin with, otherwise you'd just hire a contractor company to come in and do the servicing.

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.

Not, if the functionality was enabled only on a USB port inside the chassis, or via the Management controller virtual USB (e.g. iLO)

The average user is not going to take a screwdriver, open their computer case, and find the USB port on the motherboard, to plug into.

That's not significantly different than allowing an unsigned BIOS, security-wise, but requires a lot of extra effort if you're testing/developing custom BIOS firmware images. It's certainly a valid alternative; I'm just not sure it buys you anything.

I think preventing casual bios updates from any source would be the preferred and correct solution for servers. We have a movement towards lights out datacenters, but even so, some things should just have to be done in person.

I'm not opposed to BIOS updates only being performed from an attached flash drive and completely impossible while the machine is running as jmorris42 proposes.

Also, remember how often people update BIOS in the first place. Hardly ever. How often is an operating system wiped to get r

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 [apple.com], making it "almost impossible" seems like a very bad idea for general-purpose hardware.

And I would agree that updating the BIOS on server hardware is particularly exceptional.

WTF are you talking about? Every time a server is having hardware issues, one of the first steps the trained-monkeys at Dell tell you to do is update the firmware (if newer versions are available), including the BIOS.

Welcome to/., where a prereq for sweeping generalizations is that you don't actually have any experience in the field...

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

Honestly, how often do you update your BIOS? Drivers, yes. But BIOS? Have you ever "needed" to do it, in the lifetime of your computer? Apart from to correct bugs that never should have shipped in the first place I mean.

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.

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.

while still allowing unsigned updates to be installed by the user manually from within a menu in the BIOS UI prior to booting.

I would favor, providing a mechanism in the boot menu for the user to add their own signing keys public RSA key, and set what permissions each signing key has.

The the signing authentication method for BIOS, could then be re-used for "Signed MBR bootcode" verification, and optional signing of a temporary read-only disk partition for booting an integrity-protected lightweight O

To put it very simply, servers need to be able to resist things like Blue Pill [wikipedia.org] 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;-)

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.

Without a special flash chip or adding another one your simple electrical fix isn't practical. The ESCD info typically gets reflashed on a pretty regular basis if anything in the machine changes. To save cost it is usually in the same physical flash with the BIOS. Also, your simple jumper would preclude lights out server management.

No, it has to be a gate that can only be cleared by a cold start once flipped on.

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

If I remember correctly that's how it used to be. BIOS could only be changed by changing out the chip and re-flashing the EPROM (when we had EPROMs). But you're right, there are many powerful companies who are desperate to see the "top down" model enforced on computers, from entertainment companies to software companies.

It's just a more profitable model. Apple taught the industry that. Magins on hardware are painfully thin, but if you strictly control the hardware you can use it to promote all manner of far-more-profitable things. Like app stores.

Signed bootloaders with hardware keys are exactly the right way to go, except that the implementation forces Microsoft software in this evolution. As in other realms Microsoft is trying to preempt our progress with the mandate that we also buy their products. But their products are not prerequisite to progress. They are anathema to it.

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.

I sense sarcasm... and good point. No idea is perfect for every situation.

After thinking about it a bit, it might just be a nice way to update the bios on 100s of servers.suppose this:You have 100s of extra USB keys (say colored blue), then update the bios on all of them the same way on your secure workstation. Spot test a few (or all of them) independently, and then walk through your server farm swapping the keys (old ones, black, with new ones, blue). Perhaps it can be hot-swapped - less server down-time.

Server farms are lights-out. Having people walk around to physically switch around hardware is going completely backwards...

To me, your idea reeks of bringing back the good old AT&T operators, manually patching calls through a switchboard... Positively primitive, extremely inconvenient, very expensive, and utterly impossible to scale-up.

Back when I was coming up the only way your BIOS was updated was when you opened up the machine, pulled out the old BIOS chip and put a new one in. Yes stone age I know, but there was no way for code running on the computer to do anything to the BIOS at all.

Sometimes to old ways are the best way. You want real security at the BIOS level? Burn the code into the chip. It is a one time deal. You need a bios update? The manufacturer sends you a new chip. Better yet, you want a better BIOS? Burn your own.

If only they could have some kind of system where a physical device allows or prevents the BIOS from being modified. We could come up with some kind of crazy term for it, like "jumper" just to get really wild!

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

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.

I know that it was built originally by Intel. They did it more than 10 years ago when Itanium came out. But the security infrastructure didn't exist until UEFI 2.31. That is what I suspect was designed by Microsoft. Your link doesn't say anything to that respect.

that should be a big hint about what UEFI is all about.

No, I can see the value in replacing the BIOS with something newer. EFI existed at all because Intel was silly NIH.

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

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 [wikipedia.org], a company not precisely known for having a cordial relationship with Microsoft.

No, it's a standards group. That means every company has two goals in mind:
1. Make it a good, workable, effective standard which solves all deficiencies of the previous standard in the most practical and optimal manner.
2. Maximise their own business benefit from the new standard.

Goal two usually means things like ensuring the standard can only be implimented using patents they hold. In this case, Microsoft's goal two plans included finding some way to obstruct linux, which is a looming threat to them on

I see people keep throwing the list at me, without looking at the tiers.

Simply sorting it for "software developers" is one thing, ignoring the membership level is another thing entirely. Microsoft is the only pure software firm in the Promoters group, who far and away pay the most for their involvement in UEFI.

this is clearly a joint effort across the industry to replace a two decade-old invention whose time has come

It is, but that does not say anything about the security mechanisms other than that the Cont

> I've often wondered why we don't see more persistent infections given how firmware is handled these days.

Because writing malware for bioses and firmware means you have to be able to insert your bits of evil into firmware for a multitude of versions of Phoenix BIOS, AMI BIOS, EFI, etc. And that's hard work.

Just look at the OpenBIOS project. Just trying to get that to work on a bunch of motherboards and to stay up to date is sisyphean.

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.

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.

Congress has the power to ' fix the standard of weights and measures' by the constitution. NIST is the body that does that. They also happen to pay for a lot of measurements of material properties (density, hardness, etc) and publish them online for free. NIST does sometimes publish standards, but those standards don't carry the force of law, nor can NIST pass laws about the standards. If you want to be paranoid about government overreach, just watch congress, they're the ones that make laws.

AHEM.. You do understand that a single source to define standards of weights and measures is kind of one of the single most KEY parts of Commerce, right? That they were established to make sure that things like "a pound" are defined, and tested and validated.

Perhaps you should read up on some of the other standards NIST has, like time. They are THE stratum 1 server for most people that use NTP. (time.gov).

You do understand that a single source to define standards of weights and measures is kind of one of the single most KEY parts of Commerce, right? That they were established to make sure that things like "a pound" are defined, and tested and validated.

Rubbish. It's just another tool of a socialist government trying to control the people.

In a true free market, sellers would be able to call anything they wanted to a "pound", and if a buyer wasn't aware of how much each and every seller's "pound" actually was

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.

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.

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.

And when the attacker inevitably finds an exploit and installs a rootkit anyway, they'll change the keys so you can't install the officially signed BIOS.

And when the attacker inevitably finds an exploit and installs a rootkit anyway, they'll change the keys so you can't install the officially signed BIOS.

Exactly. You can't really protect a generic computer from unknown software bugs. Also if you have physical access is game over anyway, you could replace a big enough piece of hardware with a malicious one and that's it, pwned.

If that scenario, the victim is screwd no matter how securely the bios is protected. Any attacker good enough to hack firmware should be quite capable of exploiting the hardware itsself. Time-delay system-killers, a hacked network card that starts sending duplicate packets to any IP that gives it a key string of bytes, a keylogger that stores the passwords entered when installing the OS for later retrieval (Possibly via hacked network card). It can all be done, because things like that have long been done t

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.

If the bad guys had access to the internals of the computer, they could just physically replace the ROM chip, no? And they could make the hacked BIOS look exactly like the original. Even if the ROM chip wasn't removable they could connect their flasher device directly to the pins of the chip.

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.

This is idiotic. Back when those non-flashable BIOSes existed, the BIOS was damn tiny. These days it's still got all that legacy code, while also handling ACPI, power management, fan speed, configuring CPU/PCI/RAM bus speeds and multipliers (instead

exactly. increasing a systems complexity for the sake of convenience is counter to security. It was called a BASIC IOS for a reason.I can't guarantee that existing code is 100% non exploitable, but if you can't get it right after 30 years, you should be doing something else. This whole security scare is a false dilemma, people who need secure systems know how to do it.
Companies who need to reinvent market share know how to do that too.
There is a reason we use physical keys to control nuke's, rather than

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.

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.

At the very least, the motherboard's essential components - basic video, keyboard/mouse/USB, network chipset, recovery-boot-device (e.g. SATA 0, but not necessarily the drive you normally have attached to it), etc. would work right. Once you've wiped and reloaded the "real" BIOS, you can use it to boot a known-clean disk and update to the current manufacturer's BIOS. From there you can boot to a known-by-you-to-be-clean disk even if it's on a device not supported by the recovery BIOS.

Getting to a jumper is not always an easy task. When you have a 2 or 4 U server bolted into a rack of 4 or 5 other servers, it is somewhat of a major undertaking pulling it out, taking the cover off, hooking things back up to flash, putting the cover back on, then bolting it back in. You cannot always get to the back of them so holding it half in and out while reaching behind and looking at the reflections of a mirror to see what you are doing complicates things too. Also, when you have something like a 2 o

Too hard? Make it a fucking button somewhere. Too insecure? Make it a key lock.

This is probably the way to go if a jumper is going to be required. You get a bunch of servers in a rack or cabinet and it starts getting complicated to get to the jumpers. But I would make it open nothing closed flash. This way if the wires to the switch get pinched and cut for some reason, it fails to safe (open- no flash).

With Intel chipset, i could say only one thing: FORGET about security. Why? Pretty simply, the chipset itself is with already built-in remote control module. Even before booting. Oh, nooo, not true, even if the computer is shut down (but is still connected to the power socket of course).

- implementing the braindead ACPI spec which is often prone to bugs- housing laptop's EC code in some systems which controls power management and the fans (not unheard of this to have bugs)- responsible for applying installed CPU microcode updates (fixing CPU bugs before the OS starts)- faking nonexistent hardware on dirt cheap systems via SMI (not sure if this is common anymore, and bugs may lurk here)

Large environments require BIOS updates more than the average user, and may require some type of update across hundreds of servers (or more) if a bulk-purchase was made. These need to have the ability to be scripted. A solution sacrificing both convenience and security would be to require a BIOS password to be set on first boot. This could be scripted so that when a server comes into a corporation, it gets a BIOS password, and then this password is required to write any BIOS (or even firmware-level update)

So, for starters, people appear to confuse secure boot functionality in UEFI with secure BIOS upgrades. The former is required by new Windows 8 hardware profile and is provided as specified by the UEFI standard. The latter is what the NIST spec is talking about---to prevent firmware malware attacks.
The idea is simple---during normal operation BIOS is readonly; firmware updates write the new image to a temporary area, and upon reboot the old firmware takes over, realizes that there's a new firmware availab