Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Defeating a Laptop's BIOS Password

github.com

Post reply on HN
Print view View original

11–20 of 100 posts

Re: Defeating a Laptop's BIOS Password

#11

Post by onedognight »

Razengan wrote: post #2

> Even today's modern 64-bit CPUs begin execution in 16-bit mode. In UEFI, this is called the SEC phase. Is that true even for the T2 Macs and such?

Apple has been moving their defenses earlier and earlier in the boot process. According to this talk[0] they are even able to foil malicious option ROM[1] and other early boot attacks. I don’t recall if they mention boot passwords specifically, but they claim to lead the industry in this regard.

[0] https://youtu.be/3byNNUReyvE

[1] https://www.blackhat.com/us-19/briefings/schedule/#behind-th...

Re: Defeating a Laptop's BIOS Password

#12

Post by TrueDuality »

I'm curious if TPM measurements would catch these kind of manipulations. It's probably system specific but the configuration of the BIOS should (as far as I understand it) be captured as part of the measurement process.

If requisite credentials or remote attestation is sealed against a certain measurement value it should protect the system.

Re: Defeating a Laptop's BIOS Password

#13

Post by Avery3R »

onedognight wrote: post #11
Razengan wrote: post #2

> Even today's modern 64-bit CPUs begin execution in 16-bit mode. In UEFI, this is called the SEC phase. Is that true even for the T2 Macs and such?

Apple has been moving their defenses earlier and earlier in the boot process. According to this talk[0] they are even able to foil malicious option ROM[1] and other early boot attacks. I don’t recall if they mention boot passwords specifically, but they claim to lead the industry in this regard. [0] https://youtu.be/3byNNUReyvE [1] https://www.blackhat.com/us-19/briefings/schedule/#behind-th...

Verification of option roms as a part of secure boot is a part of the normal uefi spec, however some vendors forgot to implement it

https://docs.microsoft.com/en-us/windows-hardware/manufactur...

Re: Defeating a Laptop's BIOS Password

#14

Post by pwg »

fortran77 wrote: post #5
Avery3R wrote: post #3

Earlier quoted context omitted.

I'm not that familiar with Macs, but if they're using an Intel CPU it almost definitely starts in 16-bit mode. From what I understand the T2 chip is more akin to what's called an embedded controller in other laptops.

According to the CPU processor manuals, they all boot in "real mode" which is a 16-bit legacy/bootstrap mode.

Yes, all Intel X86 CPU's start up in 'real mode' which is 16-bit mode.

They start this way because at initial reset none of the required data structures for protected mode operation (page tables, GDT, IDT, etc.) are present. So the CPU starts up as a very fast 8086 who's purpose is to setup just enough page tables, a GDT, an IDT, etc. to be able to switch into protected mode and continue system bootstrap.

Re: Defeating a Laptop's BIOS Password

#16

Post by Legogris »

I was of the impression that BIOS passwords were in general not something one should rely even as a layer when assuming physical access. In the (not that) old days it was usually just a matter of removing the internal battery to reset it. Has this assumption changed in past years?

Re: Defeating a Laptop's BIOS Password

#18

Post by Avery3R »

TrueDuality wrote: post #12

I'm curious if TPM measurements would catch these kind of manipulations. It's probably system specific but the configuration of the BIOS should (as far as I understand it) be captured as part of the measurement process. If requisite credentials or remote attestation is sealed against a certain measurement value it should protect the system.

The way locking a TPM to firmware config works is that the TPM has several registers called PCRs that contain a hash value. Anything can send data to the TPM and have it update the hash value, and you can lock TPM keys to the PCRs such that you can only use the key when the PCRs you choose have a specific value. The TCG spec defines some of these PCRs to be sent certain information [0], but it's up to the firmware to send it, the TPM doesn't magically know what the state is. If there's even a single setting or nvram variable that you can change to gain code execution that isn't part of the data that's sent to the PCRs that the crypto key is locked to, it's game over.

[0]: https://trustedcomputinggroup.org/wp-content/uploads/TCG-EFI...

Re: Defeating a Laptop's BIOS Password

#19

Post by unnouinceput »

Legogris wrote: post #16

I was of the impression that BIOS passwords were in general not something one should rely even as a layer when assuming physical access. In the (not that) old days it was usually just a matter of removing the internal battery to reset it. Has this assumption changed in past years?

A bit, as posted in this blog, but for most part having physical unlimited access to a device it's game over. Hence why encrypting your sensitive data should be the norm (I am aware that is not the norm, not by far)
Post reply on HN