Hot answers tagged

8

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


8

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


6

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


5

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


4

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


4

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


4

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


4

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


3

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


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


2

This is using Trusted Platform Module to defeat the Evil Maid Attack. In short this is to insure that your bootloader hasn't been tampered with, which could undermine an encrypted file system.


2

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


2

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


2

The goal of the creator of Rakshasa was to avoid having any malware, which could potentially be flagged by an antivirus, to be stored anywhere in the machine (whether it is on the hard-disk, in a firmware, or anywhere else). To achieve this, Jonathan Brossard (to call the creator by his name) implemented Rakshasa with the following principle: Rakshasa is ...


1

From what I can tell in this guide, and I preface this that I'm not an expert in TPMs, taking ownership of a TPM does not affect the Secure Boot options for an operating system. Taking ownership of a TPM means resetting the keys within the TPM with a new ownership password. In Microsoft Windows at least this means that the TPM is consulted for any ...


1

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


1

You can persist by compromising the UEFI firmware, and doing so is extremely easy (for a state-sponsored attacker). On most consumer-grade machines there are no signature checks on the firmware images and you can thus install malicious firmware, and since Secure boot is enforced by that firmware, you can thus bypass Secure boot. Personally I only know of ...


1

Focusing on the simpler of the two, the BIOS boot, the answer is no. To quote this IBM reference IBM link Historical issues limit the size of a user-supplied bootloader program to slightly less than 512 bytes. Since this isn't enough space to implement all the possible device drivers that might be required to access different displays and storage ...


1

Software cannot protect against physical attacks. Security requires a layered approach. Most cases have the ability to put on a physical lock. More secure systems cases can also hide the cable connections and prevent changing keyboards, or other peripheral connections. The BIOS/boot password is only one part of a greater security plan for a system. It's ...


1

Yes, you have correctly concluded what Rakshasa is doing, except that the hard drive itself is never infected, nor does it have any evidence of the compromise. The compromise lives exclusively as non-malicious code in BIOS, which loads malicious code from a network server that lives exclusively in RAM. That's a long video for us to watch and review, so I ...


1

Already before UEFI, infected firmware could do what it wanted, including spying on you. What changed, is that UEFI now has a network stack, making writing payloads much easier. Also, if you have attackers with physical access, you have already lost.


1

If you're asking if UEFI add additional attack vectors against TrueCrypt vs. a non-UEFI BIOS, the answer is probably no. Running TrueCrypt on a UEFI-enabled computer with the UEFI code signing turned off is no less secure that a computer without UEFI.


1

First, there's a terminology issue when talking about this stuff. Strictly, 'BIOS' and 'UEFI' are different programming interfaces for the firmware present on PC motherboards. However, in a PC context, 'BIOS' is often used to refer to the firmware irrespective of its API -- that is, "UEFI BIOSes" should strictly read "UEFI firmwares". (Just to be clear: ...


1

I recommend locking down GRUB and taking away access to the GRUB shell. GRUB manual: Authentication and authorisation (Archived here.) By default, the boot loader interface is accessible to anyone with physical access to the console: anyone can select and edit any menu entry, and anyone can get direct access to a GRUB shell prompt. For most systems, ...


1

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


1

Physical access is always a very risky thing. While I don't now of any security flaws right now that will give you immediate access there are a lot of other things that you can do, eg. using a USB keylogger to intercept the user's password when he uses the machine the next time. There have been attacks using PCI cards utilizing direct memory access ...


1

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



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