Forgot your password?
typodupeerror
Security IT Hardware

NIST Publishes Draft Guidelines For Server BIOS Protection 141

Posted by timothy
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."
This discussion has been archived. No new comments can be posted.

NIST Publishes Draft Guidelines For Server BIOS Protection

Comments Filter:
  • Stupid and wrong (Score:5, Insightful)

    by jmorris42 (1458) * <jmorris&beau,org> on Friday August 24, 2012 @08:55PM (#41118651)

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

      • Re: (Score:3, Interesting)

        by VortexCortex (1117377)
        ... And how is this different from secure boot?
        • by SuricouRaven (1897204) on Saturday August 25, 2012 @04:15AM (#41120947)
          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.
      • Easier (Score:5, Insightful)

        by Weaselmancer (533834) on Saturday August 25, 2012 @02:03AM (#41120455)

        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.

        • by drsmithy (35869)

          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.

          • It's a BIOS. If it was working to get you to boot to begin with and your hardware functions then you don't really ned to change it, now, do you?
        • by mysidia (191772)

          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

    • by dgatwood (11270)

      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.

      • by Lehk228 (705449)
        instead, allow adding signing keys in the bios menu, so if you want to load your own bios you generate a key, type it in at bios, then install bios.
        • by dgatwood (11270)

          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.

          • by Lehk228 (705449)
            it treats all loading as a single class, image signed from array keys[]

            it would also allow you to import your key once and sign test bioses as you work without rebooting to load
      • by EdIII (1114411)

        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)

          by dgatwood (11270) on Friday August 24, 2012 @10:02PM (#41119215) Journal

          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.

          • by evilviper (135110)

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

        • by jmorris42 (1458) *

          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

        • by Joce640k (829181)

          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.

      • by Dunbal (464142) *

        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.

        • by sumdumass (711423)

          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

        • by hairyfeet (841228)
          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.
      • by mysidia (191772)

        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 ;-)

    • by msauve (701917) on Friday August 24, 2012 @09:41PM (#41119059)

      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.

      • by jmorris42 (1458) *

        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.

        • by msauve (701917)
          If you change your hardware, you close a jumper (or a switch during boot). If you can't handle that, you deserve what you get.

          BTW, if the lights are out, you're not gonna be managing anything.
    • Re: (Score:3, Insightful)

      by fustakrakich (1673220)

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

    • by Dunbal (464142) *
      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.
    • by symbolset (646467) *
      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.
    • Re:Stupid and wrong (Score:4, Interesting)

      by crispytwo (1144275) on Saturday August 25, 2012 @12:09AM (#41120009)

      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.

    • by mrmeval (662166)

      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.

    • by FlyingGuy (989135)

      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!
  • Step one? (Score:4, Interesting)

    by girlintraining (1395911) on Friday August 24, 2012 @09:03PM (#41118735)

    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)

      by Microlith (54737) on Friday August 24, 2012 @09:34PM (#41118991)

      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.

      • by Altanar (56809)
        UEFI security architecture was designed by Intel, not Microsoft. Please, enough with the conspiracy theories.
        • by Microlith (54737)

          Source of some sort?

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

            • by Microlith (54737)

              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.

      • Re:Step one? (Score:4, Informative)

        by Aryeh Goretsky (129230) on Saturday August 25, 2012 @01:13AM (#41120243) Homepage

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

        • 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
        • by Microlith (54737)

          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

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

    • by bmo (77928)

      > 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

      • by Grave (8234)

        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)

    by Gothmolly (148874)

    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)

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

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

      • by Esteanil (710082)

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

        • 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

      • by drsmithy (35869)

        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

    • Uh if you don't like it do your own.

      Crikey.

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

  • 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

  • by cachimaster (127194) on Friday August 24, 2012 @09:54PM (#41119171)

    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.

  • 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?
  • by Anonymous Coward

    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.

    • by sumdumass (711423)

      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).
  • by crutchy (1949900)
    hopefully its a little more thought out than their report on 9/11
  • 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

  • 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

3500 Calories = 1 Food Pound

Working...