NIST Publishes Draft Guidelines For Server BIOS Protection 141
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."
Stupid and wrong (Score:5, Insightful)
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: (Score:2)
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)....
Re: (Score:3, Interesting)
Re:Stupid and wrong (Score:5, Insightful)
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.
Easier (Score:5, Insightful)
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: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:3)
Signed updates? (Score:3)
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.
Re: (Score:3)
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 (Score:5, Informative)
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: (Score:3)
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: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
it would also allow you to import your key once and sign test bioses as you work without rebooting to load
Re: (Score:2)
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
Re:Stupid and wrong (Score:4, Interesting)
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.
Re: (Score:2)
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...
Re: (Score:2)
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
Re: (Score:3)
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: (Score:2)
BIOS updates
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.
Re: (Score:2)
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 offi
Re: (Score:3)
Re: (Score:2)
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
Servers are different (Score:3)
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 ;-)
Re:Stupid and wrong (Score:5, Insightful)
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: (Score:1)
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.
Re: (Score:2)
BTW, if the lights are out, you're not gonna be managing anything.
Re: (Score:3, Insightful)
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: (Score:1)
That'll work well when you need to update the BIOS on hundreds of servers...
Re: (Score:2)
Security or convenience... Pick one
Re: (Score:3)
I demand both.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re:Stupid and wrong (Score:4, Interesting)
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: (Score:2)
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.
Re: (Score:2)
Spoken like someone who has never managed a server farm...
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.
Re: (Score:2)
It used to take a socketed part, then it took a jumper or switch. I'd suggest going back to the jumper or switch. It's the simplest solution with the highest level of security.
Re: (Score:2)
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.
Re: (Score:2)
Step one? (Score:4, Interesting)
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? (Score:4, Interesting)
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: (Score:2)
Re: (Score:2)
Source of some sort?
Re: (Score:2)
Source of some sort?
Source [wikipedia.org]. "The original EFI specification was developed by Intel and was used as the starting point from which the UEFI version(s) were developed."
However, as you'll note; the only OS vendor participating in the UEFI trade group is Microsoft... so that should be a big hint about what UEFI is all about.
Re: (Score:2)
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.
No, I can see the value in replacing the BIOS with something newer. EFI existed at all because Intel was silly NIH.
Re:Step one? (Score:4, Informative)
Hello,
A list of OS software developers who are members of UEFI:
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.
Regards,
Aryeh Goretsky
Re: (Score:2)
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
Re: (Score:2)
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.
It is, but that does not say anything about the security mechanisms other than that the Cont
Sounds good to me! (Score:1)
So glad this is finally being taken seriously! I've often wondered why we don't see more persistent infections given how firmware is handled these days.
Re: (Score:2)
> 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.
It's more productive to write malware for the OS. It's much less he
Re: (Score:2)
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.
Why NIST? (Score:2, Offtopic)
Why is the government proposing any standards for computer BIOSes? Can you say backdoor? Can you say "abuse of the Commerce Clause" ?
Re: (Score:2, Insightful)
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.
Not sure if trolling (Score:1)
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.
Re: (Score:2)
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).
Re: (Score:1)
You know, the quote button is an excellent choice for good answers to stupid questions - then you can be modded up and he modded to oblivion, while retaining everything that was written... ;-)
Re: (Score:1)
You know, the quote button is an excellent choice for good answers to stupid questions - then you can be modded up and he modded to oblivion, while retaining everything that was written... ;-)
I don't usually quote people, but I can tell you practice what you preach ;)
.
Ferrous
Re: (Score:2)
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
Re: (Score:1)
Uh if you don't like it do your own.
Crikey.
Re: (Score:3)
Seeing this article reveals we have some very stupid people in some very high places in the IT world.
Re: (Score:3)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:1)
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.
Re: (Score:2)
No we didn't, we had bugs that went unreported and code that didn't get fixed, ever.
Re: (Score:2)
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
Re: (Score:2)
BIOS was damn tiny.
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
Re: (Score:2)
You're the one making this a false dilemma... between absolutely zero security, and nuclear bunker-level insane security procedures.
Your bank absolutely is not going to go for nuclear bunker-levels of security, yet a pretty good amount of security is needed there. Your proposal is... nothing.
Management Port anyone? (Score:2, Interesting)
Guarenteed-clean factory reset (Score:2)
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.
I
Re: (Score:1)
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.
Yes, this can be a lo
4 most important lines in whole paper (Score:1)
Read carefully, this is very important:
Comments on this publication may be submitted to:
National Institute of Standards and Technology
Attn: Computer Security Division, Information Technology Laboratory
100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930
Phrack citation (Score:3)
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.
simpler idea (Score:2)
Re: (Score:1)
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
Re: (Score:2)
Too complex. Much easier way. (Score:1)
Hardware jumper.
Jumper on. Bios is read/write.
Jumper off. (default) Bios is read only. Period. No exceptions. Not possible to write when its off. At all.
Done and done. No signing anything needed. 100% under the control of the machine owner.
Too hard? Make it a fucking button somewhere. Too insecure? Make it a key lock.
Re: (Score:1)
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... (Score:2)
Re: (Score:1)
9/11 (Score:2)
Remote BIOS updates are sometimes needed (Score:1)
Given that the BIOS/UEFI is responsible for all the following:
- 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)
in my humble opinion updating it is necessar
Why not use a password? (Score:1)
secure BIOS confusion (Score:1)