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. Continue reading “This Week In Security: Broken Shims, LassPass, And Toothbrushes?”

The End Of Landlines?

Imagine if, somehow, telephones of all kinds had not been invented. Then, this morning, someone entered a big corporation board room and said, “We’d like to string copper wire to every home and business in the country. We’ll get easements and put the wires on poles mostly. But some of them will go underground where we will dig tunnels. Oh, and we will do it in other countries, too, and connect them with giant undersea cables!” We imagine that executive would be looking for a job by lunchtime. Yet, we built that exact system and with far less tech than we have today. But cell phones have replaced the need for copper wire to go everywhere, and now AT&T is petitioning California to let them off the hook — no pun intended — for servicing landlines.

The use of cell phones has dramatically decreased the demand for the POTS or plain old telephone service. Even if you have wired service now, it is more likely fiber optic or, at least, an IP-based network connection that can handle VOIP.

Continue reading “The End Of Landlines?”

FLOSS Weekly Episode 769: OpenCost — We Spent How Much?

This week Jonathan Bennett and Katherine Druckman talk with Matt Ray about OpenCost. What exactly is Cloud Native? Why do we need a project just for tracking expenses? Doesn’t the cloud make everything cheaper? Is there a use case for the hobbyist?

The cloud is just a fancy way to talk about someone else’s servers — and what may surprise you is that they charge you money for the privilege of using those computers. But how much? And when you have multiple projects, which ones cost how much? That’s where OpenCost comes in. Not only does it help you track down costs in your cloud usage, it can also catch problems like compromised infrastructure sooner. Mining bitcoin in your Kubernetes Cluster makes a really noticeable spike in processor usage after all.
Continue reading “FLOSS Weekly Episode 769: OpenCost — We Spent How Much?”

Friendly Flexible Circuits: The Cables

Flexible cables and flex PCBs are wonderful. You could choose to carefully make a cable bundle out of ten wires and try to squish them to have a thin footprint – or you could put an FFC connector onto your board and save yourself a world of trouble. If you want to have a lot of components within a cramped non-flat area, you could carefully design a multitude of stuff FR4 boards and connect them together – or you could make an FPC.

Flexible cables in particular can be pretty wonderful for all sorts of moving parts. They transfer power and data to the scanner head in your flat-bed scanner, for instance.  But they’re in fixed parts too.  If you have a laptop or a widescreen TV, chances are, there’s an flexible cable connecting the motherboard with one or multiple daughterboards – or even a custom-made flexible PCB. Remember all the cool keypad and phones we used to have, the ones that would have the keyboard fold out or slide out, or even folding Nokia phones that had two screens and did cool things with those? All thanks to flexible circuits! Let’s learn a little more about what we’re working with here.

FFC and FPC, how are these two different? FFC (Flexible Flat Cable) is a pre-made cable. You’ve typically seen them as white plastic cables with blue pieces on both ends, they’re found in a large number of devices that you could disassemble, and many things use them, like the Raspberry Pi Camera. They are pretty simple to produce – all in all, they’re just flat straight conductors packaged nicely into a very thin cable, and that’s why you can buy them pre-made in tons of different pin pitches and sizes. If you need one board to interface with another board, putting an FFC connector on your board is a pretty good idea.

Continue reading “Friendly Flexible Circuits: The Cables”

Retrotechtacular: The Master Hands Of The Early Automotive Industry

When motion pictures came along as a major medium in the 1920s or so, it didn’t take long for corporations to recognize their power and start producing promotional pieces. A lot of them are of the “march of progress” genre, featuring swarms of workers happy in their labors and creating the future with their bare hands. If we’re being honest, a lot of it is hard to watch, but “Master Hands,” which shows the creation of cars in the 1930s, is somehow more palatable, mostly because it’s mercifully free of the flowery narration that usually accompanies such flicks.

“Master Hands” was produced in 1936 and focuses on the incredibly labor-intensive process of turning out cars, which appear to be the Chevrolet Master Deluxe, likely the 1937 model year thanks to its independent front suspension. The film is set at General Motors’ Flint Assembly plant in Flint, Michigan, and shows the entire manufacturing process from start to finish. And by start, we mean start; the film begins with the meticulous work of master toolmakers creating the dies and molds needed for forging and casting every part of the car. The mold makers and foundrymen come next, lighting their massive furnaces and packing the countless sand molds needed for casting parts. Gigantic presses stamp out everything from wheels to frame rails to body panels, before everything comes together at the end of the line in a delicate ballet of steel and men.

Continue reading “Retrotechtacular: The Master Hands Of The Early Automotive Industry”

Human-Interfacing Devices: Packing For The Descriptor Heist

We started with figuring out HID descriptors a week ago, and I’ve shown you how to send raw HID packets using a MicroPython fork. We do still have the task in front of us – making a touchscreen device. For that, let’s give you the tools to capture an existing descriptor from a touchscreen, then show you how to tweak it and how it turns out in the end.

Packing For The Heist

When it comes to this kind of adventure, we can’t go without tools and weapons – it could be dangerous! Without them, you could even abandon your project halfway! Here’s enough high-precision tools and ammunition to last you through whatever obstacles you might encounter. Except for the web-based tools, these tools are for Linux, but please remember that you can always use a virtual machine or a Raspberry Pi. Nobody would use Windows for a heist anyway, what’s with all the telemetry and such.

The first tool is for reading descriptors – we need one to learn from, it’s just like a keycard you can flash to a security guard and scan at the vault entry. Of course, with RFID, you want to have enough examples, compare bits between a few cards and all. For now, HID descriptors don’t have authenticity checks, but it looks like that might just change in the future. Leave it to Apple and Microsoft to add them, as usual. On Linux, seeing descriptors is simple – as root, go into /sys/bus/usb/devices/, find your device by its lsusb device tree path, then follow the directory with the VID/PID in it. That directory will contain a report_descriptor file – hexdump it. The entire command could look like this:

sudo hexdump -v -e '/1 "%02X "' /sys/bus/usb/devices/3-6.2/3-6.2\:1.1/0003\:0C40\:8000.0022/report_descriptor

Again, you might need root to even find this path, so use sudo -i if you must. The format string in the hexdump command gives you parser-friendly output. Specifically, for parsing, I use this webpage – it’s wonderful, even adding tabs that delineate different sections of the descriptor, making its output all that more readable! You can also save this webpage locally, it’s a very neat tool. Other than that, you can try other local tools like this one!

Continue reading “Human-Interfacing Devices: Packing For The Descriptor Heist”

Biomedical Engineering Hack Chat

Join us on Wednesday, February 7 at noon Pacific for the Biomedical Engineering Hack Chat with Nyeli Kratz!

Although medical doctors and engineers generally work in completely different domains, there’s a fair amount of overlap between the disciplines. At the end of the day, they both solve problems, and while doctors clearly focus on the biological aspects of disease, there just might come a point where the problem has to be addressed with engineering principles. From the intricate design of an artificial hip to the electrical interface between an amputee’s nervous system and a prosthetic limb, biomedical engineers can make a tremendous contribution to positive patient outcomes.

join-hack-chatNyeli Kratz, a recent biomedical engineering grad, has worked on quite a few engineering solutions to diseases. Many of her projects, like this stand-up mobility aid or a wheelchair attachment that lets a tetraplegic father interact with his newborn child, seem aimed at making it easier for patients to interact with the world. She’ll stop by the Hack Chat to talk about these projects in particular as well as what the engineer brings to the table when it’s time to design hardware that heals.

Our Hack Chats are live community events in the Hackaday.io Hack Chat group messaging. This week we’ll be sitting down on Wednesday, February 7 at 12:00 PM Pacific time. If time zones have you tied up, we have a handy time zone converter.