This Week In Security: Malicious Rollback, WHOIS, And More

It’s time to talk about Microsoft’s patch Tuesday, and the odd vulnerability rollback that happened. CVE-2024-43491 has caught some attention, as it’s a 9.8 on the CVSS scale, is under active exploitation, and results in Remote Code Execution (RCE). Yikes, it sounds terrible!

First off, what actually happened? The official statement is that “build version numbers crossed into a range that triggered a code defect”. We don’t know the exact details, but it’s something like an unsigned integer that was interpreted as a signed integer. A build number could have rolled over 32767, and what was intended to be 32768 or higher suddenly became −32767. Lots of “if greater than or equal” logic breaks down in that situation. Because of a logic flaw like this, certain versions of Windows 10 were unintentionally opting out of some historical security fixes.

And that’s where the high CVSS score and active exploitation descriptor comes from. This is simply the highest score of the resurgent flaws, and an acknowledgement that they have been exploited in the past. The good news is that this only applies to Windows 10 build 1507, so either the original install without any of the major updates installed, or one of the Windows 10 Enterprise Long-Term Servicing Branch (LTSB) versions. It seems that the March 2024 monthly security update introduced the problem, and it wasn’t fixed until this month’s updates. Continue reading “This Week In Security: Malicious Rollback, WHOIS, And More”

FLOSS Weekly Episode 800: Champagning The Ladybird Browser

This week Jonathan Bennett and Aaron Newcomb chat with Andreas Kling about Ladybird, the new browser in development from the ground up. It was started as part of SerenityOS, and has since taken on a life of its own. How much of the web works on it? How many people are working on the project? And where’s the download button? Listen to find out!

Continue reading “FLOSS Weekly Episode 800: Champagning The Ladybird Browser”

This Week In Security: EUCLEAK, Revival Hijack, And More

[Thomas Roche] of NinjaLab is out with EUCLEAK, (pdf) a physical attack against Infineon security microcontrollers, and the security tokens that contain them. The name is a portmanteau of Euclidean and leak. And no surprise, it’s a data leak in some implementations of the Extended Euclidean Algorithm (EEA), a component of an Elliptical Curve Digital Signature Algorithm (ECDSA).

OK, time to step back. Infineon microcontrollers are the digital smart parts inside popular security tokens like the Yubikey 5, some Java smart cards, and even the Infineon TPMs. These devices all serve a similar purpose. They store one or more secret keys, and are guaranteed to never disclose those keys. Instead, they use their secret keys to do cryptographic functions, like ECDSA signatures, and output the result. There’s even a special set of tests, the Common Criteria, that are intended to backstop these guarantees. What’s interesting is that an otherwise excellent product like the Yubikey 5, that passes all these auditing and certification processes, is still vulnerable.

The actual attack is to perform ECDSA signatures while monitoring the physical chip with an electromagnetic probe. This tiny directional antenna can pick up on EM noise generated by the microprocessor. That EM noise leaks timing information about the internal state of the cryptography, and the secret key can be derived as a result.

This process does require physical access to the token for several minutes. To get useful readings, the plastic case around the security token does need to be disassembled to get the probe close enough to pick up signals. From there it’s at least an hour of post-processing to actually get the key. And most of these security tokens intentionally make the disassembly process rather difficult. The point isn’t that it’s impossible to open up, but that it’s impossible not to notice that your token has been tampered with. Continue reading “This Week In Security: EUCLEAK, Revival Hijack, And More”

This Week In Security: The Rest Of The IPv6 Story, CVE Hunting, And Hacking The TSA

We finally have some answers about the Windows IPv6 vulnerability — and a Proof of Concept! The patch was a single change in the Windows TCP/IP driver’s Ipv6pProcessOptions(), now calling IppSendError() instead of IppSendErrorList(). That’s not very helpful on its own, which is why [Marcus Hutchins]’s analysis is so helpful here. And it’s not an easy task, since decompiling source code like this doesn’t give us variable names.

The first question that needs answered is what is the list in question? This code is handling the option field in incoming IPv6 packets. The object being manipulated is a linked list of packet structs. And that linked list is almost always a single member list. When calling IppSendErrorList() on a list with a single member, it’s functionally equivalent to the IppSendError() in the fixed code. The flaw must be in the handling of this list with multiple members. The only way to achieve that criteria is to send a lot of traffic at the machine in question, so it can’t quite keep up with processing packets one at a time. To handle the high throughput, Windows will assemble incoming packets into a linked list and process them in batch.

So what’s next? IppSendErrorList(), takes a boolean and passes it on to each call of IppSendError(). We don’t know what Microsoft’s variable name is, but [Marcus] is calling it always_send_icmp, because setting it to true means that each packet processed will generate an ICMP packet. The important detail is that IppSendError() can have side effects. There is a codepath where the packet gets reverted, and the processing pointer is set back to the beginning of the packet. That’s fine for the first packet in the list, but because the function processes errors on the entire list of packets, the state of the rest of those packets is now much different from what is expected.

This unexpected but of weirdness can be further abused through IPv6 packet fragmentation. With a bit of careful setup, the reversion can cause a length counter to underflow, resulting in data structure corruption, and finally jumping code execution into the packet data. That’s the Remote Code Execution (RCE). And the good news, beyond the IPv6-only nature of the flaw, is that so far it’s been difficult to actually pull the attack off, as it relies on this somewhat non-deterministic “packet coalescing” technique to trigger the flaw.

Continue reading “This Week In Security: The Rest Of The IPv6 Story, CVE Hunting, And Hacking The TSA”

FLOSS Weekly Episode 798: Building The Rust Desktop With COSMIC

This week Jonathan Bennett and Rob Campbell chat with Carl Richell about System 76, COSMIC, Wayland, Rust and more! What was the “last straw” that convinced System 76 to write their own desktop environment (DE)? What’s the story with smithay, and why did that jump start the whole process? Listen to find out!
Continue reading “FLOSS Weekly Episode 798: Building The Rust Desktop With COSMIC”

This Week In Security: Crash Your IPhone, Hack Your Site, And Bluetooth Woes

There have been some hilarious issues on mobile devices over the years. The HTC Dream had a hidden shell that was discovered when a phone rebooted after sending a text containing just the word “reboot”. iOS has gotten in on the fun from time to time, and this time it’s ""::. Type the double quotes, a colon, and any other character, and Apple’s Springboard service crashes.

Another hacker dug in a bit, and realized that Springboard is trying to jump execution to a null pointer, leading to a crash. It’s very odd that user input breaks the query parser badly enough to jump to null like that. There are a couple interesting questions that we have to ask. Given that the crash trigger is quite flexible, "anything goes":x, is it possible to manipulate that function pointer to be something other than null? And perhaps more importantly, why is the code crashing, instead of an invalid address error as one would expect from a Pointer Authentication Code (PAC) violation? Regardless, the bug seems to be fixed in the latest iOS 18 builds.

Continue reading “This Week In Security: Crash Your IPhone, Hack Your Site, And Bluetooth Woes”