Sign in Subscribe
5 min read

exploits.club Weekly Newsletter 57 - Decompiling 2024, RANsacked, SUSCTL, And More

exploits.club Weekly Newsletter 57 - Decompiling 2024, RANsacked, SUSCTL, And More

Another week of trying to be the DeepSeek to tl;dr sec's OpenAI. Hey @clintgibler 👋

Annnnnnnyways 👇

In Case You Missed It...

Resources And Write-Ups From This Week:

  • SUSCTL (CVE-2024-54507) - What do you get when you set up your own custom suite of XNU regression tests to run on each new release? Well, in the case of @0xjprx, sometimes you get a silly info leak. This new write-up takes us through how running sysctl -a ended up triggering a KASan invalid load. The bug resulted from an int type confusion, in which a uint16_t is cast to an int, causing a 2-byte OOB read. These two bytes are subsequently returned to userspace, resulting in a kernel leak. The post walks through a demonstration of this, with PoC code included. It then theorizes what can be leaked with the classic answer of "It depends". Finally, it rounds out with the patch and some takeaways.
  • Decompiling 2024: A Year of Resurgance in Decompilation Research - We are no stranger to @mahal0z posts here at the club. Last year, we covered both parts of his Unsolved Structuring Problem series. This week, he returned to his blog to discuss what a year decompilation had in 2024. The post specifically focuses on the influx of academic publications and the increase in "top-tier" appearances. This leads mahal0z to theorize that decompilation is "mature enough to publish in top-tier" and continues to "grow rapidly". The post then takes a look at some of the common trends across this year's publications, including what is "good" decompilation (source recovery, simplicity, semantic correctness) and AI's growing uses. It rounds out with some non-academic works as well and concludes that this was a special year, and the excitement will hopefully carry over into 2025.
  • RANsacked: A Domain-Informed Approach for Fuzzing LTE and 5G RAN-Core Interfaces - What do you get when you find a way to effectively fuzz RAN-Core interfaces? Apparently, 119 vulnerabilities with 93 unique CVEs assigned. This new paper walks through the different components of a cellular network, mapping out the different potential attack surfaces and the associated threat models. From there, it covers the traditional difficulties fuzzing LTE/5G networks, such as delayed messaging, initialization, and complexity. As a result, the team created ASNFuzzGen, which compiles "ASN.1 specifications into structure fuzzing modules." And yeah, safe to say it was a a success. The paper talks a bit about seed selection and performance, before going over the findings, including two case studies and some broad bug class conclusions.
  • CVE-2024-6773 – Type confusion in v8 - A quick hitter about a type confusion in V8's Turboshaft compiler optimization pipeline. The bug stems from "improper pointer handling in Turboshaft's Load Elimination optimization phase." In plain English, a faulty optimization takes place, resulting in a pointer that the Garbage Collector briefly loses track of. Therefore, the dangling pointer survives heap compaction and potentially allows for arb read/write if you win the GC race. Okay...so not "plain" English, but probably as close as we are gonna get. Bonus points for the Nord theme on the code snippets.
  • CVE-2024-26230: Windows Telephony Service - It's Got Some Call-ing Issues (Elevation of Privilege) - A fun windows UAF in the Windows Telephony Service (TapiSrv). The bug results from a deallocation without properly checking refcounts, followed by a callback, which subsequently uses the freed object. The post then moves on to discuss exploitation, specifically hunting for a way to craft objects of arbitrary size with arbitrary data. From there, it quickly detours into a bit of Interface Definition Language (IDL) to help understand how to communicate with the Telephony Service before walking through the steps to get PC control. However, PC is only half the battle here, as a CFG bypass is needed as well. Using malloc, it is possible to leak 32 bits, and then use that information to make a call to VirtualAlloc where we can remap memory, provide a path to our malicious DLL, and make a call to load it. Then, with assistance from PrintSpoofer, a full EOP is achieved. Also, the post just casually includes a bonus OOB write bug that the team found while writing the exploit.
  • CVE-2024-49138 Windows CLFS heap-based buffer overflow analysis – Part 1 - A two-part blog series covering a recent ITW Windows bug (well, the patch itself actually fixes two distinct bugs). Part one specifically focuses on one of the bugs, while part two takes a look at the other, each rounding out with a full exploit. To kick things off, the post provides a bit of background on the Common Log File System (CLFS) and includes links to some previous research in the area. From there, we get into the vulnerability analysis, walking through the relevant functions and demonstrating how they lead to a UAF. Code for a full PoC is included, as is an outline of the necessary for exploitation. Part 2 follows much the same format, and a very similar code pattern resulting in the bug. And again, full PoC code is included with steps for exploitation.

Interesting Job Postings:

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!

Your second brain - strictly for bugs

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 🏴‍☠️

Published by:

exploits.club