The Future of Zed Attack Proxy – Simon Bennetts, Ori Bendet – ASW #302

A researcher fuzzing PHP filters found that chaining together code conversion filters caused a crash. That's good! Fuzzers a great for finding code quality issues and many times those issues manifest in ways that can be exploitable.

In this case, the underlying issue was a 24-year old bug in glibc that was exploitable only in rare cases -- one of them being in PHP's filter capability.

Hear about the journey from PHP fuzzing to exploitation to fixing directly from the researcher in their presentation at this year's OffensiveCon24.

There are lots of nice appsec lessons from these articles (check out parts 1 and 2). One of them is how simple the fix was -- basically six lines of an if statement in two different places. But even more important was that the fix was accompanied by some code to verify it and, ideally, prevent regressions.

Two very small tweaks to a fuzzer led to discovery of an exploitable flaw in a video codec. Once again, an integer overflow strikes and once again a fix is dead simple -- use an unsigned int.

I love this article because it's about fuzzing. And I love the idea of tweaking existing security tools to improve their quality and coverage to discover code quality issues. That feels like a more useful way to burn CPU cycles than hoping an LLM gets lucky with a random string.

And now an article that combines fuzzing and LLMs, with the use case of using fuzzing techniques against LLM prompts. We cover this in more detail in this week's interview segment!

A short article that mentions some high-level defenses that any code based on C or C++ should follow. It also highlights how the baseband on phones has all sort of overlapping concerns like performance, security, and consistency across devices.

Since we already mentioned an OffensiveCon24 video, check out this video from OffensiveCon23 about baseband hacking.

Here's an update from Microsoft on the security model of the new Windows Recall feature. It gives us a chance to remind appsec folks that security and privacy are peer concerns that each require threat models, design models, and controls -- it's just that all too often privacy gets incorrectly lumped under the confidentiality piece of security's CIA triad. As the early reaction to Recall shows, privacy covers more important concepts than just confidentiality, such as consent, control, and reduction.

There doesn't need to be a new "AppPriv" label for this. Let's skip straight to the part where privacy models are part of the SDLC and we see more privacy engineering teams in the vein of security engineering teams or, really, engineering teams.

There's no apparent exploitation here beyond a DoS due to crashing a system.

Instead, I thought this would be another chance to talk about fuzzing -- parsers and codecs are prime targets -- and memory safety in terms of overcoming the inertia of a large, established project that's not only in a memory unsafe language, but that has very visible performance constraints. After all, most projects might insist they need the utmost performance from the binaries their code compiles to. It's just that audio and video codecs have very obvious degradation when performance is poor.

We covered an LLM CTF from Bishop Fox back in episode 299. Here's a tool based on research into creating prompts that lead to jailbreaks.