CPU vulns, LoopDOS, AI worms and Bad Bots - March 18th - 24th - This Week in Security
Editor's introduction
Aaron back with you as editor this week, and I'm going to look at a few of the interesting pieces of secrurity news from the week just gone - the good news is, there was a lot of interesting news! The bad news is, that interesting news usually means more work for us all... allow me to walk you through a few of the interesting things I saw this week and give you my take on what their real-world impact is going to be to us all.
We in F5 SIRT invest a lot of time understanding the frequently changing behavior of bad actors. Bad actors are a threat to your business, your reputation, and your livelihood. That’s why we take the security of your business seriously. When you’re under attack, we’ll work quickly to effectively mitigate attacks and vulnerabilities, and get you back up and running. So next time you are under security emergency please contact F5 SIRT.
Processor architecture back in the news
First up; processor architecture and vulnerabilities are back in the news again! In the last week we have seen at least three new processor vulnerabilities disclosed - the first two, GhostRace and IPI, both impact all (or most, at least) processor architectures; x86, ARM, RISC-V etc, and deal with exploiting speculative race conditions. In other words, they are a lot like Spectre & Meltdown (there's a great lightboard session if you need a reminder of that research from 2018). GhostRace (CVE-2024-2193) deals with bypassing of synchronization primitives - that is, code designed to prevent multiple threads from trampling on a common resource - like mutexes and spinlocks by using a Spectre-v1 attack on the speculative execution paths. The research was undertaken specifically on Linux although it is quite likely (at least in my opinion) that other operating systems will be similarly affected, but at least on Linux the research showed that the Linux kernel itself is vulnerable to this style of attack.
IPI Storming (CVE-2024-26602) is the second half of the complete attack demonstrated in the paper(s); because successful exploitation requires the attacker to win a race condition, exploitation would be most successful if winning that race could be guaranteed. That's where IPI Storming comes in. IPI stands for Inter-Process Interrupt, and the researchers found they could indefinitely 'pause' the victim process by flooding the CPU core it is executing on with interrupts. This allows the attacker to pause the victim process while it is within it's 'race' window (how much of a race is it if the other competitor isn't moving, though) and carry out an infinite number of Speculative Concurrent Use-After-Free attempts. Once successful this attack can leak memory from a target process or, indeed, the Linux kernel at a rate of 12KB/s.
As with Spectre, Meltdown and most other hardware-level vulnerabilities that we have seen, the only real mitigation here is to ensure you never run untrusted code on your systems. While there is partial mitigation being added to the Linux kernel for CVE-2024-26602, completely mitigating these issues would reduce processor and operating system performance so significantly as to be improbable. Most (if not all) processor vendors have responded that the mitigations for GhostRace are idenitcal to those for Spectre v1, in fact. That said, the researchers suggest only a 5% performance overhead for their suggested mitigations, albeit in synthetic benchmarks. Despite that assertion I don't believe we'll see widespread adoption of kernel-level or microarchitecture level fixes for this or any other similar vulnerabilities; simply put, we are too addicted to the performance boost speculative execution gives us in modern processors.
Just in case Apple were feeling left out with the focus here being on x86 and Linux, we also saw GoFetch published last week. This flaw is specific to Apple's M1, M2 and M3 silicon and can allow an attacker access to cryptographic keys, allowing them to access encrypted files or any other data protected by those keys. Once again the research deals with exploiting speculative predictions - in this case we aren't predicting branches in code (as per Spectre) but rather the processor's Data Memory-dependent Prefetcher (DMP) tries to predict which memory address the running code is going to request next so that it can be pre-fected into cache to improve performance. Apparently sometimes, however, the DMP gets the addresses mixed up with the contents of those addresses, and the attacker can then use cache side channels to guess parts of a cryptograhic key until they've recovered the entire key, and the entire attack can be carried out by unprivileged code running as a regular user.
All of the suggested fixes impact performance in some way (did I mention we are addicted to performance, already?) though they have suggested mitigations that might be acceptable to the average user such as pinning cryptographic functions to the "efficiency" cores (which lack DMP functionality) or disable DMP when running security critical applications, leaving it available for performance-focused applications. But, as with the other issues we've talked about today, what manufacturer wants to reduce performance when performance benchmarks are one of the very things they rely on to differentiate themselves from the competition - especially for Apple, who leaned heavily into their roots of media production with the M-silicon and saw huge performance gains (talking to AubreyKingF5 , This Month in Security editor and vidographer extraordinaire, I know that a 4k video which previously took 4 hours to render on his 12 core Intel Macbook now takes 20 minutes thanks to the M-silicon - or, as he put it: "I used to have to set my videos to render overnight. Now, I go get a cup of decaf and it’s done when I’m back."). Would they really want to give any of that up, or push the responsibility back to the user under the guise of "don't run untrusted code"?
- https://www.vusec.net/projects/ghostrace/
- https://www.macworld.com/article/2276399/gofetch-flaw-m1-m2-m3-processor-cryptographic-performance.html
Packet goes in, packet goes out, packet goes in, packet goes out..
If you've worked in the networking space for any amount of time, you've probably created a routing or bridging loop at least once in your career, right? Just me? Oh.. I jest, but at least when trying to reproduce parts of complex environments in the lab, it is (in my experience, anyway!) rather easy to accidentally create a loop and have no spanning tree or other mitigations in place and you can quickly take down an entire switching infrastructure - honestly, I have done it more than once although it has, thankfully, been a while. We see them in the F5 SIRT, too; sometimes what presents as a world-ending Distributed Denial of Service (DDoS) turns out to actually be a loop between devices or within a single device, and that storm of traffic was simply a device talking back to itself as fast as it possibly could.
Well, enter LoopDOS. I'm going to say something perhaps contraversial here; LoopDOS should not come as a surprise to any of us. At it's core, LoopDOS simply states that (I'm paraphrasing) "The UDP protocol lacks any protection against IP spoofing, this allows an attacker to spoof the source IP on malicious traffic directed to Victim A and have the responses sent to Victim B" and this is not really news. In fact that is the core of many well understood (and well used!) attacks like DNS amplification where a small request from the attacker sends a large response from a target DNS server back to the ultimate victim; what's new in LoopDOS, however, is that the researchers have identified a number of UDP-based services which can be exploited such that a single packet from the attacker will cause Victim A and Victim B to talk to each other forever, importantly, the vulnerable services included some very common services like DNS and NTP (plus TFTP, though I think it is fair to say that TFTP is less widely exposed to the Internet than DNS and NTP!). They also demonstrated that legacy services such as QOTD, Chargen, Echo, Time, Daytime and Active Users were vulnerable to the same attack and linked to an old advisory from 1996, CA-1996-01 and honestly this is where I start to have a problem..
CA-1996-01 describes exactly what LoopDOS describes - and it described it 28 years ago. The advice in CA-1996-01 and LoopDOS is also largely the same - be very careful when you expose UDP services, don't expose legacy UDP services like chargen and echo (also widely documented as amplification vectors already) monitor traffic and implement rate limiting mechanisms to prevent a complete denial-of-service should a loop occur (the LoopDOS authors also recommend migrating to TCP where possible); so AFM's L4DOS protections are your friend, here.
I'm not discounting the usefulness or validity of the researcher, but giving it a catchy name and all the press coverage it's received seems too much for what is a fundamental part of a protocl which has existed for 40 years, and describing a flaw first described nearly 30 years prior. Still, here I am, adding to the news coverage..
- https://cispa.de/en/loop-dos
- https://vuls.cert.org/confluence/display/historical/CERT+Advisory+CA-1996-01+UDP+Port+Denial-of-Service+Attack
AI worms
No, not the ones in the video game, but the kind that infiltrate computer systems and do damage or steal data. Let's talk about ComPromptMized! My first thought was that this was another piece of research on using generative AI to create malware but no - in fact, this is malware that targets generative AI powered applications like email assistants to coerce those assistance into taking malicious action like sending spam or exfiltrating the legitimate user's data. This is far more intriguing to me than the news we've seen in past months about GenAI writing polymorphic malware; this is bascially automated AI prompt-engineering which could be done at-scale to quietly subvert existing infrastructure (such as email) to very quietly exfiltrate data. That's much harder to detect than a new piece of malware trampling across systems (IMHO) as the exfil channel is legitimate, expected, activity. Once again the only mitigation I can really think of is tightly controlling what software is allowed to run on endpoint devices - ensure users can't download arbitrary executables, white-list only known approved software and so on (of course, antivirus/antimalware/etc tooling has a role to play, but that is shown to be routinely bypassed). As a user, I don't really want to see draconian lockdowns on devices but, as a security professional, I can feel it coming..
More Bad Bots
While we are on the topic of malware, I'd like to reference an article that is from slightly outside of "my week" and point everyone to F5 Labs' 2024 Bad Bots Review published March 14th. This is a great drill down into the kinds and amounts of bot traffic mobile APIs and web applications are seeing in the real world, trends across industry verticals (healthcare and hospitality being the leaders in the charts for web traffic, while entertainment leads the way for mobile APIs) as well as across functionality (e.g., search & giftcards are most often automated). It's a 15 minute read and, in my opinion, well worth giving the time to! Of course if (and when) you find yourself on the receiving end of bot traffic, as most sites will at some point, F5 Distributed Cloud Bot Defense can help, as can the F5 SIRTs Emergency Security Response Process if you would rather mitigate using on premise solutions!