Slashdot Mirror
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."
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.
Democrat delenda est
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".
#fuckbeta #iamslashdot #dicemustdie
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.
Earn Cash and Prizes, and get free stuff!
Why is the government proposing any standards for computer BIOSes? Can you say backdoor? Can you say "abuse of the Commerce Clause" ?
I want to delete my account but Slashdot doesn't allow it.
Physical jumper to stop writing to the BIOS flash if it isn't set, and code in the rom to disallow bpoting beyond the post aside from the update if it is set. Impossible for any kind of automated attack, and servers should never get a deep update like that without being closely supervised anyway
One of many options that I think should be implemented is a jumper on the motherboard that has to be shorted in order to make any change to the BIOS (settings, updates, etc). Run a switch (even a key switch) from the jumper to the outside of the case. When you want to change the BIOS you put the switch into the short position. When done set it back.
Only draw back is it makes it difficult to make a change to the BIOS remotely. But if you are doing that frequently you can just leave the jumper shorted and find a different way to secure the BIOS. For companies with big pockets like Google or Facebook, they could put some sort of a remote relay on the jumper.
If you can't protect the OS (patching) how the hell are you going to protect the system from BIOS attacks?
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.
-------- -1 for SUCK IT!
Nobody Seems To Notice and Nobody Seems To Care - Government & Stealth Malware
In Response To Slashdot Article: Former Pentagon Analyst: China Has Backdoors To 80% of Telecoms 87
How many rootkits does the US[2] use officially or unofficially?
How much of the free but proprietary software in the US spies on you?
Which software would that be?
Visit any of the top freeware sites in the US, count the number of thousands or millions of downloads of free but proprietary software, much of it works, again on a proprietary Operating System, with files stored or in transit.
How many free but proprietary programs have you downloaded and scanned entire hard drives, flash drives, and other media? Do you realize you are giving these types of proprietary programs complete access to all of your computer's files on the basis of faith alone?
If you are an atheist, the comparison is that you believe in code you cannot see to detect and contain malware on the basis of faith! So you do believe in something invisible to you, don't you?
I'm now going to touch on a subject most anti-malware, commercial or free, developers will DELETE on most of their forums or mailing lists:
APT malware infecting and remaining in BIOS, on PCI and AGP devices, in firmware, your router (many routers are forced to place backdoors in their firmware for their government) your NIC, and many other devices.
Where are the commercial or free anti-malware organizations and individual's products which hash and compare in the cloud and scan for malware for these vectors? If you post on mailing lists or forums of most anti-malware organizations about this threat, one of the following actions will apply: your post will be deleted and/or moved to a hard to find or 'deleted/junk posts' forum section, someone or a team of individuals will mock you in various forms 'tin foil hat', 'conspiracy nut', and my favorite, 'where is the proof of these infections?' One only needs to search Google for these threats and they will open your malware world view to a much larger arena of malware on devices not scanned/supported by the scanners from these freeware sites. This point assumed you're using the proprietary Microsoft Windows OS. Now, let's move on to Linux.
The rootkit scanners for Linux are few and poor. If you're lucky, you'll know how to use chkrootkit (but you can use strings and other tools for analysis) and show the strings of binaries on your installation, but the results are dependent on your capability of deciphering the output and performing further analysis with various tools or in an environment such as Remnux Linux. None of these free scanners scan the earlier mentioned areas of your PC, either! Nor do they detect many of the hundreds of trojans and rootkits easily available on popular websites and the dark/deep web.
Compromised defenders of Linux will look down their nose at you (unless they are into reverse engineering malware/bad binaries, Google for this and Linux and begin a valuable education!) and respond with a similar tone, if they don't call you a noob or point to verifying/downloading packages in a signed repo/original/secure source or checking hashes, they will jump to conspiracy type labels, ignore you, lock and/or shuffle the thread, or otherwise lead you astray from learning how to examine bad binaries. The world of Linux is funny in this way, and I've been a part of it for many years. The majority of Linux users, like the Windows users, will go out of their way to lead you and say anything other than pointing you to information readily available on detailed binary file analysis.
Don't let them get you down, the information is plenty and out there, some from some well known publishers of Linux/Unix books. Search, learn, and share the information on detecting and picking through bad binaries. But this still will not touch the void of the APT malware described above which will survive any wipe of r/w media. I'm convinced, on both *nix and Windows, these pieces of APT malware
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 ;-)
I'm a dreamer, the world is my playpen. But hey, I'm a serious person, I can't dream all the time.
Retarded hardware that blindly lets you flash anything you want to the BIOS is the problem.
This is not a matter of software security, it's a matter of low level hardware security. This isn't something we're going to fix with "security certificates" and bullshit like that (though I'm sure that's what everyone will resort to- signed BIOS updates, thus bringing the life of your average hardware admin one step closer to absolute hell). This is something that you can easily fix by requiring physical interaction with the hardware prior to launching an update.
At the minimum, there should be a 1-bit DIP switch on the logic board of server spec gear that lets you select between the following:
1) Updates can be applied directly from the OS, and are made active immediately after reboot
2) Updates can be applied directly from the OS, but are buffered in a secondary flash chip and only dumped into the primary firmware chip if the system is halted and powered up by holding down the power button for more then 10 seconds
If you've got the DIP switch set to #2, then anything can write to the firmware all it wants. It doesn't matter, because those writes are redirected to a secondary chip which are never ever executed by the hardware. It's just a staging area for updates, until someone physically starts the update procedure from the front of the machine.
Of course the usual solution to this sort of thing is to just throw obfuscated crypto at the problem, so I doubt anyone will bother implementing anything like this. And in the end, whatever stupid solution they do come up with will likely be hacked by the underground in a matter of months, leaving everyone right back where they were before- with vulnerable systems that can be updated through software, except now the process for legitimately updating things is that much more complex.
-AC
Seriously.
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.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
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
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
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.
Back in my old Amiga 1000 days, the firmware came first, and it was the 'kickstart' disk. After it was loaded (in firmware ram), it would be soft-wired off and the small bit of firmware that computer had wouldn't allow writes to those chips anymore. It might sound like 'the old days', but I wouldn't mind flipping a switch when updating bios rom, and after its written, it stays there as read only till you decide to update it again. It sounds like 'old timer days', but it sure keeps firmware malware out. Oh, and kill UEFI with fire!
It never gets much of anything done. Lots of talk, talk, talk, spread over years.
how about this: make bios read-only, and include a momentary push button that needs to be pushed in order to make the bios writable for a limited amount of time. Is this too simple?
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.
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.
I remember upgrading the BIOS on my AT&T PC 6300 back about ... jeez, it was 22 years ago. The upgrade consisted of removing one socketed chip and replacing it with another. Quite a secure BIOS since you cannot write to ROM.
Thinking about modern equivalents, how about storing the BIOS on a read only memory device again. SIM chips come to mind. Maybe create some sort of new device that would be equally cheap to manufacture. Sure, you would lose the ability to download a new BIOS and perform the upgrade via software, but hey, you can't beat the security of it. If the BIOS chip could be made a write-once device, then you could still have the convenience of downloading, just with the added step of burning.
Some people might complain about physical replacement being impractical in a large datacenter, but having worked in a datacenter with more than 30,000 servers I can attest that this would not be a likely issue: we never did a single BIOS update in the 3 years I worked there.
We can say that the BIZOS is protected.. read th articles submitted by hackers The Hackers Idea
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).
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.
Weaselmancer
rediculous.
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).
hopefully its a little more thought out than their report on 9/11
It is not that difficult to design the BIOS to need a H/W switch to be closed before update.
Equally, it is not that difficult to design an Operating System to require a H/W switch to be closed before any update of critical components takes place. I have done that myself while working in the dirty area of a virus lab. That gives you strong security against any attempts to compromise your system.
A lot of the current security issues which exist could easily be solved in this way - if only S/W designers would consider using a H/W solution...
.. all part of the Glorious War On General Computing Machines. Too dangerous for general consumption.
Has everyone forgotten the concept of ROM? (That's Read Only Memory for you young'ins).
Considering the average lifespan of a PC these days is 2 years or less, would it hurt to make the boot code read-only? It's not like the average user is going to shed tears 10 years from now that they can't boot Windoze 12 on the system they buy today!
What's wrong with simply having a ROM bios, an EEPROM copy, and a motherboard switch?
Switch position A: Boot from EEPROM and allow writes to it.
Switch position B: Boot from EEPROM but do not allow writes to it.
The boot sequence boots into ROM, checks to see if a key is held down (or some other hardware check), and if not continues from the EEPROM. If the trigger occurs, it boots into a mini-menu in ROM, giving the options to overwrite the EEPROM with a copy of the ROM contents or boot from the ROM image directly and bypass the EEPROM.
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 necessary from time to time, especially on OEM systems, to suggest a BIOS update as part of troubleshooting or issue resolution. It's nice to be able to do this remotely in some capacity rather than have to travel 450 miles to flip a hardware switch.
This being said, can't they put the BIOS on an SD card now? Is a LPC (or whatever) to SD converter/translator whatever really that hard/expensive to build?
This would allow hardware manufacturers to provide a UEFI compliant firmware for Windows, etc., let me completely replace it if it gets borked or infected, and let hackers have their way with it as well.
Have jumper(s) on the motherboard to be really safe. This is what I would want and will allow data centers to handle it remotely as well.
4 positions for the jumper set:
1 - Impossible to flash under any circumstances. This is where I would leave my computers set.
2 - basically just a signed update, where "signed" can mean "locally signed" - a locally set key in unreadable hardware is set at hardware install time. Send this key to the hardware while running. Wrong key sent? Options include "lock up", "ignore", "bios log", etc. Correct key sent? Next reboot is allowed to write to flash. Reboot. Write flash. Reboot. To get around this, you have to install a persistant threat. If you have that, you hardly need to modify the BIOS, except in case you get formatted.
3 - Possible to flash, but only if the "Bios write protect" in the BIOS is turned off.
4 - Possible to flash at any time.
Sorry, let me clarify.
Flashing should be possible even with an evil BIOS already installed. Source of flash can be:
- an application program running normally (e.g. normal OS or boot CD) (not successful under an evil BIOS)
- a properly formatted storage detected at POST before running main BIOS (e.g. USB thumb drive which itself can be write protected cryptographically or with a jumper) (multiple validly signatured drives cause a lock up)
- a write protected (by yet another jumper set) internal backup of the BIOS ROM. Effectively a built in version of the above USB drive option......
These give data centers some options for remote repair, even with an evil BIOS already installed, which should never happen.
They also allow familiar simple updates for normal users.
They also give you certainty of a clean install, unless all of your IT staff's machines and drives are also infected with an incredibly complex evil BIOS that understands and works perfectly with all operating systems that you might boot (CD, HD, USB, Floppy, Network, add in card, Linux, Windows, DOS, Mac, all versions, including future versions, including timing attacks against the Blue Pill, etc. Although it may be possible for this evil BIOS to run correctly, it is impossible for it to hide from e.g. an unknown timing attack launched from a CD. Either it is detected, or the test is noticably falsified.
oh cool. locked down bioses .. now available to malware creators! ...
prolly locked all your cars into the key oops. lockout
"NIST published the draft guidelines [PDF]": too bad it's not in
the guidelines never to open or use pdfs
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.
Weaselmancer
rediculous.
Many NIST recommendation series are actually authored, wholly or in part, by industry professionals. Not in this particular case, but this is also a new, short publication that is narrow in scope.
That Andrew Regenscheid has his name on the document doesn't mean he wasn't involved with others when coming up with the recommendations. He distilled down a lot of recent papers (from all sorts of venues) and prioritized the issues as they stand. His references for it are a goldmine of additional interesting stuff.
Besides, this guy is a total nerd, he spent his PhD a few years ago working on hacking into voting systems. His judgement jives with what I'd like to see from the industry.
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) to the system. Then the issues are losing the password - which could then employ a jumper to reset - and the encryption level of the BIOS password, which would be interesting after few years.
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 available, cheks the crypto signatures to ensure the provenance of the bew image and flashes it if they're OK. Unfortunately, there's no single implementation and AFAIK no common signing scheme---this stuff is proprietary and board-specific. NIST spec might make it saner, by requiring conforming implementations. Does it prevent firmware exploits? Not quite, because there are option BIOSes that reside on PCI cards and such, and AFAIK they are not covered by the BIOS spec. Is it better than a jumper solution proposed here? I believe so: I don't want to go back to the old days of having to crack open the box and boot DOS from floppies; they may work for a single machine or two but are not scalable for realistic largish deployments.