Microsoft is racing to get into the AI game as part of Windows 11 on ARM, calling it Copilot+. It’s an odd decision, but clearly aimed at competing with the Apple M series of MacBooks. Our focus of interest today is Recall, a Copilot+ feature that not only has some security problems, but also triggers a sort of visceral response from regular people: My computer is spying on me? Eww.

Yes, it really sort of is. Recall is a scheme to take screen shots of the computer display every few seconds, run them through character recognition, and store the screenshots and results in a database on the local machine hard drive. There are ways this could be useful. Can’t remember what website had that recipe you saw? Want to revisit a now-deleted tweet? Is your Google-fu failing you to find a news story you read last week? Recall saw it, and Recall remembers. But what else did Recall see? Every video you watched, ever website you visited, and probably some passwords and usernames you typed in.

Now to their credit, the folks at Microsoft knew this could be a problem, and took some steps to keep this data safe. The huge win here is that Windows 11 with Copilot+ will run an Azure AI instance right on the laptop, to do all the AI processing without sending any private data up to the cloud. And then on top of that, Recall data is encrypted at rest, which Microsft claims is enough to keep attackers and other users out. The problem there is that encryption at rest only protects data from a physical, offline attack. And even that is incredibly hard to get right.

So let’s cut to the chase. How bad is it? [Kevin Beaumont] took a look, and the results aren’t pretty. The description sounded like Recall uses a per-user encryption system like EFS to keep the data safe. It’s not. Any admin user can access all the Recall databases on the machine. And of course, malware that gets installed can access it too. There’s already a tool available to decode the whole database, TotalRecall.

Recall is only planned to run on these Copilot+ devices, and can be turned off by the end user. Some of the security problem can be fixed, like the cross-user availability of the data. It’s going to be much harder to fix the privacy and malware issues.

Modem Mystery

This is sort of a two-part story, starting with a real mystery. [Sam Curry] was doing some research on a vulnerability, and noticed something odd when sending HTTP requests from his home network to a test server. Each HTTP request was sent a second time, from a separate IP address. That’s odd. A bit of investigation discovered that these were HTTP packets that were sent through his cable modem, and the mystery IP was a DigitalOcean VM. The culprit was a compromised cable modem, but it’s still an open mystery, what exactly the purpose was of mirroring HTTP traffic this way. [Sam] went to his cable company to request a new modem, and turned the compromised unit over in the exchange, ruining his chance to figure out exactly what was on it.

The second part of this story is that curiosity about exactly how malware ends up on a modem eventually led [Sam] down the rabbit hole of Cox APIs and TR-069, the protocol that allows an ISP to manage devices at scale. The Cox API used a reverse proxy that could be tricked into showing a Swagger-ui page, nicely documenting all the API endpoints available. That API had a quirk. Send the same request multiple times, and it’s eventually accepted without authorization. That was the motherload, allowing for arbitrary access to customer devices via the TR-069 support.

So mystery solved? Was this how [Sam]’s modem was hacked? Cox responded very rapidly to the vulnerability report, closing the problematic APIs within hours. But the vulnerability just wasn’t old enough. The original modem malware was in 2021, and this API didn’t launch til 2023. The mystery continues.

Linux Flipping Pages in the Wild

CISA has added another two vulnerabilities to the their list of known-exploited. One is the Check Point arbitrary file leak that we covered last week, and the other is the Flipping Pages vulnerability in the Linux kernel, made public back in March, with the fix predating the announcement, in February.

The core bug itself is pretty simple. A NetFilter chain in the kernel can return one of multiple values, to indicate how to handle an incoming packet. The NF_DROP target drops the packet, frees the memory, and returns a user-supplied error value. The quirk here is that errors are negative values, and the rest of the NetFilter actions are positive values. And NetFilter allows a user to set that error value as a positive value, enabling an odd state where the packet is both dropped and accepted at the same time. The specific bug is a double free, which enables the Dirty Pagetable technique to overwrite arbitrary memory and trigger elevation.

That vulnerability became more important to get patched, once a Proof of Concept (PoC) was published, allowing for easy use. And it’s apparently getting used, given the CISA announcement.

Binding Android

Up next is a nice walk-through of an Android vulnerability making use of the Binder Inter-Process Communication (IPC) device. As all the apps on Android run sandboxed, Binder is both an important part of the OS, and very accessible to apps — and hence not a good place for a vulnerability.

On the other hand, Binder is fairly complicated. It’s doing memory management, connects multiple processes, transferring arbitrary data, and just generally has a difficult dance to do. It’s not surprising that there are vulnerabilities in that code. This one is a logic flaw in error handling, where an error can trigger the cleanup function to clean up unallocated objects. That results in a dangling pointer, which can be used for all sorts of things.

The first step in actual exploitation is to use the dangling pointer to leak a few bytes from kernel heap memory. That data can be used to build a fake binder object in the space, and then a delete function called on that fake object results in an “unlink”, or a way to modify kernel pointers. That unlink can be abused to build an arbitrary read primitive, by unlinking a fake pointer. The last trick is a cross-cache attack, where multiple objects are created and freed, to trick the allocator into putting something important under the dangling pointer. Putting it together, it allows a process to overwrite it’s own credentials struct, setting ID to root.

Make it a 9.8

When a company typos their latest CVE score, reporting it a full point worse than it is, what’s a researcher to do? In this case, put the time in to find a way to make the severity rating worth it. It’s a Remote Code Execution in the Progress Report server. The initial vulnerability report listed it as a post-authentication RCE.

The report server takes reports, and turns it into pretty graphs and charts. Those reports are in the form of a serialized stream. And yes, the flaw is a deserialization attack, a ridiculously deep chain that finally ends in loading an arbitrary .NET type, which leads easily to a process start command.

The vulnerability requires some sort of authenticated user to trigger. We’re looking for pre-auth exploitation here. How about a first-run endpoint that doesn’t have any authentication code applied, and doesn’t go away after the server is configured. It’s not the first software to fall to this trap, and won’t be the last.

Bits and Bytes

The Chrome Root Store is kicking out a trusted Certificate Authority. It doesn’t happen often, but one of the tools to keep CAs behaving is the threat of removing them the browser certificate store. “e-commerce monitoring GmbH” has been trusted for right around three years, and was fraught with problems from the very beginning.

Tavis has the rest of the Libarchive story. Why does Libarchive implement the RarVM, and why did Rar use a bytecode VM? Historical reasons.

The libarchive e8 vulnerability is actually really cool, but the ZDI advisory doesn't explain why it's so wild lol. For some reason, I know about RAR filters, so let me provide the background. 🧵 1/n

— Tavis Ormandy (@taviso) June 6, 2024

The Internet Archive is under attack by a Distributed Denial of Service attack (DDoS). It’s unclear exactly where the attack is coming from, but it is making the archive and the Wayback machine a bit spotty to access these days. And as the post says, it’s not just cyber-bullies trying to mess with our favorite library.

Extra Credit: Crypto is hard. This one takes a bit of time to work through and understand, but the gist is that one of NIST’s cryptography recommendations had a bit of an oversight in it. The scenario is that Alice and Bob both provide key material to produce an agreed upon shared key. When one party gets to pick some of the initialization data, as well as one of the keys used for this multi-key system, careful selection can lead to way too much control over the final produced key. The example given is an encrypted message app, that has a sneaky backdoor. This was discovered, never actually implemented that anyone knows of, and has been fixed in the NIST recommendation.