Linux has a shim problem. Which naturally leads to a reasonable question: What’s a shim, and why do we need it? The answer: Making Linux work wit Secure Boot, and an unintended quirk of the GPLv3.

Secure Boot is the verification scheme in modern machines that guarantees that only a trusted OS can boot. When Secure Boot was first introduced, many Linux fans suggested it was little more than an attempt to keep Linux distros off of consumer’s machines. That fear seems to have been unwarranted, as Microsoft has dutifully kept the Linux Shim signed, so we can all run Linux distros on our Secure Boot machines.

So the shim. It’s essentially a first-stage bootloader, that can boot a signed GRUB2 or other target. You might ask, why can’t we just ask Microsoft to sign GRUB2 directly? And that’s where the GPLv3 comes in. That license has an “anti-tivoization” section, which specifies “Installation Information” as part of what must be provided as part of GPLv3 compliance. And Microsoft’s legal team understands that requirement to apply to even this signing process. And it would totally defeat the point of Secure Boot to release the keys, so no GPLv3 code gets signed. Instead, we get the shim.

Now that we understand the shim, let’s cover how it’s broken. The most serious vulnerability is a buffer overflow in the HTTP file transfer code. The buffer is allocated based on the size in the HTTP header, but a malicious HTTP server can set that value incorrectly, and the shim code would happily write the real HTTP contents past the end of that buffer, leading to arbitrary code execution. You might ask, why in the world does the shim have HTTP code in it at all? The simple answer is to support UEFI HTTP Boot, a replacement for PXE boot.

The good news is that this vulnerability can only be triggered when using HTTP boot, and only by connecting to a malicious server or via a man-in-the-middle attack. With this in mind, it’s odd that this vulnerability is rated a 9.8. Specifically, it seems incorrect that this bug is rated low complexity, or a general network attack vector. In Red Hat’s own write-up of the vulnerability, they argue that the exploitation is high complexity, and is only possible from an adjacent network. There were a handful of lesser vulnerabilities found, and these were all fixed with shim 15.8.

LassPass Banned from the App Store

All we lack here is another app name LastPast, and we’d have the App Store equivalent of three different Spidermen standing in a circle pointing at each other. The devs behind the LastPass app found a suspiciously similar looking LassPass app on the Apple App Store. We’ve seen typosquatting on a bunch of Open Source software repositories, but it’s a problem on the app stores, too.

Three Million Toothbrushes

A story took the security world by storm this week: Three million smart toothbrushes had been compromised, and were used to launch a Distributed Denial of Service (DDoS) attack on a Swiss website. The story originated on a Swiss news website, and was referencing an interview with Stefan Züger of Fortinet.

Before we give away the rest of the story, let’s think about this. The story would be a big deal, but this seems to be the only original source on the Internet. The toothbrush brand isn’t named, and neither is the company that was DDoS’d. Nor was a specific botnet or malware family listed. Smart toothbrushes do exist, but they’re not going to be exposed to the Internet en masse. In fact, it would be unusual for one of these to have connectivity beyond simple Bluetooth. How would malware even get to one of these devices to compromise it?

We could construct a scenario where this could happen. A smart toothbrush would have to have Wifi connection as part of its setup process. This sounds weird, but I’ve seen sillier IoT behavior. Then, the only way to explain so many devices getting compromised all at once is a malicious firmware update. Either through a supply chain attack, or something silly like a domain name lapsing and getting claimed by a threat actor. This rather convoluted scenario could actually explain a three million toothbrush botnet.

But if you haven’t caught on yet, this didn’t happen. It’s a hypothetical scenario roughly based on earlier Fortinet research into what could be done with toothbrush malware (PDF). Bleeping Computer has gotten an official response from Fortinet:

To clarify, the topic of toothbrushes being used for DDoS attacks was presented during an interview as an illustration of a given type of attack, and it is not based on research from Fortinet or FortiGuard Labs. It appears that due to translations the narrative on this topic has been stretched to the point where hypothetical and actual scenarios are blurred.

That’s not quite the end of the story. The site, Aargauer Zeitung was pretty explicit that Stefan from Fortinet said this attack was real in the original article. In response to Fortinet’s announcement, they’ve amended that article, but also published a response, claiming that there was no translation issue — they all speak German after all. They report that Fortinet listed the toothbrush attack as real, gave details about how long it lasted, and about how expensive it was for the victim. The most surprising detail here is that Fortinet did a pre-publication review of the piece, and signed off on it.

So what’s the takeaway here? For one, news sites sometimes get it wrong. If a story seems weird, look for the primary sources. If there aren’t any primary sources, then just maybe something isn’t quite as reported. It’s not entirely clear where the communication breakdown happened in this case, but what seems most likely is that a Fortinet employee read an internal case-study on a hypothetical attack, and thought it was describing a real event. Of all the coverage of this, I think I like the Malwarebytes Blog story the best.

Bits and Bytes

There’s an interesting trick that security researchers have played on themselves. There are too many honeypots out there. Or maybe the problem is that the honeypots are too good at acting like real hardware. Regardless, the process of tracking the number of accessible, vulnerable devices on the Internet is getting to be pretty challenging. The example given is the presence of over 200,000 Confluence results on Shodan, but only 5,000 actual favicon results. That suggests there’s 40 Confluence honeypots for each real server. The mind boggles.

Apparently some heat pumps from Alpha Innotec and Novelan have an undocumented feature: SSH access with a known root password. That’s one way to keep Home Assistant users from spamming your API servers. It probably wasn’t intentional, though. It just happens that a simple password hashed with 3DES can be broken in seconds on a modern machine. It’s eschi if you wondered.

And finally, there was a vulnerability in Mastodon published last week. This is a bug in the federated account handling, such that an attacker can impersonate an account from another server. The update is out now, but the full details won’t be public until the 15th to give server operators time to update. Hackaday.social is already updated, if you wondered.