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


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


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

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

if the boot and hardware is what you need access to and assuming you could get physical access to the computer with money backing you...(and apologize my noobness) then here is my thought process. Make the computer think it's a piece of hardware. A typical ram for example is 2gb or more, could you write the basic lowest level code on to a ram chip, as hard ...


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

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

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

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

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


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

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

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

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



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