Hot answers tagged

92

The main thing that is happening is that the bug is being seriously overhyped. Exploiting this vulnerability requires physical access to the computer during startup, and if you've got physical access, there are about a zillion ways you can bypass security. The bug is about bypassing Grub2's internal password protection. Most users don't password-protect ...


36

Your question is the first I've heard of this. Based on the articles you presented though you're probably plenty safe for 2 reasons: A) The first article you linked says that the major distros have already patched this. If you keep up to date like you said, it should be fine. If not, the same article says the researchers who found the bug have released a ...


10

Forgive me, but the #1 solution for a real-time dependent system is to not let undesignated junk run on it. Users shouldn't be browsing the Internet with an RTOS setup. That needs to stop yesterday. At least in good theory, Deep Freeze type systems will protect your computer from any permanent modification. They intercept all write activity and remap it. ...


9

It's complicated. Both are Root of Trust for Measurements meaning they can be used to measure the running environment. The main problem with SRTM is that you need to keep measurements of the entire platform boot sequence (BIOS config, 3rd party boot rom (e.g. network cards), etc) and this includes a LOT of code. Any change to any of this requires new ...


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


7

You're very wrong in your last assumption; full disk encryption is not "possible to circumvent with relative ease". It is especially not "possible to circumvent with relative ease" to reach the goal of this workaround IF you're behaving securely. As you've probably figured out by now, this is a physical-access problem. If somebody has physical access to ...


7

Best option is just to encrypt the Linux partition, e.g. with LUKS. That way the Windows 7 partition can't actually access any of the data on the other partition. Technically it can still read and write to the partition (there's no way to prevent this) but the data it sees is all encrypted.


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


6

Before we talk about the single user mode, let's talk about what you can do when you have physical access (in the context of your question, of course). On a Mac, the first thing to boot from another media (LiveCD, USB stick, etc.) and navigate to /var/db/dslocal/nodes/Default/users and modify root.plist and disable the password. On Linux, I'd do the same ...


6

This is exactly the problem that Secure Boot was created to solve. The problem is that if you don't have a chain of trust going all the way back to POST, then you can't guarantee that there hasn't been tampering. (And even then, "guarantee" is an exaggeration). You can checksum the boot partition at startup; perhaps use the checksum as part of the key for ...


5

The TPM doesn't stop the boot. The boot will still continue, but the PCRs will have a different value in them than they used to (since now the BIOS is different than it was before). As a result, the system will be unable to unseal the sealed data. Of course, if the bootloader or kernel is unable to unseal the sealed partition, depending on how it is ...


5

The "right way" to protect boot code on an embedded device is to load from a ROM: it should be hard to modify the boot sector. Even without a true ROM, most flash devices I've seen have a lock sequence you can write from within the flash driver. This makes the device harder to overwrite (not impossible, say by a targeted attack) -- preventing garden variety ...


5

The top security concern is that the only protection of traditional PXE booting is physical security. There is no encryption or authentication anywhere in the process from power-on to OS start. The basic PXE process: Computer makes a DHCP request DHCP server responds with address and PXE parameters Computer downloads boot image using TFTP over UDP The ...


5

In a PXE environment, as a pentester, I have 2 major classes of attack I can choose from. 1: I can capture a full machine image. Do your systems automatically connect to the domain controller after setting up the machine? If so, this image probably has domain controller credentials on it, that I can capture and use elsewhere. 2: I can manipulate images on ...


4

BIOS Most memory chips I've worked with have a W or R/W pin which selects the write mode. Physically tying that one to appropriate logical level should do the trick. Write-protected USB drives I'm a bit suspicious about this one. I've implemented microcontroller<->SD card interface, and the "write-protect" bit is handled completely in software, so you ...


3

Corruption is an act of Evil perpetrated by Bad People. You discovered that when you download things "off the Internet", you sometimes don't obtain the genuine thing. If you need medication, do you go to the pharmacy, or will you prefer something sold by a shifty-looking guy in a back alley ? Don't you believe that inoculating yourself with substance of ...


3

I doubt this is possible to set up in the BIOS. However, even if it was, you have a bigger issue: The only way to identify a USB device is by its vendor and device ID. However, all devices by a specific vendor share the same device ID. So even if you could whitelist your own USB, any USB of that same make would also be accepted. Also, I'm pretty sure it's ...


3

Yes, you can use sdmem tool for your purposes. If you use only bash without any desktop environment you can simple add your command to $HOME/.bash_logout script. In case of using GDM you can try to append sdmem command to /etc/gdm/PostSession/Default file. Also you can to look this and this. Good luck!


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


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


3

One measure to seriously take into consideration with laptop theft protection is physical security. Your thief may not be tech savvy enough to avoid the traps you set, but he's got the unit in his hands already, and depending on what he wants to do with it he can always make a quick buck on the hardware alone. In previous companies I've worked for they did ...


3

It prevents accidental leaks of private data that is copied around. For example, if /tmp is on the / partition, files from your encrypted /home partition could be copied to the unencrypted /tmp, thereby making them accessible to an attacker. By encrypting the entire system, you avoid this channel.


2

There are some variables to take into account. First of all it's not trivial to just access the Linux partitions. Mainly because, natively, Windows does not support ext3 or ext4 which are used to install Linux on. Without these drivers it's impossible to access the drives. Malware will, normally, not have onboard read/write drivers for these filesystems. ...


2

Bitlocker is vulnerable to much the same attack. This paper describes an attack against the PIN: "At the next boot, the MBR boot loader loads this file and transfers control to it. A fake BitLocker prompt is displayed (see figure 1); the entered PIN is stored in the NTFS partition, the original MBR is restored and the system rebooted. Later, the entered PIN ...


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

Have you considered the possibility that a thief opens a laptop, resets the BIOS (by removing the CMOS battery)? Or that the SSD can be removed and wiped/ replaced by a different disk? If you disregard those situations, then you can try to find an option in your BIOS Setup to disable booting from USB and configure a BIOS Setup password. Also note that the ...


2

There are some specific vulnerabilities associated with PXE boot images. Unauthenticated Images. If someone gets onto your network, it's trivial to boot a PXE image from VirtualBox or VMWare. Which means that you now have a rogue host on your network, loaded with all your proprietary software. Local Administrator exploits. (Windows only) Since this ...


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