For the second time, we attended the legendary OffensiveCon — top-tier talks, flawless organization, and unforgettable parties. Huge thanks to the organizers; it truly lives up to the hype! You can find a quick review of what we liked the most.

Parser Differentials: When Interpretation Becomes a Vulnerability by Joernchen

A parser is a program or a software component that analyzes and processes input data according to a specified syntax or structure. It is commonly used in computer programming and cybersecurity to interpret and validate data, such as network traffic, logs or configuration files, to detect anomalies or potential security risks.

This talk explored parser differential bugs—intriguing and often dangerous issues that arise when multiple parsers interpret the same input in subtly different ways.

Using YAML as a case study, Joernchen demonstrated how small discrepancies in how various implementations handle specifications, edge cases and error recovery can result in “very useful difference vulnerabilities”. Through hands-on examples involving widely used YAML parsers, he showed how these inconsistencies can surface in real-world scenarios and lead to serious security vulnerabilities in production environments.

He also highlighted notable parser differential vulnerabilities discovered in the wild, illustrating the broader implications and creative exploitation of this technique across diverse formats and systems.

Android In-The-Wild: Unexpectedly Excavating a Kernel Exploit by Seth Jenkins

In this presentation, Seth Jenkins presented his research which started with analysing kernel crash logs for an in-the-wild Android exploit without the corresponding exploit sample. He presented his journey with finding three bugs in an attempt to reproduce the same kernel crash logs discovered. Along the way, he demonstrated how crash artifacts, careful experimentation and classical vulnerability research techniques can converge to reveal hidden attacker strategies. The talk concluded with insights into what the logs suggest about the original exploit’s design and the broader implications for Android kernel security.

Breaking the Sound Barrier: Exploiting CoreAudio via Mach Message Fuzzing by Dillon Franke

Inter-Process Communication (IPC) on macOS is an essential aspect of any operating system. It refers to a set of methods allowing processes to communicate with each other and synchronise their actions. The study presented in this talk focused on the overlooked attack surface of Mach message handlers. System daemons frequently employ these handlers to reveal privileged, RPC-like functionality; yet, because of their intricacy, there are chances for local privilege escalation and sandbox escapes.

In this presentation, Dillon Franke walked through the fuzzing process and explained how to effectively select a target for security research. He presented next how he found flaws in the Mac message handlers using fuzzing, focusing on the coreaudiod system daemon. A key component of his work is a method he refers to as API call chaining, which is an effective way of directing coverage-based fuzzers through intricate, stateful API interactions.

He already has written a well-detailed blog post about it.

By combining static and dynamic analysis with runtime instrumentation and a custom-built fuzzing harness, he uncovered several security flaws—including a high-impact memory corruption vulnerability. He also discovered a second vulnerability: a double free issue in CoreAudio.

He detailed the necessity of correctly initialising the CoreAudio subsystem, simulating faulty parts and creating a focused grammar to promote deeper fuzzing coverage.

Entrysign: Create Your Own x86 Microcode for Fun and Profit by Matteo Rizzo, Kristoffer (spq) Janke, Eduardo Vela Nava and Josh Eads

The security team of Google was here to present the work they have done on AMD microcode. This research resulted in the EntrySign bug.

EntrySign is a design flaw that leads to improper signature validation in AMD microcode patch system. It was a team effort, however, this time Matteo Rizzo, Kristoffer Janke, Eduardo Vela Nava and Josh Eads were in Berlin to talk with us.

They already have written a well-detailed blog post about it. The Google team was here to re-explain their work in a lightweight form and go more in-depth on parts that are not detailed in the paper.

The bug, which could have a massive impact on security, was well hidden behind a fog of obscurity. The only public information that they had at the start was the patches provided by AMD to the open source community and the process to apply these last ones.

Google folks have explained to us how they passed through this fog and uncovered a misconception that let them modify the microcode of all the AMD CPUs.

As one can ask itself: no, they do not have broken materials. Even they were surprised!

KernelGP: Racing Against the Android Kernel by Chariton Karamitas

Huku, from Census Labs, started with a statement saying that: while attacking the Linux kernel, there are known methods (like userfaultfd) in order to delay actions and increase the window for race conditions. Those methods are not accessible on Android because they are either not activated or either not accessible from userspace. Those techniques are known from years and are not mitigated because those are part of the design of some important mechanisms. So he had searched for Android specific designs that could lead to the same results.

He presented 4 of his findings. Three of them are accessible from a normal application context, and one is accessible from system context:

• Proxy file descriptors
• Scoped storage
• Redaction and Transcoding
• Incremental FS (this is the one accessible from system context)

Those techniques relay on userland callbacks (e.g.: Proxy file descriptors) or on information processing that can be increased (e.g.: Redaction and Transcoding).

Since they are a side effect of normal Android mechanisms, it is difficult to mitigate them as with the previously cited Linux techniques.

Finding and Exploiting 20-Year-Old Bugs in Web Browsers by Ivan Fratric

Ivan Fratric from Google Project Zero was here to demonstrate to us a good lesson: bugs can be everywhere, even in an old and previously very audited code base. It is the case for the XSLT parser of Firefox. XSLT is part of the DOM which was well known in the past for bugs, but it was less audited in the past years in favor of JIT. Ivan gave it a try, and the less we can say: it was a success!

He mixed manual code review and fuzzing in order to discover bugs. While reviewing previously reported CVEs, a moderate one took his attention: Javascript can hang during XSLT parsing. That means that Javascript can be executed during XSLT manipulation, but the code base hasn’t been developed with concurrency in mind. Starting from here, almost every interaction between Javascript and the resulting DOM elements of the XSLT became an UaF.

He developed an exploit by transforming an UaF bug into an Out-Of-Bound read in order to create a leak primitive. This allowed him to create a fake object in memory, resulting into arbitrary code execution.