This Week In Security: Broken Shims, LassPass, And Toothbrushes?

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. is already updated, if you wondered.

8 thoughts on “This Week In Security: Broken Shims, LassPass, And Toothbrushes?

    1. All of my employer’s PCs and servers use secure boot, including the Linux workstations and servers. The shim is very important for us. For us, outside threats are unlikely due to firewalls, but not impossible for an inside threat.
      I have implemented various network protocols in the past. I always made sure to first check I could allocate a large enough buffer and then to only read in as many bytes as specified in the message header. It’s the right way to do it.

    2. If secure boot is enabled, you wouldn’t even notice. I installed debian on a machine and only noticed secure boot was on because I could not access PCI devices from userspace (which apparently happens due to secure boot). The install of the shim happens without you noticing it.

    3. I use secure boot on my Linux machines, but I replaced Microsoft’s keys with my own in the BIOS, and I sign everything myself.

      On my laptop, I run Gentoo with systemd-boot, and TPM2+PIN for LUKS full disk encryption key derivation, using a secure boot signed combined kernel and initrd image, and seal the key to TPM2 PCRs 0, 1, 2, 4, 7 and 12.

      The idea behind using Secure Boot and the TPM2 is to defend against evil-maid attacks. I would be alerted to secure boot being turned off if my TPM2 pin doesn’t unlock my disk, and even if my PIN got transmitted at that moment, it is useless without the TPM2 unlocking the actual decryption key for the disk.

      As for why I set this craziness up: Because I could! and/or why not? :D

  1. I leave it off because Windows will do stupid things like encrypt your whole drive if you do something as silly as log into Windows with a Microsoft account with TPM enabled. Thats a bunch of cruft I don’t want. For corporate use sure I guess.

  2. If you are a creature who has any self-awareness you would know how nasty MS is
    And you would incidentally also know that things like AI are not primarily there to help the user but rather to gather profiling info on them. MS are known Mofos and getting worse and worse.
    And the worse part is that they are not only aided by everybody and their aunt, but their behaviour is also ignored by the politicians that are supose to keep things in check. Money talks, and it’s the native language of mofos.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.