Tag Info

Hot answers tagged

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

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


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


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


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

BIOS and UEFI are both different system firmware solutions. BIOS was designed back when MS-DOS was main OS, so there was no concept of security built-in. EFI 1.x also basically had no security. UEFI 2.x had Secure Boot, signed code, uses TPM or TrustZone, and has other security features. But, both solutions can have vulnerabilities. UEFI is more complex than ...


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

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

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