Linux Rains Exploits

For tips, feedback or story suggestions, business contact: cyberinvestigationsau@gmail.com

In this episode of Cyber Investigations Australia, we break down three major cyber security stories making headlines: Copy Fail, the new Dirty Frag Linux kernel privilege escalation exploit, and the reported Canvas LMS hack linked to ShinyHunters.

We explain how Linux kernel vulnerabilities can allow attackers to escalate from a low-privileged user to root access, why page-cache corruption bugs are so dangerous, and how exploits like Dirty Pipe, Copy Fail and Dirty Frag show the risks facing Linux servers, cloud workloads and container environments.

We also examine the Canvas cyber incident, what it means for schools, universities and students, and why education platforms are becoming high-value targets for ransomware, data theft and phishing campaigns.

This episode is perfect for listeners interested in cyber security news, hacking techniques, Linux exploits, ransomware, data breaches, threat intelligence, cloud security, education sector cyber attacks, vulnerability research and incident response.

Transcript

SPEAKER_00 0:08

Welcome back to the show. Today we are covering three cybersecurity stories. If you work in cybersecurity, offensive defense defensive operations, this week felt like a lot. It was difficult to stay on top of all the seeming quote unquote, this bug has been sitting in the kernel for twenty years type headline. The first one we'll touch on is, of course, copyfail, which is a serious Linux kernel privasque vulnerability tracked as CVE 2026 31431, sorry. It affects the Linux kernel crypto subsystem and can let a normal user become root by corrupting the page cache. I think the second story I'm covering today is just a few days after that copyfail Linux vulnerability was disclosed, another local Linux Privesque issue that builds on the same family of bugs as DirtyPipe and CopyFail came out. This one uses page cache to write primitives in networking-related kernel paths, including XFRM, ESP, and RXRPC, to help attackers get root on major Linux distributions. And finally, we'll look at the Canvas Breach. Canvas is the learning management system operated across a number of a huge number of learning platforms, universities. And this one was associated with Shiny Hunters. Shiny Hunters again. Striking. Okay, so let's dive into our first story, which is CopyFail. CopyFail is a local privilege escalation vulnerability in the Linux kernel, as I mentioned. That means the attacker generally needs some level of access to the machine first. So an attacker might start at some sort of low-level privileged user, compromised web shell or a container workload. From there, um copyfail can potentially turn that limited access into root. This bug sits in the Linux kernel's cryptographic subsystem. And it's quite interesting to see how it works technically. Specifically around AFALG interface and the ALGIF AEAD module in the Linux kernel. AFALG is a socket-based interface that lets user space programs access kernel crypto functions. In simple terms, rather than every application implementing its own cryptographic operations, Linux exposes a way to ask the kernel to perform certain crypto operations. That sounds normal. However, the problem is that data moves through the kernel. So to really understand what's happening in CopyFail, we need to talk about page cache. A page cache is where Linux keeps in memory copies of file data. When a program reads a file from disk in Linux, this is often Linux often stores those files, file pages in memory so future reads are faster. So if you run a common system binary like SU or sudo or another privileged tool, the data backing that executable may be served from the page cache. CopyFail allows an unprivileged user to perform a small controlled write into page cache-backed file data. Several write-ups describe this as a controlled four-byte write into a page cache of a readable file. So that four-byte write sounds small. But for the offensive hackers out there, we know four bytes is enough for you to work with. So these four bytes, if an attacker can modify the in-memory copy of the set UID binary, they may not need to change the actual file on disk. They're corrupting the cached version in memory. Another thing that matters in this copy fail vulnerability is that it's being reported as being deterministic. Some kernel exploits rely on race conditions where an attacker has to win a timing window. That can make exploitation unreliable. But reports on copy fail describe it as a logic flaw that does not rely on a race window, making it reliable. This is hacker gold, basically. So from a defender's perspective, this is very difficult to defend against because it combines three dangerous properties. One, it affects virtually all major Linux distributions. So you're not escaping from it. It has a public proof of concept exploit code. So, you know, script kitties all the way up to nation-state hackers are currently using it. That's safe to assume. And finally, it can turn the low-level access into a root. So all the way up to local prevesque. Very bad. If you're a system admin out there, or if you're just a listener and uh want to know if your system admins have patch or what they can do, the proper fix is to patch the kernel and reboot into the fixed version. Kernel patching is not just installing the package. The system usually needs to boot into the patched kernel. In some environments, live patching may help. But organizations still need to confirm the vulnerable path is actually remediated. So go in and check for potential IOCs is what I would suggest. Some mitigation guidance is also focused on disabling or restricting the vulnerable ALGIF AEAD path to another possibility if you're a system admin. But this is where the story gets worse because mere days after copy fail was reported, 20-year-old Linux kernel bunk, another Linux vulnerability was disclosed. The second story that I want to touch on today is basically part B to copy fail. Dirty Frag is the name of the second major Linux exploit that was disclosed this week. And it is important because uh Dirty Frag is showing that attackers and researchers are now exploring a broader class of page cache corruption bugs. So uh I've been reading the the Hacker News report, and it's been reported as a local privilege escalation escalation, rather, vulnerability impacting the Lunus kernel, uh, described by a researcher Xuang Wu Kim as the successor to copy fail. Dirty Frag changed two page cache write vulnerabilities. Uh so it's effectively two vulnerabilities wrapped up in one, the first being XFRM ESP path, and the other is RXRPC. So let's unpack both of these. First, XFRM is part of the Linux and networking stack used in IPsec processing, if you've never heard of it. Uh IPsec is commonly used for encrypted network traffic, especially in VPN style use cases. ESP, which is abbreviated the abbreviation for encapsulating security payload, is the part of IPsec that provides confidentiality and integrity for packets moving in and out of the Linux kernel. Now the other component of a dirty frag is RXRPC. Now, RXRPC is a remote procedure call mechanism stored in some Linux environments. It is not something that most everyday users think about. So if you haven't heard of RXRPC, you are forgiven. So let's tie this all up in a bow. DirtyFrag is a combination of those two process change chains tied together. And Dirty Frag targets how the kernel handles page fragments of data effectively. So to give more information to that, modern Linux is highly optimized. Instead of copying data around unnecessarily, the kernel uses mechanisms like splice and send file and page back buffers to move data efficiently. Now, normally these performance optimizations like splice and send file are a good thing. But security bugs often appear where optimization meets ownership confusion confusion, rather. In Dirty Frag, the issue is that certain receive or decryption paths can operate directly over pages that are not privately owned by the kernel. What does that mean? That means that this can expose or corrupt memory that an unprivileged process still has a reference to. Olema Linux explanation described the issues as involving socket buffers carrying page fragments that are not privately owned by the kernel, where in-place description can affect externally backed pages. Okay. This has been a mouthful. So in plain English, the kernel thinks it is safely processing networks or crypto data, but with dirty frag, the memory backing that the data may still be connected to page cache backed content in a way that the attacker can influence. That creates another page cache write primitive. A write primitive is effectively the holy grail for offensive operations. It means the attacker has found a way to write control data somewhere they should not be able to write. Even if it is only a few bytes that can be chained into privileged escalation. Okay. Third story and final story I'm going to touch on today is the Canvas hack. Wow. Canvas is you I I didn't really appreciate the amount of universities and learning institutes that Canvas was in. A hack is big when your your main news providers start talking about the hacks that have happened. I think it's important to understand the Canvas incident is not just about one company. It's about the concentration of sensitive student data inside education platforms. Infrastructure, the company behind Canvas, said it experienced a cybersecurity incident involving data for users at affected institutions. According to its incident update reported by WIR, the exposed information includes names, email addresses, student ID numbers, and messages exchanged by users on the platform. Wow, that's not good. Also, other reporting has stated that there is no evidence that passwords, dates of birth, government IDs, financial information were involved. But even without those fields, this is not not great. So thankfully, they didn't get to the crown jewels of information, but they certainly did get some. Again, in in the Wyard story that I've written about this attack, Wide noted that it is unclear who exactly is operating behind the name in this instance because cybercrime brands are often reused. Yeah, so I think that will wrap up my show today. Thank you very much for listening. Please drop a comment or question in my comment section in Spotify or Apple Podcasts, and I look forward to seeing you next time. Cheers.