This Week In Security: IPhone Unpowered, Python Unsandboxed, And Wizard Spider Unmasked

As conspiracy theories go, one of the more plausible is that a cell phone could be running malicious firmware on its baseband processor, and be listening and transmitting data even when powered off. Nowadays, this sort of behavior is called a feature, at least if your phone is made by Apple, with their Find My functionality. Even with the phone off, the Bluetooth chip runs happily in a low-power state, making these features work. The problem is that this chip doesn’t do signed firmware. All it takes is root-level access to the phone’s primary OS to load a potentially malicious firmware image to the Bluetooth chip.

Researchers at TU Darmstadt in Germany demonstrated the approach, writing up a great paper on their work (PDF). There are a few really interesting possibilities this research suggests. The simplest is hijacking Apple’s Find My system to track someone with a powered down phone. The greater danger is that this could be used to keep surveillance malware on a device even through power cycles. Devices tend to be secured reasonably well against attacks from the outside network, and hardly at all from attacks originating on the chips themselves. Unfortunately, since unsigned firmware is a hardware limitation, a security update can’t do much to mitigate this, other than the normal efforts to prevent attackers compromising the OS.
Continue reading “This Week In Security: IPhone Unpowered, Python Unsandboxed, And Wizard Spider Unmasked”

Things Are Getting Rusty In Kernel Land

There is gathering momentum around the idea of adding Rust to the Linux kernel. Why exactly is that a big deal, and what does this mean for the rest of us? The Linux kernel has been just C and assembly for its entire lifetime. A big project like the kernel has a great deal of shared tooling around making its languages work, so adding another one is quite an undertaking. There’s also the project culture developed around the language choice. So why exactly are the grey-beards of kernel development even entertaining the idea of adding Rust? To answer in a single line, it’s because C was designed in 1971, to run on the minicomputers at Bell Labs. If you want to shoot yourself in the foot, C will hand you the loaded firearm.

On the other hand, if you want to write a kernel, C is a great language for doing low-level coding. Direct memory access? Yep. Inline assembly? Sure. Runs directly on the metal, with no garbage collection or virtual machines in the way? Absolutely. But all the things that make C great for kernel programming also make C dangerous for kernel programming.

Now I hear your collective keyboards clacking in consternation: “It’s possible to write safe C code!” Yes, yes it is possible. It’s just very easy to mess up, and when you mess up in a kernel, you have security vulnerabilities. There’s also some things that are objectively terrible about C, like undefined behavior. C compilers do their best to do the right thing with cursed code like i++ + i++; or a[i] = i++;. But that’s almost certainly not going to do what you want it to, and even worse, it may sometimes do the right thing.

Rust seems to be gaining popularity. There are some ambitious projects out there, like rewriting coreutils in Rust. Many other standard applications are getting a Rust rewrite. It’s fairly inevitable that the collection of Rust developers started to ask, could we invade the kernel next? This was pitched for a Linux Plumbers Conference, and the mailing list response was cautiously optimistic. If Rust could be added without breaking things, and without losing the very things that makes Rust useful, then yes it would be interesting. Continue reading “Things Are Getting Rusty In Kernel Land”

Asahi GPU Hacking

[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”

This Week In Security: F5 Twitter PoC, Certifried, And Cloudflare Pages Pwned

F5’s BIG-IP platform has a Remote Code Execution (RCE) vulnerability: CVE-2022-1388. This one is interesting, because a Proof of Concept (PoC) was quickly reverse engineered from the patch and released on Twitter, among other places.

HORIZON3.ai researcher [James Horseman] wrote an explainer that sums up the issue nicely. User authentication is handled by multiple layers, one being a Pluggable Authentication Modules (PAM) module, and the other internally in a Java class. In practice this means that if the PAM module sees an X-F5-Auth-Token, it passes the request on to the Java code, which then validates the token to confirm it as authentic. If a request arrives at the Java service without this header, and instead the X-Forwarded-Host header is set to localhost, the request is accepted without authentication. The F5 authentication scheme isn’t naive, and a request without the X-F5-Auth-Token header gets checked by PAM, and dropped if the authentication doesn’t check out.

So where is the wiggle room that allows for a bypass? Yet another HTTP header, the Connection header. Normally this one only comes in two varieties, Connection: close and Connection: keep-alive. Really, this header is a hint describing the connection between the client and the edge proxy, and the contents of the Connection header is the list of other headers to be removed by a proxy. It’s essentially the list of headers that only apply to the connection over the internet. Continue reading “This Week In Security: F5 Twitter PoC, Certifried, And Cloudflare Pages Pwned”

This Week In Security: UClibc And DNS Poisoning, Encryption Is Hard, And The Goat

DNS spoofing/poisoning is the attack discovered by [Dan Kaminski] back in 2008 that simply refuses to go away. This week a vulnerability was announced in the uClibc and uClibc-ng standard libraries, making a DNS poisoning attack practical once again.

So for a quick refresher, DNS lookups generally happen over unencrypted UDP connections, and UDP is a stateless connection, making it easier to spoof. DNS originally just used a 16-bit transaction ID (TXID) to validate DNS responses, but [Kaminski] realized that wasn’t sufficient when combined with a technique that generated massive amounts of DNS traffic. That attack could poison the DNS records cached by public DNS servers, greatly amplifying the effect. The solution was to randomize the UDP source port used when sending UDP requests, making it much harder to “win the lottery” with a spoofed packet, because both the TXID and source port would have to match for the spoof to work.

uClibc and uClibc-ng are miniature implementations of the C standard library, intended for embedded systems. One of the things this standard library provides is a DNS lookup function, and this function has some odd behavior. When generating DNS requests, the TXID is incremental — it’s predictable and not randomized. Additionally, the TXID will periodically reset back to it’s initial value, so not even the entire 16-bit key space is exercised. Not great. Continue reading “This Week In Security: UClibc And DNS Poisoning, Encryption Is Hard, And The Goat”

This Week In Security: Android And Linux, VirusTotal, More Psychic Signatures

To start our week of vulnerabilities in everything, there’s a potentially big vulnerability in Android handsets, but it’s Apple’s fault. OK, maybe that’s a little harsh — Apple released the code to their Apple Lossless Audio Codec (ALAC) back in 2011 under the Apache License. This code was picked up and shipped as part of the driver stack for multiple devices by various vendors, including Qualcomm and MediaTek. The problem is that the Apple code was terrible, one researcher calling it a “walking colander” of security problems.

Apple has fixed their code internally over the years, but never pushed those updates to the public code-base. It’s a fire-and-forget source release, and that can cause problems like this. The fact that ALAC was released under a permissive license may contribute to the problem. Someone (in addition to Apple) likely found and fixed the security problems, but the permissive license doesn’t require sharing those fixes with a broader community. It’s worth pondering whether a Copyleft license like the GPL would have gotten a fix distributed years ago.

Regardless, CVE-2021-0674 and CVE-2021-0675 were fixed in both Qualcomm and MediaTek’s December 2021 security updates. These vulnerabilities are triggered by malicious audio files, and can result in RCE. An app could use this trick to escape the sandbox and escalate privileges. This sort of flaw has been used by actors like the NSO group to compromise devices via messaging apps. Continue reading “This Week In Security: Android And Linux, VirusTotal, More Psychic Signatures”

A Real GPU On The Raspberry Pi — Barely.

[Jeff Geerling] saw the Raspberry Pi Compute Module 4 and its exposed PCI-Express 1x connection, and just naturally wondered whether he could plug a GPU into that slot and get it to work. It didn’t. There were a few reasons why, such as the limited Base Address Register space, and drivers that just weren’t written for ARM hardware. A bit of help from the Raspberry Pi software engineers and other Linux kernel hackers and those issues were fixed, albeit with a big hurdle in the CPU. The Broadcom chip in the Pi 4, the BCM2711, has a broken PCIe implementation.

There has finally been a breakthrough — Thanks to the dedicated community that has sprung up around this topic, a set of kernel patches manage to work around the hardware issues. It’s now possible to run a Radeon HD 5000/6000/7000 card on the Raspberry Pi 4 Compute Module. There are still glitches, and the Kernel patches to make this work will likely never land upstream. That said, It’s possible to run a desktop environment on the Radeon GPU on a Pi, and even a few simple benchmarks. The results… aren’t particularly inspiring, but that wasn’t really ever the point. You may be asking what real-world use is for a full-size GPU on the Pi. Sure, maybe crypto-mining or emulation, or being able to run more monitors for digital signage. More than that, it might help ensure the next Pi has a working PCIe implementation. But like many things we cover here, the real reason is that it’s a challenge that a group of enthusiasts couldn’t leave alone.

Continue reading “A Real GPU On The Raspberry Pi — Barely.”