Gonna start sending out questionnaires weekly to all readers asking for 5 things you hacked this week. Don't have them? You're out of the club. Annnnnnyways 👇

In Case You Missed It...

• RECon and DistrictCon Round-Up - The battle of the new US cons took place over the last two weeks, and both have been good about re-sharing slide decks from talks. Check out the @REverseConf and @DistrictCon accounts to see some of the reshared materials.
• Jackalope Harness Additions - @ifsecure added his harness responsible for finding some CoreAudio bugs to the examples.
• March Android Security Bulletin w/ 10 Crits - Maybe Google's internal LLM tooling is getting really good.

Resources And Write-Ups From This Week:

• Hacking the Xbox 360 Hypervisor Part 2: The Bad Update Exploit - As promised, @Grimdoomer is back this with the second part of his Xbox 360 exploit. Look - we tried to do this one justice with a summary, but anything we write feels insufficient. It's packed full with methodology notes, Xbox 360 internals, and a crazy bug / exploit that deals with encrypted memory, ciphertext generation, bootloader updates...and that's all just the first half!
• Trigon: developing a deterministic kernel exploit for iOS - Another week, another high school student being better at something than most of us who have a career of it under our belt. @alfiecg_dev released a write-up this week on his second look at CVE-2023-32434. Last year, he blogged about a step-by-step guide to writing an iOS kernel exploit in which he walked through the physical UAFs that were found in iOS. However, after hearing through the grapevine that the ITW variants did not rely on memory corruption, he decided to circle back and give it another pass. With a bit of experimentation and additional research, he found a way to map physical memory into his userland process. While it seems like that would be game over, there were a handful of additional gotchas in the way to achieving a deterministic kernel exploit.
• !exploitable Episode Two - Enter the Matrix - A few weeks back, we covered the first entry into the "!exploitable" series, where Doyensec decided that they should write some fun exploits on their team offsite cruise. In this new episode, they take a look at SSHNuke, reliving the glory days of 2001 and "The Matrix Reloaded". The post recaps the int overflow bug, and develops a basic trigger to validate the vulnerability in a sample program. From there, the team sets up an old OpenSSH server, and crashes it with their write-what-where. While they didn't take it all the way to RCE, they do discuss some of the weaknesses of the primitive and further conclusions.
• When NULL isn't null: mapping memory at 0x0 on Linux - Can a null pointer actually point to mapped memory on Linux these days? Well, it depends on what your vm.mmap_min_addr is set to. An interesting post and a good reminder that if the sysctl parameter has been (mis)configured in a custom way, it may bring this ancient bug class back into play.
• Exploitation of AIxCC Nginx bugs: Part I - Another great exploit dev post, though we are a bit late to it. This one comes from Zhuo Ying Jiang Li, and he takes a look at the Nginx bugs added for AIxCC to determine their exploitability. The post walks through each UAF bug, and then takes a look at exploitation, taking into account different allocators. It's an interesting look not only at Nginx internals, but also at the differences between ptmalloc and jemalloc, the optimizations they can leverage....and of course what that means for your bugs.
• A very fancy way to obtain RCE on a Solr server - The first sentence of this one got our blood boiling - "most beautiful and complex vulnerabilities I have ever found, and how it got triaged as "Duplicate", although I was the only one achieving RCE." But even with the misfortune, it's impossible to disagree that this a beautiful bug. The crux boils down to a custom .jar library which could be delivered remotely to a Solr server, leading to RCE. And although the target company didn't necessarily pay out like they should have, it still makes for a great write-up.
• Zen and the Art of Microcode Hacking - Occasionally we include some microcode research in these newsletters, including the recent AMD Microcode Signature Verification Vulnerability. But if those bugs have gone over your head (as they often do our own), then fear not - this new post from Google serves as both a great introduction to the subject, as well as a deeper dive on the bug linked above. The write-up gives a background on microcode in general, discusses the AMD microcode patching routine, its verification algorithm, and the vulnerability the team identified (more crypto this week for all you crypto fans...you freaks). It then discusses the patch released by AMD, and introduces zentool, an "AMD Zen microcode manipulation utility"

Interesting Job Postings:

• Secure Code Reviewer @ Accenture (On-Site: Denver, CO)
• Senior Vulnerability Researcher @ ARM (On-Site: Austin, TX)
• Senior Vulnerability Researcher @ STR (On-Site: Melbourne, FL)
• Staff Reverse Engineer @ Dragos (Remote)
• Exploit Developer @ Lockheed Martin (On-Site: Hanover, MD)

Wrapping Up...

As always, thanks for stopping by. We here at the club are always trying to improve so if you have comments, questions, or suggestions, feel free to shoot us an email - info@exploits.club.

Follow us on X - we occasionally Tweet poor attempts at memes

Don't forget to check out https://bug.directory!

We sell mugs, and personally we have seen a drastic uptick in bugs since using ours. Get yours on at https://shop.exploits.club.

Feel free to join the exploits.club Discord server here 👉 https://discord.gg/2dxN2Gtgpx

Same time next week? See you then 🏴‍☠️