Hot answers tagged

15

Firmware configuration Writing to the BIOS is a privileged operation, only doable by the superuser. Many BIOSes attempt to prevent this, for example by locking the SPI write bit and limiting the ability of SMM to interact with the BIOS. Unfortunately, there are so many ways to modify the BIOS that many (most?) firmware vendors do not adequately lock down ...


14

One simple answer is bugs in the code that implements those security features. For example, the recently-released CVE-2015-2552 allows loading unsigned (well, test-signed, which is almost the same thing) drivers on a system that has Secure Boot enabled. There have also been a number of bugs in UEFI implementations (and other low-level code) that allowed ...


10

Matthew Garrett has some nice blog posts on UEFI Secure Boot. Concerning your question he writes: Anyone can pay $99 and get their binaries signed. So why won't malware authors just do that? For starters, you'll need to provide some form of plausible ID for Verisign to authenticate you and hand over access. So, sure, you provide some sort of fake ID. That'...


9

You are mixing up two technologies here it seems. First, there is UEFI and its Secure Boot feature. Secure Boot can be used to assure that your boot loader and your OS kernel are not tampered with. In order to do so, your boot loader and kernel need to be signed digitally and your UEFI configuration must contain the certificates/signatures needed to verify ...


8

This depends what you mean by “the overall concept of secure boot”. Pretty much all secure boot systems have several components, starting with one in ROM and ending with an operating system or even programs within that operating system. A typical boot chain is ROM → OEM bootloader → OS bootloader → OS kernel → OS startup programs. A typical secure boot ...


8

After conducting extensive research on the Bitlocker platform, I believe I can answer my own question. Key reference: Bitlocker Drive Encryption Technical Overview In our default setup (at least on MS Surface Pro 3), Bitlocker, UEFI and Secure Boot are on. There is TPM 2.0 enabled. The UEFI is not password protected, and the boot order allows USB before ...


7

There is no relation between Meltdown and UEFI attacks. Meltdown allows to read kernel memory by using a a cache side-channel used during speculative execution. It does not write anything into privileged memory, or processor microcode.


6

UEFI secure boot ensures that the UEFI firmware loads and executes only signed UEFI applications (including bootloaders) and drivers. So an attempt to modify them by introducing a malware would be detected and rejected. A vulnerability or malware (including rootkits) could possibly be also signed in the loaded code or the components loaded next. Can a ...


6

The strength of an encryption solution is directly tied to the number of possible passwords. A brute force attack simply tries all possible passwords so it will succeed more quickly if the number of distinct passwords is smaller. Case insensitivity means the attacker only has to try lower case passwords since 'EXAMPLE', 'eXamplE' and 'ExAmPlE' would all be ...


6

For reference, should anyone still be looking for an answer. Turns out it is because most BIOS' will use the scancodes of the keys it (the individual BIOS) supports for password input. The shift and caps lock are ignored in laptops I've encountered (Lenovo, HP, Dell; business line laptops).


6

what this allows an attacker to do? It allows an attacker to execute arbitrary code in System Management Mode (SMM), a highly privileged execution mode of x86 processors. This mode is transparent to the Operating System (OS) and it is more privileged than any other mode. If an attacker can execute code in SMM, it basically owns the platform/computer (more ...


6

As of right now there don't seem to be any firmware that support encrypted ESPs, but there is little need for that. Secure boot takes care of checking the signature of whatever EFI application you're about to load, so bootkits/rootkits or malicious OSes are dealt with. If you do actually have confidential data in the ESP your best bet is to put the ...


5

Real security enhancements are created if you are buying for a commercial or governmental enterprise but at a cost related to supportability. For the majority of home users who want nothing more than a Microsoft desktop and never modify their purchased system it will also provided added security. For the home user that wants to dual boot (a very small ...


5

With your unencrypted boot partition, malware could theoretically replace your unsigned kernel with its own (say, a hypervisor running your original kernel). This malware would then be undetectable by your system, while having full access to it. A signed kernel closes this hole, at least in theory: since the malware hypervisor isn't be signed, a EFI BIOS ...


4

There is always an operating system, albeit not necessarily a complex one. The BIOS is an OS in the strict sense of the term: it provides access to hardware through an hardware-independent API. The boot code for an OS (or some malware that pretends to be that boot code) uses the BIOS-provided API to read (and possibly write) bytes from the hard disk. ...


4

A BIOS/EFI password can only be considered effective because of security by obscurity. An attacker can easily override the BIOS password with only keyboard and power button access with something like this, or via physical access to the internals of the PC. What use is it, then? Well, it makes you feel secure, but it really only deters people who don't know ...


4

The attack you describe sounds more like a "diamond heist" attack of sorts (a bit elaborate for the everyday criminal). Before I address UEFI, I wanted to answer if that is feasable. No, not really. If we are talking about a server running a VM, the end user may not notice a performance issue (given enough physical resources) but more than likely the ...


4

There is an entire literature in the Blackhat and Defcon communities showing how to exploit the software that manages TPMs, retrieve secret keys from the TPM by interposing on the communication between the TPM and the CPU, and other attacks. The answer above by Kevinze and his followup comments are simply not accurate (he/she argues that such exploits are ...


4

Think about the overall concept of "security" as protecting data from loss. There are several forms of loss. There is loss to a malicious third party, but there is also the loss of access to the data, meaning the owner can't get to it anymore. This would happen if the user gets the password wrong. Presuming the encryption is cryptographically strong, ...


4

In layman's term, as requested, I think this vulnerabiliy can be simply boiled down to particular case of privilege escalation attack. It follows the same way, and pursue the same goal (and such attacks against SMM are not new: two other occurrences were presented at the Black Hat conference in 2008 and 2015). How it works: it works by injecting arbitrary ...


4

Well, that's one reason why UEFI sucks. In theory (and don't get me wrong: nobody serious in sec. ever believed this would work in RL) secure boot and signed drivers should prevent "malware" from being installed. But well: certs get stolen and exploits get found. There have already been many papers on that topic. This driver signing BS is more like a ...


4

Explanation It seems that it is not a virus or a hack on your computer. The message that is shown can be set when you lock your device from iCloud (Find My Phone). So it seems that Apple has an iCloud backdoor or something like that. Only with the password it would not be possible to login to iCloud, because of the activated two-factor authentication. So ...


4

systemd-boot has to be signed as well. The original signed gummiboot respects the 'secure' boot process and requires that the binaries it is to launch are signed as well: https://www.rodsbooks.com/efi-bootloaders/secureboot.html So it's not quite that trivial. But there are other attacks on Secure Boot that do override the protections: https://www.ghacks....


4

Technically, yes. The answer, in simple terms, is "yes" to all of your questions. The firmware (BIOS or UEFI) loads before the operating system. Typically, it looks for a boot sector on your storage devices (internal HD, CD/DVD, USB drives, etc). Then it loads the bootloader specified in the boot sector into memory and passes control to that boot loader, ...


3

Secure Boot is one security technology, it is not complete. There can be attacks before Secure Boot, Intel created Boot Guard for that. Read this Apress book for better understanding of the various Intel silicon and firmware technologies: http://firmwaresecurity.com/tag/isbn-978-1-4302-6572-6/ Also, Secure Boot varies in strength by OS, see: http://...


3

Secure Boot for PCs is inflexible and leaves you with few options if your system is somehow broken. It is also not designed to scale in an environment with multiple stakeholders - say your company wants to use Secure Boot to ensure not only a proper windows installation but also a set of certain policy-enforcing tools. Not possible out of the box. Trusted ...


3

The key here is privacy vs integrity. If your data volume (/home, /var/log and anything else with sensitive data) is encrypted then you're primarily just assuring privacy, whereas for /boot you want to make sure no malicious code is placed (integrity). Note this does not imply that it needs to be encrypted. /boot almost never requires actual encryption, ...


3

I think the theory is that each level only signs an instance of the next level if it implements signature checks correctly. In other words systemd-boot is supposed to do signature checks, and only load files that pass validation. Obviously there may be gaps between theory and practice...


Only top voted, non community-wiki answers of a minimum length are eligible