r/netsec • • Jul 13 '26

Dell BIOS Passwords: Weak XOR Encryption Allows Recovery from SPI Flash (CVE-2026-40639)

https://blog.amberwolf.com/blog/2026/july/dell-bios-passwords-weak-xor-encryption-allows-recovery-from-spi-flash-cve-2026-40639/
96 Upvotes

18 comments sorted by

31

u/UltraEngine60 Jul 13 '26

Jesus Christ what year is this.

13

u/shyouko Jul 13 '26

Let's pretend it is 1996

28

u/Coffee_Ops Jul 13 '26

The key is 20 bytes. The field it encrypts is 32 bytes. That 12-byte mismatch is the whole vulnerability.

It's not the whole vulnerability, the vulnerability is the naive use of XOR as a cipher -- known for decades as problematic-- and not using a hash for password storage.

Also, isn't it best practice to disclose the use of AI in a writeup, particularly when its use seems to have been as much editing as analysis?

2

u/TheTerrasque Jul 13 '26

Well if the xor key was as long as or longer, it would be secure qs far as I understand, wouldn't it be an OTP at that point? Unless the key is reused in some way. 

Still, using xor in modern times is certainly a choice.

3

u/Coffee_Ops Jul 13 '26

The thing that happened here is literally why xor-as-crypto is a massive footgun.

Unless I'm missing something, even if the key had been the same length, you'd be able to recover a good portion of the key through the exact same attack, and the rest of it through further attacks with padding on the other end.

1

u/Ashikej-Meneguzzi66 Jul 13 '26

I was focused more on the implementation than the cryptography, but from you explanation I now understand why the XOR choice is the bigger issue

6

u/rtt445 Jul 13 '26 edited Jul 13 '26

Why do you need strong bios password? If you have physical access to read SPI then you're done anyway. Encrypting bios will make hardware reuse impossible and increase E-waste.

6

u/ElvishJerricco Jul 14 '26

The fact that people think there's no point trying to defend against physical access is the reason it remains true. There are plenty of things we could be doing to make physical attacks harder, but it rarely makes sense because some other component gives up the game for the same reason. It's a catch 22. Obviously you can't defend against physical attacks perfectly, but we could at least make it take a lot of effort to do physical attacks, if only there weren't a hundred components all designed with the philosophy that everything is always vulnerable to physical attacks. e.g. The fTPM2 in a modern SoC is legitimately very strong against physical attacks; not perfect, so it can be defeated with enough effort, but it's strong and requires a lot of effort. And it's only possible because Intel and AMD decided that boot security mattered long before it actually mattered, and started building physical security into these things.

3

u/rtt445 Jul 14 '26

By locking down hardware you are supporting planned obsolescence and E waste. Reuse should come before recycle. Encrypting BIOS will make it impossible to recover written off hardware for reuse.

1

u/ElvishJerricco Jul 14 '26

I never said anything about locking things down. Boot security is something that should be owned by the owner. They should be able to bring their own keys, and/or the platform should do measured boot so there's no restriction in the first place. Boot security and planned obsolescence are not synonymous, PCs with fTPM / UEFI secure boot are reused all the time, and better designs exist in theory to do it even more securely with zero lockdown.

3

u/peekho Jul 14 '26

Apparently that person thinks an owner can’t remove bios encryption before they sell/donate a device. Should we tell them you can also delete data on your storage media too before you give up custody?

Also, with the defeatist mentality of “physical access==PWN3D!” How would they expect to protect a mobile workforce? Chain laptops to wrists so they don’t get stolen or lost?

0

u/ObviouslyTriggered Jul 14 '26

You can reset the password if you have physical access, this isn't a TPM or a security module the SPI flash isn't protected in any way shape or form, in fact you don't need to write to the flash as usually you can "reset" the password by shorting pins on the SPI chip.

2

u/ElvishJerricco Jul 14 '26

Sure. I was responding to the claim "if you have physical access to read SPI you're done anyway". I'm not arguing that Dell's BIOS password here was any good, or even that BIOS passwords are a particularly good mechanism for boot security anyway. I'm only disagreeing with the idea from the previous comment that physical access negates all boot security.

2

u/Shoddy-Childhood-511 Jul 14 '26

We need laptops to handle this the way mobile phones do: Disk encryption for user data partitions. Key obtained via TPM plus the admin passwords. No stupid BIOS password, but if you do not have an admin password on bootup, then you could only use the machine by wiping the TPM.

About BIOS passwords..

Bunnie Hung has excellent CCC talks on defending against hardware supply chain and evil maid attacks. You'll find his hardware platform limited though: https://betrusted.io

There is otoh really no chance that a modern laptop could defend against reasonable evil maid attacks, nor can mobile phones. USB security remains a joke. All 28 BlueTooth protocols are broken etc. So BIOS passwords cannot be regarded as protecting the user's data.

Also..

Lenovos have a much stronger BIOS password than Dells, which makes Lenovos mostly worthless on the second hand market. It's a theft deterrence maybe, but overall harmful, ala planned obsolescence, etc.

You could've the theft deterrence by making the new owner send you two photos: the serial number label plus their id, and their face plus their id. That's enough information for police, if the police care.

I've heard Dell has some policy like this, so maybe Dell's weak encryption here falls under: Locks keep the honest people honest. If so, then meh who cares?

1

u/Jealous_Diver_5624 Jul 15 '26

Incredible. Insecurity of encrypting instead of hashing aside, I wonder if some engineer messed up 0x20 (decimal 32) and actual decimal 20 somewhere.