Last week we covered the latest 0-day from NSO group, BLASTPASS. There’s more details about exactly how that works, and a bit of a worrying revelation for Android users. One of the vulnerabilities used was CVE-2023-41064, a buffer overflow in the ImageIO library. The details have not been confirmed, but the timing suggests that this is the same bug as CVE-2023-4863, a Webp 0-day flaw in Chrome that is known to be exploited in the wild.
The problem seems to be an Out Of Bounds write in the
BuildHuffmanTable() function of libwebp. And to understand that, we have to understand libwebp does, and what a Huffman Table has to do with it. The first is easy. Webp is Google’s pet image format, potentially replacing JPEG, PNG, and GIF. It supports lossy and lossless compression, and the compression format for lossless images uses Huffman coding among other techniques. And hence, we have a Huffman table, a building block in the image compression and decompression.
What’s particularly fun about this compression technique is that the image includes not just Huffman compressed data, but also a table of statistical data needed for decompression. The table is rather large, so it gets Huffman compressed too. It turns out, there can be multiple layers of this compression format, which makes the vulnerability particularly challenging to reverse-engineer. The vulnerability is when the pre-allocated buffer isn’t big enough to hold one of these decompressed Huffman tables, and it turns out that the way to do that is to make maximum-size tables for the outer layers, and then malform the last one. In this configuration, it can write out of bounds before the final consistency check.
An interesting note is that as one of Google’s C libraries, this is an extensively fuzzed codebase. While fuzzing and code coverage are both great, neither is guaranteed to find vulnerabilities, particularly well hidden ones like this one. And on that note, this vulnerability is present in Android, and the fix is likely going to wait til the October security update. And who knows where else this bug is lurking. Continue reading “This Week In Security: WebP, Cavium, Gitlab, And Asahi Lina”
[Alyssa Rosenzweig] has been tirelessly working on reverse engineering the GPU built into Apple’s M1 architecture as part of the Asahi Linux effort. If you’re not familiar, that’s the project adding support to the Linux kernel and userspace for the Apple M1 line of products. She has made great progress, and even got primitive rendering working with her own open source code, just over a year ago.
Trying to mature the driver, however, has hit a snag. For complex rendering, something in the GPU breaks, and the frame is simply missing chunks of content. Some clever testing discovered the exact failure trigger — too much total vertex data. Put simply, it’s “the number of vertices (geometry complexity) times amount of data per vertex (‘shading’ complexity).” That… almost sounds like a buffer filling up, but on the GPU itself. This isn’t a buffer that the driver directly interacts with, so all of this sleuthing has to be done blindly. The Apple driver doesn’t have corrupted renders like this, so what’s going on?
Continue reading “Asahi GPU Hacking”
Regardless of the chipset or original intended use of any computer system, someone somewhere is going to want to try and run Linux on it. And why not? Linux is versatile and free to use as well as open-source, so it’s quite capable of running on almost anything. Of course, it takes a little while for the Linux folk to port the software to brand new hardware, but it’s virtually guaranteed that it’s only a matter of time before Linux is running on even the most locked-down of hardware, like the M1 MacBooks.
[Hector Martin] aka [marcan] has been hard at work getting Linux up and running on the latest Apple offerings with their ARM-based M1 processors. Since these are completely divorced from their x86 product line the process had to be worked from the ground up which included both booting Linux and modifying the kernel to include support for the hardware. [marcan] has a lot of hardware working such as the USB ports and the SD card slot, and notes that his setup is even compatible with the webcam notch included in the latest batch of MacBooks.
There are a few things still missing. He’s running Arch and doesn’t have the GPU configured yet, so all of the graphics are rendered in software. But he has put the computer through the wringer including running some computationally-intense software for nearly a full day before realizing that the machine wasn’t charging, which did not make much difference in performance. These machines are indeed quite capable with their new ARM chipsets and hopefully his work going forward will bring Linux to the rest of us who still use Macs even if they don’t want to run macOS.
We love beer and we love robots, so guessing how we feel about this robotic bartender should be a no-brainer. Known as Mr. Asahi, the robot opens bottles and pours beer while taking your orders with aplomb and a jovial British accent. It also has a customized lazy susan with slots for bottles and notches for the robot’s hand to grasp.
Amazingly, this is not Asahi’s first beer pouring robot. That one requires you to do most of the leg work, though, so this one is a marked improvement. Best of all, it won’t ignore you when a person more attractive than you comes into the bar, and it won’t snub you for leaving a lousy tip. We now fear alcohol fueled robot rampages… they get more human every day. Video after the break.
Continue reading “Beer Bot Will Pour You A Cold One”