Slashdot Mirror

← Back to Stories (view on slashdot.org)

Secure Boot Coming To SuSE Linux Servers

Posted by Unknown on from the hold-the-key dept.

darthcamaro writes "UEFI Secure Boot is a problem that only desktop users need to worry about right? Well kinda/sorta/maybe not. SeSE today is releasing SUSE Linux Enterprise 11 SP3 which will include for the first time — support for UEFI Secure Boot. Apparently SUSE sees market demand for Secure Boot on servers too. Quoting Matthias Eckermann, Senior Product Manager at SUSE: 'Our market analysis shows that UEFI Secure Boot is a UEFI extension that does not only cover desktops, but might very well also be deployed and even required on server systems going forward.'"

21 of 135 comments (clear)

  1. SecureBoot is incomplete by Junta · · Score: 2, Insightful

    SecureBoot is an incomplete strategy. It only allows for attestation of software vendor provided content. It does nothing for:
    -custom executables
    -configuration data and so on

    Servers in particular need to be looking for a mechanism for the customer to measure and secure their own boot stuff. Constructing a good enough root kit out of valid signed secureboot content is going to be feasible unless you render the system overly limited.

    It's theoretically possible to completely break SecureBoot but still advertise SecureBoot as intact. System will merrily load up a signed hypervisor and that signed hypervisor may in turn do whatever the hell it wants including boot the 'normal' OS as a guest with firmware that will tell the OS whatever the attacker feels like. If secureboot is disabled, you can have a rootkit that advertises it as enabled without issue.

    Ultimately, it's a mitigation strategy with huge gaping holes that people presume are no longer a problem because they don't take the time to understand the nuances of such a strategy. I'm not accusing the designers of this misconception, but the general population's understanding of the benefits of SecureBoot has been very misguided (I have heard some claim that PXE being wide open is ok because secureboot would protect it, in one example of how badly misunderstood Secureboot is)

    --
    XML is like violence. If it doesn't solve the problem, use more.
    1. Re:SecureBoot is incomplete by bws111 · · Score: 3, Informative

      Secure boot only ensures that you know that what you are booting is signed by someone you trust. It does not provide 'attestation'. If you want attestation, use TPM, possibly combined with secure boot. TPM is not subject to being tricked by hypervisors.

    2. Re:SecureBoot is incomplete by Junta · · Score: 2, Insightful

      My issue is that I'm having a hard time seeing what SecureBoot adds that cannot be acheived in a better fashion (e.g. more comprehensive use of a TPM). SecureBoot doesn't ensure that your are booting is signed by someone you trust. It assures that one efi executable was signed by someone (who you may or may not 'trust'), but most would conceive of 'what you are booting' to be the universe of everything that happens prior to the system being usable, boot loader, kernel, configuration, third party executables, etc etc, which SecureBoot does nothing to really facilitate meaningful measurement. SecureBoot is ill equipped to facilitate most of that.

      It complicates use of non-microsoft OSes and I think the value of the mitigation provided is greatly overestimated due to a name that suggests more assurance than one should reasonably assume.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    3. Re:SecureBoot is incomplete by Nerdfest · · Score: 3, Insightful

      what you are booting is signed by someone you trust

      Or Microsoft.

    4. Re:SecureBoot is incomplete by KiloByte · · Score: 5, Insightful

      It complicates use of non-microsoft OSes

      And that's the whole reason SecureBoot is getting pushed onto manufacturers.

      --
      The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
    5. Re:SecureBoot is incomplete by John.Banister · · Score: 2

      If some well meaning but less than perfectly well informed member of a management team decides that there should be a policy requiring secure boot, then it might be nice for the product that it's able to comply. Certainly it would be better to properly educate management, but dealing with software might be easier.

    6. Re:SecureBoot is incomplete by benjymouse · · Score: 2

      My issue is that I'm having a hard time seeing what SecureBoot adds that cannot be acheived in a better fashion (e.g. more comprehensive use of a TPM). SecureBoot doesn't ensure that your are booting is signed by someone you trust.

      Yes it does. Especially on Windows, the OS is booted from signed cabinet files, i.e. the Microsoft bootloader will refuse to boot Windows unless the cabinet file (which include executables, libraries, core config files) is signed correctly.

      It assures that one efi executable was signed by someone (who you may or may not 'trust'), but most would conceive of 'what you are booting' to be the universe of everything that happens prior to the system being usable, boot loader, kernel, configuration, third party executables, etc etc,

      And if the bootloader and OS in turn takes on their part of that responsibility, you *do* have a trusted chain. Of course, it requires that the OS is booted from signed files that include executables as well as config. If the OS is set to require signatures (or hash matches) of 3rd party executables it can ensure integrity for itself. The chain merely ensures that each step can be confident that at the time where each step receives control of the system, integrity is ensured. Each step must ensure it's own integrity and only pass control to the next step if integrity can be validated.

      --
      Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
  2. Re:SecureBoot has no place as implemented by vux984 · · Score: 2

    Until it is something that allows for end-user control of the process instead of Microsoft,

    In that the end user can remove the microsoft key? Yes, it can do that.

    In that the end user can install their own key, sign their own software, and boot from that? Yes, it can do that too.

    What exactly is your gripe?

  3. Re:SecureBoot has no place as implemented by 0123456 · · Score: 3, Insightful

    Secure boot does nothing to prevent the end user from being in control, and it does not require anything from Microsoft. If your vendor does not allow you to install your own keys, get a better vendor.

    So first you say that Windows Boot doesn't prevent the end user from being in control, then you admit that it puts the vendor in control. Vendor lock-in is the whole point of Windows Boot.

  4. Secure Boot ISN'T! by kawabago · · Score: 2, Insightful

    Secure Boot isn't secure nor is it a security feature. It's sole purpose is to keep Linux off of x86 computers. It's already easy to get around 'Secure Boot so I think it's broken as a concept. Security has to constantly evolve to meet evolving problems. Hardware can't do that.

    1. Re:Secure Boot ISN'T! by recoiledsnake · · Score: 4, Informative

      Secure Boot isn't secure nor is it a security feature. It's sole purpose is to keep Linux off of x86 computers. It's already easy to get around 'Secure Boot so I think it's broken as a concept. Security has to constantly evolve to meet evolving problems. Hardware can't do that.

      +3 interesting? What's wrong with Slashdot that posts with the most misinformation are modded up? And then other people take these modded up posts as gospel and keep repeating the FUD.

      Can you tell us how it's easy to get around Secure Boot?

      Secure Boot isn't secure nor is it a security feature. It's sole purpose is to keep Linux off of x86 computers

      Here's a couple of viruses that Secure Boot prevents.

      http://www.chmag.in/article/sep2011/rootkits-are-back-boot-infection

      http://www.theregister.co.uk/2010/11/16/tdl_rootkit_does_64_bit_windows/

      http://www.computerworld.com/s/article/9217953/Rootkit_infection_requires_Windows_reinstall_says_Microsoft

      I recommend reading atleast the first link.

      Here's one juicy bit:

      TDL4 is the most recent high tech and widely spread member of the TDSS family rootkit, targeting x64 operating systems too such as Windows Vista and Windows 7. One of the most striking features of TDL4 is that it is able to load its kernel-mode driver on systems with an enforced kernel-mode code signing policy (64-bit versions of Microsoft Windows Vista and 7) and perform kernel-mode hooks with kernel-mode patch protection policy enabled.

      When the driver is loaded into kernel-mode address space it overwrites the MBR (Master Boot Record) of the disk by sending SRB (SCSI Request Block) packets directly to the miniport device object, then it initializes its hidden file system. The bootkit’s modules are written into the hidden file system from the dropper.

      The TDL4 bootkit controls two areas of the hard drive one is the MBR and other is the hidden file system created at the time of malware deployment. When any application reads the MBR, the bootkit changes data and returns the contents of the clean MBR i.e. prior to the infection, and also it takes care of Infected MBR by protecting it from overwriting.

      The hidden file system with the malicious components also gets protected by the bootkit. So if any application is making an attempt to read sectors of the hard disk where the hidden file system is stored, It will return zeroed buffer instead of the original data.

      The bootkit contains code that performs additional checks to prevent the malware from the cleanup. At every start of the system TDL4 bootkit driver gets loaded and initialized properly by performing tasks as follows: Reads the contents of the boot sector, compares it with the infected image stored in hidden file system, if it finds any difference between these two images it rewrites the infected image to the boot sector. Sets the DriverObject field of the miniport device object to point to the bootkit’s driver object and also hooks the DriverStartIo field of the miniport’s driver object. If kernel debugging is enabled then this TDL4 does not install any of it’s components.

      TDL4 Rootkit hooks the ATAPI driver i.e. standard windows miniport drivers like atapi.sys. It keeps Device Object at lowest in the device stack, which makes a lot harder to dump TDL4 files.

      All these striking features have made TDL4 most notorious Windows rootkit and it is also very important to mention that the key to its success is the boot sector infection.

      Another bit:

      The original MBR and driver component are stored in encrypted form using the same encryption. Driver component hooks ATAPI's DriverStartIo routine where

      --
      This space for rent.
    2. Re:Secure Boot ISN'T! by csumpi · · Score: 2

      What's wrong with Slashdot that posts with the most misinformation are modded up? And then other people take these modded up posts as gospel and keep repeating the FUD.

      Welcome, young Skywalker, I have been expecting you.

    3. Re:Secure Boot ISN'T! by benjymouse · · Score: 2

      The concept is solid enough, but the implementation is flawed. As a consequence of mandating that the factory burns in the signing key, it pretty much forces MS to sign competitor payload or be seen as anti-competitive.

      This is where you fail. Microsoft does not sign competitor payload using a UEFI burned key. What Microsoft offers is that they will sign 2nd level boot loaders so that the Microsoft bootloader will accept to chain-load it. You cannot directly boot such a Microsoft signed bootloader or OS directly from UEFI.

      Why is this significant? Because
      1. It allows Microsofts bootload'er to make it *obvious* that a foreign OS is being booted. You cannot get around this because it is Microsofts code that gets the control before your code.
      2. It allows Microsoft to *revoke* that specific signing if it turns out that it is being used for nefarious purposes.

      This means your Microsoft install implicitly trusts software from Red Hat, Canonincal, VMware, Attachmate, and really anyone else who may enter the ring. There is no way that MS is providing adequate auditing to assure those paths aren't vulnerable and it shouldn't have to. Because it must be installed into firmware before an OS touches it, there is also *no* reasonable opportunity to provide any assurance of customer provided content like configuration.

      Again, fail. The key validating software from Linux vendors (when they use Microsofts boot loader shim) is NOT in the firmware. It is part of Microsofts bootload'er (which is in turn validated by UEFI). If a 2nd level bootloader shim is being used for nefarious purposes, Microsoft can *revoke* that specific bootloader/OS. Thus, it is in the self-interest of distros to secure their part of the path.

      As to that root kit you mentioned, MS could have protected itself from that without SecureBoot or any boot signing. MS could have made MBR writes from within their OS forbidden without an extreme warning. No OS bothers to do that, but it would have been actually a pretty defensible move on their part to mitigate root kits.

      Defense in depth. Secure boot cannot prevent vulnerabilities, nor is it designed to do that. It is designed to prevent malicious code from gaining persistent foothold on a system, i.e. a guaranteed validated system after each boot. A kernel space exploit in any OS can lead to the attacker can write to otherwise off-limit areas. I trust that you are not advocating hard-shell-soft-core security.

      The problem is that Secure Boot gives MS control of the entire ecosystem but in doing so missed an opportunity to provide something that *would* have worked better and allowed MS to avoid vouching for anything but their own software at boot time.

      Linux Foundation could have stepped up as signing authority. Or Red Hat - they have the amp to do so. As it happens, both those organizations actively declined. There is *nothing* in UEFI that precludes anyone else from having their keys directly in the firmware. They would need to work with multiple vendors, however. That's why it would have been a job for LF or Red Hat.

      Incidentally, Microsoft Hyper-V 3 (launches with Server 2012R2) support secure boot and has UEFI firmware. And yes, you can register your own keys. If VMWare/Xen/KVM were to offer the same this will soon become a silly discussion as this would pertain only to the lowest level hypervisor layer on a host. I could certainly fathom VMWare working with server vendors to have *their* key pre-registered.

      --
      Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
    4. Re:Secure Boot ISN'T! by Anonymous Coward · · Score: 2, Interesting

      The problem is that a LOT of people on Slashdot basically live on Slashdot. It's their primary tech site, and hence they surround themselves with like-minded people who believe Linux will crush Microsoft on the desktop any day now, that Microsoft are dying, that no-one could like Windows/Microsoft by choice, that most people support Snowdon and his actions, and so on. It's one great bit echo chamber as opinions get reinforced by other like-minded posters, which strengthens their opinions and moves them into undeniable fact.
      A place like ArsTechnica shows a vastly different situation, with far more people showing more varied opinions, such as liking Windows 8, preferring Microsoft technologies like C# to C++/Java, preferring Surface to iPad, and in this case, seeing the benefits of Secure Boot. Why do they do this? Because they aren't fucking brainwashed to believe what Slashdot tells them to believe.

      I can see what you're saying, but the Slasdot community is largely made up of REAL nerds - old school!
      We remember rebooting Windows 3.11 for workgroups more than 20 times a day due to system crashes when trying to do real work.
      We remember the amazement of playing sasteroid with no lag while installing slackware from floppies.
      We remember the shit that Microsoft has pulled over the decades to crush superior products, especially ones like Linux and Java that threatened it's vendor lock-in stranglehold.
      Fuck me I could go on and on...
      Anyway, the point is, we weren't brainwashed...we lived through it and we remember.

  5. Re:SecureBoot has no place as implemented by Rockoon · · Score: 3, Insightful

    Unless the hardware manufacturer won't let you.

    Isn't this argument essentially fear, doubt, and uncertainty?

    --
    "His name was James Damore."
  6. I don't think it was about Linux on x86... by Junta · · Score: 2

    I think it more likely it was about Android on ARM. MS didn't want to end up selling some fantastic hardware device and getting all the 'momentum' wiped out by Android loads so people could run with a platform with some semblance of an ecosystem going (though I've not seen an RT device I'd find interesting regardless of software). x86 got to come along for the ride so that MS would be doing things in a nicely consistent fashion with more credibility on the matter of rootkit mitigation. It does mitigate rootkits, rootkits now have to be more complicated than they had to be previously. The components available to construct a rootkit may be unable to avoid tipping off a careful user that something is weird during the boot process (e.g. if SuSE's logo appears during a pure Windows boot, that would be a sign that something is afoot). Of course, the typical user that doesn't notice or has been trained to shrug off 'weird stuff' during the boot process (e.g. a lot of security suites end up branding boot process as they do their own FDE thing, so seeing a lizard on screen may make most people assume it's security software).

    --
    XML is like violence. If it doesn't solve the problem, use more.
  7. some responsibility is on owner by Chirs · · Score: 3, Interesting

    As I understand it, the signed redhat bootloader will only boot redhat kernels (which in turn will extend the chain of trust upwards). The generic linux bootloader will boot anything, but will require proof from a person that they acknowledge that it is booting that thing (in order to prevent a "blue pill" type attack).

    In this instance, the person with physical control over the system could load an arbitrary kernel, but it is difficult for an attacker to install a hidden rootkit.

  8. yes, based on previous experience by Chirs · · Score: 2

    WinRT ARM devices already lock out the user from disabling secure boot or modifying the keys.

  9. Re:Secure Boot solves a nonissue by wbr1 · · Score: 4, Funny

    There's no place for rational discourse here, whoever posts the most anti-MS screed gets voted up regardless of facts.

    I am going to test your theory.

    MS Sucks balls, They have since 1978. In fact Gates dropped out because everyone's balls at Harvard were chafed from staying damp with Gates saliva.

    Balmer is CEO now, because he even has a ball in his name.

    If you look deep in the resources in shell32.dll, there is a string that reads, "insert balls into CD-ROM for a 'Gates job'."

    --
    Silence is a state of mime.
  10. Re:SecureBoot has no place as implemented by Microlith · · Score: 2

    In that the end user can install their own key, sign their own software, and boot from that?

    Maybe. If the device you're booting from has its option rom signed by Microsoft and you remove their key, can you boot from the device anymore? My educated guess is no (you can't truly get away from Microsoft) and you are forced to trust Microsoft even if you don't want to because hardware OEMs can only ever assume one key is available due to the (poor) architecture.

  11. Ridiculous. by VortexCortex · · Score: 2

    I understand the software writers don't want to marginalize themselves in case servers adopt UEFI. However, there are zero security benefits of UEFI, versus booting part of your OS right from the BIOS/Firmware. It's up to the OS's bootloader to kick of an encryption chain after UEFI loads. So, put the damn bootloader in the firmware with Coreboot.

    The way my setup works is that Coreboot has a bootstrap loader for my OS in firmware. The BIOS requrires a password to access it, and enable the flashing of firmware. Type password, "Enable Firmware Flash On Next Boot" option. No screwy hex code you're bound to mess up several times. My boot protocol uses public key crptography so that the custom multi-boot loader can handle any number of OS updates. The 2nd stage OS loader changes, it can include the signature of via key that's paired with the OS's 1st stage firmware boot loader. DONE. All we need is a standardized way for BIOS to flash a small part of the OS loader at OS install, and then any OS can be just as secure as secure boot, without ANY hierarchy of control -- The OS devs can own all the keys they use to secure and load their own OS. It's not like the chips don't have the memory now -- Shit, on new desktop systems the firmware has gaudy graphics, animations, and sounds -- The damn motherboard runs a stipped down Linux or BSD to prestent you the BIOS config options!

    So, think about this. Coreboot + Key/Signing you already have to have in the OS loader is just as secure as UEFI, except there's no grand central Microsoft authority who says what OS can and can not install on the hardware, or to pressure hardware makers into bowing to the demands of the Windows requirements. If there is a bug in the BIOS or hardware that lets it rewrite firmware from software without permission, then it exploits UEFI or Coreboot equally -- How do you think UEFI is implemented -- IN FIRMWARE? Hell, I have the option with Coreboot to use UEFI boot if I want. However, I can also remove that shite, or even have the firmware setup legacy BIOS interrupt tables for booting old OS's like MSDOS, DR DOS, etc. Currently, I have my system config in my Coreboot, so it doesn't search for shit, just loads my OS and runs instantly at power up.
    Coreboot w/ OS + SSD = Milliseconds to boot; Beat that, Security Theater Boot.

    They should rename that shite, Microsoft Controlled Boot, because it is, for all intents and purposes. Stop and think. How can a sysop like me figure out a more flexible system that's just as secure as SecureBoot, more easy to use and maintain, and even adds security to tons of legacy x86 hardware -- Yet all those well paid folks who's only job was to engineer a secure boot standard "UEFI", came up with some restrictive shit that in effect gives Microsoft more control of the hardware and software arena? NO. ACTUALLY THINK. SEE?