A tale of two privilege escalation bugs

Why Copy Fail is a bigger deal than PhantomRPC

I generally don’t get excited about privilege escalation vulnerabilities on workstations. Infostealers can vacuum up all sorts of credentials and sensitive files without escalating privileges, and it’s possible to laterally move throughout the environment without root or SYSTEM.

On Windows, if an attacker has any interactive access to the system, it belongs to the attacker. There might be folks out there who have figured out how to harden Windows to a point where this isn’t true, but the average Windows system is toast as soon as an attacker has a foothold. BYOVD is just one option on the table if attackers do need to escalate their privileges on Windows.

For these reasons, I didn’t get very excited about PhantomRPC and didn’t plan to write about it.

Then Copy Fail dropped.

Photo by Niklas on Unsplash

This is how you write a vulnerability disclosure

Wow. WOW. This writeup has it all. Check it out and come back here - I’m not going to repeat too much of it and they’ve earned your eyeballs with this excellent post.

1. Description of the vulnerability: 10/10

2. Technical Description: n/a (beyond my understanding, but I imagine it’s as good as the rest)

3. General Description: 10/10

4. Context and relevance

5. Fix included (wow!)

6. Explains the history of how it got there (nice!)

7. Explains how to mitigate if you can’t patch (WOWOWOW)

8. They explain how they found it (excellent!)

9. It’s also nice to see that the Linux kernel folks responded within a day and by day 2 were reviewing potential patches

Unless I missed something, the only thing missing is the exploit itself, which is understandable, given that today is disclosure day and folks need time to patch.

AI

Yes, AI played a part in finding this. I’m noticing a trend. It’s looking like expert-assisted AI will be a common combination in vulnerability discovery from now on. AI can find bugs in the hands of novices, but they’re generally not very interesting bugs based on what came out of Anthropic’s Mythos (more on this in the post below).

Even when interesting bugs were found, like the RCE in FreeBSD, an expert was necessary to get to a working exploit.

I mentioned that Xint didn’t release the 732 byte exploit. I’d be surprised if someone hasn’t taken the technical details from the writeup and the patch, and vibe-coded a working exploit by now. This is the speed of exploit development today - working exploits the day the patch is released.

I want to really stress this again.

I’d be surprised if someone hasn’t vibe-coded a working exploit by now.

Linux Yikes, Windows Yawn?

The main reason why privilege escalation is so much more concerning in Linux is due to where Linux is used.

Everywhere.

Including in multiuser and multi-tenant situations where organizations are serving untrusted parties. Kubernetes, containers, every SaaS, every PaaS, IaaS. Every cloud, hyperscaler, code hosting platforms, and AI service has Linux running beneath it. Some network infrastructure and most IoT devices also run Linux. Every supercomputer is basically one big multi-tenant shell server.

Cloud providers, probably not worried

In the cases where untrusted customers are intentionally handed a shell, privilege escalation vulnerabilities are anticipated and part of every threat model. Folks at AWS, GCP, and Azure probably aren’t scrambling too much today - they expect vulns like this to occasionally drop and their whole business model depends on dealing with days like today.

Unlike cloud and hosting providers, supercomputers aren’t just handing shells to random folks off the street. Control is a bit tighter and folks are generally vetted before being given access. I imagine that any attempt to exploit a privesc vuln would get you booted and banned rather quickly. With that said, it seems likely that all the flavors of Linux that run on supercomputers would be vulnerable to this.

AI platforms, apps, and agents on the other hand…

These new AI services and platforms popping up left and right, however - I wouldn’t be surprised if some of them are less prepared. Add the risk of prompt injection to the lists of ways we could see this vulnerability get exploited. This is where I’d look for any fallout from this vulnerability.

Who else should be concerned?

If you’re on this list, you could be a juicy target for ransomware crews. Ransomware teams like being able to reuse vulnerabilities to get access to multiple victims, and organizations that are large enough to pay a 5-7 digit ransom, but small enough to not have a security team are often the sweet spot these criminal groups go after.

• Low cost web hosting companies that give customers shell access might be scrambling.

• There are all sorts of niche hosting services for gaming as well. Minecraft is a particularly large one - anyone running Pterodactyl should probably patch quickly.

• Free shell providers (yes, these still exist)

• CI/CD runners

• Anyone running online IDE/sandbox/notebook services (e.g. Jupyter) should check for impact here. I don’t know a ton about how these services work, so I can’t say with certainty how much they’d be affected.

• CTF (capture the flag) services often give access to shells. Since they’re literally designed for hacking, I’d think there would be extra measures to address unknown privilege escalation bugs… right?

• With the exploit requiring only 732 bytes, I wouldn’t be surprised to see ClickFix attacks leveraging this vulnerability and targeting software engineers and the general public.

• Any systems running Linux with services that might have unpatched command injection vulnerabilities (edge devices, I’m looking at you) might have a bad day.

If you didn’t read the Xint post and you’re wondering how to remediate this, go back and give it a look - patching isn’t the only option. Seccomp and blocking the affected module can both mitigate exploitation. This is also just part 1 from Xint - they promise to share container escapes next.