Up first is Zenbleed, a particularly worrying speculative execution bug, that unfortunately happens to be really simple to exploit. It leaks data from function like strlen, memcpy, and strcmp. It’s vulnerable from within virtual machines, and potentially from within the browser. The scope is fairly limited, though, as Zenbleed only affects Zen 2 CPUs: that’s the AMD Epyc 7002 series, the Ryzen 3000 series, and some of the Ryzen 4000, 5000, and 7020 series of CPUs, specifically those with the built-in Radeon graphics.

And at the heart of problem is a pointer use-after-free — that happens inside the CPU itself. We normally think of CPU registers as fixed locations on the silicon. But in the case of XMM and YMM registers, there’s actually a shared store of register space, and the individual registers are mapped into that space using a method very reminiscent of pointers.

XMM registers are 128 bits long, and YMM registers are 256 bits long. As a performance optimization, compilers often use the vzeroupper instruction to set the upper half of a YMM register to 0, letting the CPU run the rest of the instructions using 128-bit calculations. The important thing to understand is that the underlying memory isn’t set to zero, but the pseudo-pointer is just flagged as equaling zero.

Now here’s the speculative execution: The CPU executes code ahead of time that includes a vzeroupper. If the CPU guesses wrong, it rolls back the execution, including that vzeroupper instruction, but the underlying storage may have already been assigned to one of the other XMM registers. The data is still there, and can simply be read back from the register. Note, this isn’t a side-channel attack, the data is just there, ready to be accessed.

What’s interesting is the sorts of data that is found in those registers. Modern compilers use these vector processing instructions for some essential functions, like strcmp, memcpy, and srtlen. Those routines deal with keys, passwords, log messages, and more.

I tested this on my server, powered by an AMD 7302P, and confirmed that from within a virtual machine, the proof of concept code was able to access log messages from the bare-metal Alma Linux install. That’s really not good. Thankfully, AMD has published a microcode patch for these server series processors, and AlmaLinux has made that patch available. I did repeat the test after installing, and the microcode patch does indeed shut down the data leak.

What about desktop and mobile chips? Well unfortunately, those updates aren’t out yet, and don’t have a target date until later this year — December in the worst case. It appears that the server patch from AMD came way ahead of schedule and let the cat out of the proverbial bag, explaining the less than coordinated disclosure we’re seeing.

Google’s Web Environment Integrity

The Internet is up in arms over a project at Google to add Web Environment Integrity (WEI) to Google Chrome. The purpose of the WEI proposal is spelled out in the draft specification. It allows a website to have confidence that a connection is coming from a real user, and a validated web environment, without violating that user’s privacy by fingerprinting them.

The way this would work is through attestation, where a trusted third party has access to the browser, and then attests that it is approved. This seems to be essentially an anti-cheat scheme, or another layer of DRM. Which is where we get into the weeds of possibly being a terrible idea.

This is the argument made by Vivaldi, there is no guarantee this new system won’t be terribly abused to keep other browsers out of the marketplace. And whither Linux? Anti-cheat measures have been very difficult to implement in a sane way on Linux. If the standard takes off, will Linux browsers just be locked out of the fun? Is it a better world when third parties get to determine the software you are allowed to run? It’s fair to say that we have more questions than answers.

Ubuntu’s Overlay

In a bit of research cleverly named “Game Over(lay)”, [Sagi Tzadik] and [Shir Tamari] of Wiz describe a flaw they found in Ubuntu‘s patches on top of OverlayFS. The short version is that the Linux kernel had a vulnerability in the OverlayFS kernel module in 2020. Fixes were added to the vfs_setxattr function, but Ubuntu exposes more functionality by skipping this function, and directly calling __vfs_setxattr_noperm. Because of the Ubuntu-specific changes, the fixes in the upstream kernel are bypassed in Ubuntu’s kernels.

The exact issue is the ability to set file capabilities. setcap is the newer, better approach to the setuid bit, which allows an unprivileged user to run a binary with greater capabilities. Take a look at fping:
[jbennett@Celeborn Downloads]$ getcap /usr/sbin/fping
/usr/sbin/fping cap_net_raw=ep

The key to making that secure is that only root can assign capabilities. Except inside container filesystems, where the process of building them sometimes requires file capabilities. The unprivileged user can launch a new namespace and create the more capable executable in the “lower” directory. Where this goes wrong is when the OverlayFS filesystem is mounted, and the executable gets touched. The system makes a copy of the file, to the “upper” half of the OverlayFS, but that copy exists outside the created namespace, escaping the sandbox.

The estimate is that almost 40% of Ubuntu installs are vulnerable to this exploit. Thankfully it’s a local-only escalation of privilege flaw. It’s still quite a menace as part of an attack chain, so go forth and patch!

Bits and Bytes

The Spring Java framework has an issue in the WebFlux component, where a double asterisk ** pattern can hit an edge case in the security coverage, potentially allowing for security bypass. It clocks in at a CVSS 9.1 base score, and 8.8 overall.

And finally, don’t miss our coverage of the intentional weakness in the TETRA radio standard. The whole story reminds me quite a bit of Operation Rubicon, where Crypto AG shipped similarly compromised devices under the direction of the US and German governments.