Spectre lives. We’ve got two separate pieces of research, each finding new processor primitives that allow Spectre-style memory leaks. Before we dive into the details of the new techniques, let’s quickly remind ourselves what Spectre is. Modern CPUs use a variety of clever tricks to execute code faster, and one of the stumbling blocks is memory latency. When a program reaches a branch in execution, the program will proceed in one of two possible directions, and it’s often a value from memory that determines which branch is taken. Rather than wait for the memory to be fetched, modern CPUs will predict which branch execution will take, and speculatively execute the code down that branch. Once the memory is fetched and the branch is properly evaluated, the speculatively executed code is rewound if the guess was wrong, or made authoritative if the guess was correct. Spectre is the realization that incorrect branch prediction can change the contents of the CPU cache, and those changes can be detected through cache timing measurements. The end result is that arbitrary system memory can be leaked from a low privileged or even sandboxed user process.

In response to Spectre, OS developers and CPU designers have added domain isolation protections, that prevent branch prediction poisoning in an attack process from affecting the branch prediction in the kernel or another process. Training Solo is the clever idea from VUSec that branch prediction poisoning could just be done from within the kernel space, and avoid any domain switching at all. That can be done through cBPF, the classic Berkeley Packet Filter (BPF) kernel VM. By default, all users on a Linux system can run cBPF code, throwing the doors back open for Spectre shenanigans. There’s also an address collision attack where an unrelated branch can be used to train a target branch. Researchers also discovered a pair of CVEs in Intel’s CPUs, where prediction training was broken in specific cases, allowing for a wild 17 kB/sec memory leak.

Also revealed this week is the Branch Privilege Injection research from COMSEC. This is the realization that Intel Branch Prediction happens asynchronously, and in certain cases there is a race condition between the updates to the prediction engine, and the code being predicted. In short, user-mode branch prediction training can be used to poison kernel-mode prediction, due to the race condition.

(Editor’s note: Video seems down for the moment. Hopefully YouTube will get it cleared again soon. Something, something “hackers”.)

youtube.com/embed/jrsOvaN7PaA?…

Both of these Spectre attacks have been patched by Intel with microcode, and the Linux kernel has integrated patches for the Training Solo issue. Training Solo may also impact some ARM processors, and ARM has issued guidance on the vulnerability. The real downside is that each fix seems to come with yet another performance hit.

Is That Real Cash? And What Does That Even Mean?

Over at the Something From Nothing blog, we have a surprisingly deep topic, in a teardown of banknote validators. For the younger in the audience, there was a time in years gone by where not every vending machine had a credit card reader built-in, and the only option was to carefully straighten a bill and feed it into the bill slot on the machine. Bow how do those machines know it’s really a bill, and not just the right sized piece of paper?

And that’s where this gets interesting. Modern currency has multiple security features in a single bill, like magnetic ink, micro printing, holograms, watermarks, and more. But how does a bill validator check for all those things? Mainly LEDs and photodetectors, it seems. With some machines including hall effect sensors, magnetic tape heads for detecting magnetic ink, and in rare cases a full linear CCD for scanning the bill as it’s inserted. Each of those detectors (except the CCD) produces a simple data stream from each bill that’s checked. Surely it would be easy enough to figure out the fingerprint of a real bill, and produce something that looks just like the real thing — but only to a validator?

In theory, probably, but the combination of sensors presents a real problem. It’s really the same problem with counterfeiting a bill in general: implementing a single security feature is doable, but getting them all right at the same time is nearly impossible. And so with the humble banknote validator.

Don’t Trust That Phone Call

There’s a scam that has risen to popularity with the advent of AI voice impersonation. It usually takes the form of a young person calling a parent or grandparent from jail or a hospital, asking for money to be wired to make it home. It sounds convincing, because it’s an AI deepfake of the target’s loved one. This is no longer just a technique to take advantage of loving grandparents. The FBI has issued a warning about an ongoing campaign using deepfakes of US officials. The aim of this malware campaign seems to be just getting the victim to click on a malicious link. This same technique was used in a LastPass attack last year, and the technique has become so convincing, it’s not likely to go away anytime soon.

AI Searching SharePoint

Microsoft has tried not to be left behind in the current flurry of AI rollouts that every tech company seems to be engaging in. Microsoft’s SharePoint is not immune, and the result is Microsoft Copilot for SharePoint. This gives an AI agent access to a company’s SharePoint knowledge base, allowing users to query it for information. It’s AI as a better search engine. This has some ramifications for security, as SharePoint installs tend to collect sensitive data.

The first ramification is the most straightforward. The AI can be used to search for that sensitive data. But Copilot pulling data from a SharePoint file doesn’t count as a view, making for a very stealthy way to pull data from those sensitive files. Pen Test Partners found something even better on a real assessment. A passwords file hosted on SharePoint was unavailable to view, but in an odd way. This file hadn’t been locked down using SharePoint permissions, but instead the file was restricted from previewing in the browser. This was likely an attempt to keep eyes off the contents of the file. And Copilot was willing to be super helpful, pasting the contents of that file right into a chat window. Whoops.

Fuzzing Apple’s CoreAudio

Googler [Dillon Franke] has the story of finding a type confusion flaw in Apple’s CoreAudio daemon, reachable via Mach Inter-Process Communication (IPC) messages, allowing for potential arbitrary code execution from within a sandboxed process. This is a really interesting fuzzing + reverse engineering journey, and it starts with imagining the attack he wanted to find: Something that could be launched from within a sandboxed browser, take advantage of already available IPC mechanisms, and exploit a complex process with elevated privileges.

Coreaudiod ticks all the boxes, but it’s a closed source daemon. How does one approach this problem? The easy option is to just fuzz over the IPC messages. It would be a perfectly viable strategy, to fuzz CoreAudio via Mach calls. The downside is that the fuzzer would run slower, and have much less visibility into what’s happening in the target process. A much more powerful approach is to build a fuzzing harness that allows hooking directly to the library in question. There is some definite library wizardry at play here, linking into a library function that hasn’t been exported.

The vulnerability that he found was type confusion, where the daemon expected an ioctl object, but could be supplied arbitrary data. As an ioctl object contains a pointer to a vtable, which is essentially a collection of function pointers. It then attempts to call a function from that table. It’s an ideal situation for exploitation. The fix from Apple is an explicit type check on the incoming objects.

Bits and Bytes

Asus publishes the DriverHub tool, a gui-less driver updater. It communicates with driverhub.asus.com using RPC calls. The problem is that it checks for the right web URL using a wildcard, and driverhub.asus.com.mrbruh.com was considered completely valid. Among the functions DriverHub can perform is to install drivers and updates. Chaining a couple of fake updates together results in relatively easy admin code execution on the local machine, with the only prerequisites being the DriverHub software being installed, and clicking a single malicious link. Ouch.

The VirtualBox VGA driver just patched a buffer overflow that could result in VM escape. The vmsvga3dSurfaceMipBufferSize call could be manipulated so no memory is actually allocated, but VirtualBox itself believes a buffer is there and writable. This memory write ability can be leveraged into arbitrary memory read and write capability on the host system.

And finally, what’s old is new again. APT28, a Russian state actor, has been using very old-school Cross Site Scripting (XSS) attacks to gain access to target’s webmail systems. The attack here is JavaScript in an email’s HTML code. That JS then used already known XSS exploits to exfiltrate emails and contacts. The worst part of this campaign is how low-effort it was. These aren’t cutting-edge 0-days. Instead, the target’s email servers just hadn’t been updated. Keep your webmail installs up to date!

hackaday.com/2025/05/16/this-w…