Schneier on Security

ffinley • December 12, 2023 1:27 PM

Ray, that’s a good question and we discussed the story a bit here:
https://www.schneier.com/blog/archives/2023/12/friday-squid-blogging-strawberry-squid-in-the-galapagos.html

(My follow-up message has apparently been stuck in moderation for a week. I suggested referring to data as “user-controlled” or “attacker-controlled” instead of “unchecked”, because “checking” hints at bad designs and “where does this data come from?” is what we really care about.)

The short answer is that the BIOS is not looking to execute code at all, but is parsing incompetently and with no protection. It’s your standard buffer overrun; understood since 1972, famously exploited by Morris in 1988, and popularized in 1995 and 1996. Bruce wrote “the ability has to be in the BIOS, which means that the vulnerabilities aren’t being protected by any of the OS’s defenses”—which is kind of true, but misleading. Yes, the OS itself has no opportunity to protect anything here, but “OS defenses” could certainly be implemented in firmware (and in fact Intel is known to embed an entire OS, Minix, in their management engine firmware).

Realistically, I see two simple and safe ways to implement this feature. One, don’t support any form of compression or other format-complexity; for example, say that anyone who wants their image to be shown shall store in it the format of a 16-bit little-endian width, then height, followed by raw triplets being {R,G,B} bytes. A severely-restricted BMP parser could be called a variant of this option. Or, two, parse the data entirely via the CPU’s protected mode, providing exactly one syscall: “I’m done”. I say, go with option 2 because there are probably about a hundred other places a BIOS-maker could use such a feature.

ffinley • December 13, 2023 2:04 PM

Clive, I’m not sure the lack of signing was itself either a “hole” or “backdoor”. As I understand it, all executable code was meant to be signed, and this extra data—probably meant to be treated similarly to “EFI variables”—couldn’t have been executed if the parser(s) were competently programmed. To let a corporate buyer display their own logo, with an entirely signed payload, the buyer would have to be able to enroll their own key… which is possible, so how would it prevent this exploit? (And have people checked the key-parsers for similar bugs?)

Maybe something interesting could’ve been done with multiple levels of keys, or with write-once memory (e-fuses?). The complexity of that would probably be more work than just writing (or sandboxing) the image parser correctly, and extra complexity is often harmful to overall security. Let’s not expect too much of BIOS-writers. I guess Intel made that mistake already, by providing a design that encourages privileged code execution and lacks pre-written sandboxing.

A semi-related question for everyone: a lot of high-end motherboards can flash BIOS images directly from FAT-formatted USB flash drives, with no CPU or RAM installed. They’re obviously doing it from some kind of auxiliary CPU/MCU. Are those things checking any signatures at all?

And a slight rant: if UEFI ran faster, no logos would be needed, because we’d be in the bootloader before the monitor recognized its video signal. Has anyone here ever written code directly into a BIOS chip? I have, and was amazed the first time I ran it: the “hello world” message appeared (via serial port) so quickly I didn’t even notice it, because my eyes were still looking toward the power button. I don’t know what my PC does for the 20-40 seconds before transferring control, but that kind of delay is absolutely unacceptable in many embedded markets—CPUs themselves are executing code from EEPROM within milliseconds, and a car for example has just 2,000 milliseconds to display a rear-view camera image (per American regulatory requirements; that’s from the key being turned, and despite the horrendous electrical noise occurring during that period).

ffinley • December 14, 2023 2:42 AM

Secondly if I was to say you can not “competently program” to the extent you imply you might be a little shocked…

The core requirement is to read some image data without confusing it with code, and to put it on the screen. It’s not to parse every image format currently in existence, to parse any image format currently in existence, or to run a user-provided image parser. So, I doubt the Halting Problem comes into play. If it did, we’d have several viable options:

• ignore it; if LogoFAIL could only put UEFI into an infinite loop, would anyone care?
• mitigate it with a simple timeout
• avoid it by creating an intentionally non-Turing-complete execution environment for the parser (Coq and the original Berkeley Packet Filter do this)
• or just solve it; that can’t be done for every program, but the BIOS developers can keep re-writing till they get a solvable one (as I believe is common in formal verification)

The necessary competence, though, could be as simple as deciding to “take the hit” of sticking several megabytes of raw pixel data into EEPROM, and programming the display controller to use that hard-coded address as its framebuffer. Or, as I said, relying on the existing CPU machinery, thus moving most of the responsibility onto someone else. I’m sure you can point out various flaws of CPU protection modes (side channels, especially), but are any of them likely to matter in this highly limited context?

We can infer a requirement from what Bruce wrote: UEFI should have operating-system-style defenses against vulnerabilities. Don’t over-complicate it.

ffinley • December 14, 2023 11:44 AM

A 24-bit 1024×768 graphic will be 2.25 MB, and any desktop monitor will scale it up. A laptop display won’t, though modern display controllers can also scale things and do partial-screen overlays. It’s common to find cheap routers with 64 MB to 256 MB flash chips; desktop systems often have room for 2 copies of the BIOS code, and graphics don’t need to be duplicated that way. So I think uncompressed graphics could be made to work, if a developer couldn’t come up with something better.

Most people don’t consider it “buck-passing” in a negative sense when an operating system uses CPU features to run user-provided code—let alone unchanging vendor-provided code for handling a simple vendor-defined format. Granted, it’s been a never-ending battle in recent years with speculative execution, but UEFI could go down the “slow paths” for everything and still decompress a single graphic quickly enough. Rowhammer shouldn’t matter if the code can’t access the CPU’s DRAM or there’s nothing there to attack, and both could be arranged: run the decompressor from ROM with the page tables configured so only the video RAM or the CPU’s SRAM cache is writable.

The preceding paragraph assumes the vendor-provided decompressor will fail, so as to execute user-provided image data as code. I don’t think that’s fair. A simple run-length-encoded (RLE) decompressor is a tiny amount of code that could be made to read and write its data in order, one byte at a time, thus easily made to fault upon overflowing either buffer. Even if one forgoes formal verification, what’s the attack there? (Assuming the code doesn’t make the Xbox mistake of expecting address-space wraparound to fault.)

ffinley • December 14, 2023 6:15 PM

Trying to push back is often a risky endeavor if you want to keep “that” job.

I’m well aware it’s the common view. I just don’t think it’s true. Or if it is, I’d be self-selecting myself out of companies I wouldn’t want to work for anyway, and getting severance pay in the process.

As a personal anecdote, in my very first year working, I became aware on a Tuesday or Wednesday of an interesting bug; a critical one that a customer wanted an immediate fix for. I wasn’t busy at the time, so I mentioned to my manager that I had a hypothesis and would love to test it and maybe fix the bug. “No, we’ve got it under control; don’t worry about it.” I checked the progress a day or two later and was assured all was well.

Then, late Friday afternoon: “we’re gonna need you to work the weekend”; the team had made zero progress. So I said “no”; that I’d be at home relaxing, but I’d spend the remaining hour of the day summarizing the hypothesis I’d offered to share earlier, and the possible steps to prove or disprove it.

On Monday, a bunch of people had worked all weekend with little to show. By lunch I’d proven my root-cause hypothesis correct, and by the end of the day a patched version was under code-review while being beta-tested by the quality assurance team.

Where did that leave me? A few months later, that manager was gone, and I was given a promotion and raise. (Did you think Office Space was a fully fictional movie?) Nobody who’d worked the weekend got any kind of recognition or reward, nor did anyone seem to care or remember that I’d refused. When I handed in a letter of resignation to my (new) manager later that year, I was meeting with a vice-president within an hour, who tried to convince me to stay. I no longer ask permission to do something properly, or fix important problems; I just do it. (As it turns out, that’s not “going rogue”, it’s “having initiative” or “not needing micro-management”.)

Upper management desperately want programmers to be interchangeable cogs, and it’s to management’s benefit if the programmers believe it. But I’ve interviewed candidates, and I can tell you that it’s just not true. A co-interviewer once told me they could easily step outside our office, swing a dead cat, and hit several programmers; nevertheless, we’re interviewing 5 to 10 people to hire one, and I’m told many, many more CVs are rejected before anyone technical sees them. It follows that people rarely get fired “out of the blue”; the risk is actually very low unless one’s already on a “performance improvement plan” or does something that’s obviously “just cause”.