SKILL: Week 1: Vulnerability Classes with Real-World Examples

Metadata

• Skill Name: vulnerability-classes
• Folder: offensive-vuln-classes
• Source: https://github.com/SnailSploit/offensive-checklist/blob/main/1-vulnerability-classes.md

Description

Exploit development curriculum covering core vulnerability classes with real-world CVE case studies: stack/heap buffer overflows, use-after-free, integer overflows, format strings, type confusion, and race conditions. Use when learning or teaching vuln classes, researching specific CVE patterns, or building exploit dev knowledge.

Trigger Phrases

Use this skill when the conversation involves any of: vulnerability classes, buffer overflow, use-after-free, UAF, heap overflow, stack overflow, type confusion, integer overflow, format string, memory corruption, CVE case study, exploit development, Day 1-7

Instructions for Claude

When this skill is active:

1. Load and apply the full methodology below as your operational checklist
2. Follow steps in order unless the user specifies otherwise
3. For each technique, consider applicability to the current target/context
4. Track which checklist items have been completed
5. Suggest next steps based on findings

---

Full Methodology

Week 1: Vulnerability Classes with Real-World Examples

Course Overview

created by AnotherOne from @Pwn3rzs Telegram channel.

This document is Week 1 of a multi‑week exploit development course, focusing on core vulnerability classes and real‑world exploitation context.

Next Week we'll focus on using fuzzing to identify new vulnerabilites and in week 3 we'll focus on using patch diffing to find n-days

Day 1: Memory Corruption Fundamentals

• Goal: Understand primary memory corruption vulnerability classes and their real-world impact.
• Activities:
  • Reading:
    • "The Art of Software Security Assessment" by Mark Dowd, John McDonald, Justin Schuh - Chapter 5: Memory Corruption
    • Memory Corruption: Examples, Impact, and 4 Ways to Prevent It
  • Online Resources:
    • Microsoft Security Research: Memory Safety
    • Google Project Zero Blog - Read recent memory corruption findings
  • Concepts:
    • What is memory corruption and why does it matter?
    • Understanding the stack, heap, and their differences
    • The lifecycle of memory: allocation → use → deallocation

Stack Buffer Overflow

What It Is: A stack overflow occurs when a program writes more data to a buffer located on the stack than it can hold, causing adjacent memory to be overwritten. This can corrupt important data like return addresses, allowing attackers to redirect program execution.

Case Study - CVE-2024-27130 (QNAP QTS/QuTS hero Stack Overflow):

• The Bug: QNAP's QTS and QuTS hero operating systems contained multiple buffer copy vulnerabilities where unsafe functions like strcpy() were used to copy user-supplied input into fixed-size stack buffers without proper size validation. The vulnerabilities affected the web administration interface and file handling components. POC
• The Attack: An authenticated remote attacker could send specially crafted requests with oversized input to vulnerable endpoints. The unchecked data would overflow stack buffers, corrupting adjacent memory including return addresses and saved frame pointers.
• The Impact: Remote code execution with the privileges of the QNAP system service. The attacker could gain complete control over the NAS device, accessing stored data, pivoting to other network resources, or installing persistent backdoors.
• The Fix: QNAP released QTS 5.1.7.2770 build 20240520 and QuTS hero h5.1.7.2770 build 20240520 in May 2024, replacing unsafe string copy functions with bounds-checked alternatives and implementing additional input validation.
• Why It Matters: Stack overflows remain common in embedded devices and NAS systems running legacy C/C++ code. They're particularly dangerous in internet-facing administration interfaces and often provide the initial foothold for sophisticated attack chains against enterprise infrastructure.

Use-After-Free (UAF)

What It Is: A use-after-free vulnerability occurs when a program continues to use a pointer after the memory it points to has been freed. This creates a "dangling pointer" that can be exploited by carefully controlling heap allocations to place attacker-controlled data where the freed object once lived.

Case Study - CVE-2024-2883 (Chrome ANGLE Use-After-Free):

• The Bug: Google Chrome's ANGLE (Almost Native Graphics Layer Engine) component, which translates OpenGL ES API calls to DirectX, Vulkan, or native OpenGL, contained a use-after-free vulnerability. The bug occurred when WebGL contexts were destroyed while still referenced by pending graphics operations, leaving dangling pointers to freed graphics objects.
• The Attack: An attacker could create a malicious HTML page with specially crafted WebGL JavaScript code that triggered rapid creation and destruction of graphics contexts. By carefully timing these operations, the attacker could cause ANGLE to reference already-freed memory. Using heap spray and heap feng-shui techniques, the attacker could control the contents of the freed memory region.
• The Impact: Remote code execution via a crafted web page with no user interaction beyond visiting the page. By placing a fake object in the freed memory location, the attacker could hijack control flow and execute arbitrary code in the renderer process. This could be chained with sandbox escape exploits for full system compromise.
• The Fix: Google Chrome 123.0.6312.86 (released March 2024) fixed the vulnerability by implementing proper lifetime management for graphics objects and adding reference counting to prevent premature destruction of objects still in use.
• Why It Matters: UAF vulnerabilities are particularly dangerous in browsers and complex C++ applications where object lifetimes are difficult to track. Graphics subsystems like ANGLE are attractive targets because they handle untrusted content and have complex state management. They're a favorite target for advanced attackers because they offer fine-grained control over program execution.

Heap Buffer Overflow

What It Is: Similar to stack overflows, heap overflows occur when a program writes beyond the boundaries of a dynamically allocated buffer on the heap. Instead of corrupting stack frames, heap overflows typically corrupt heap metadata or adjacent objects, leading to memory corruption when the heap allocator later processes the corrupted structures.

Case Study - CVE-2023-4863 (libWebP Heap Buffer Overflow):

• The Bug: The libWebP library, used by Chrome, Firefox, Edge, and many other applications for processing WebP images, contained a heap buffer overflow in the BuildHuffmanTable() function. When parsing specially crafted WebP images with malformed Huffman coding data, the function would write beyond the allocated buffer boundaries. POC
• The Attack: An attacker could embed a malicious WebP image in a web page or send it via messaging apps. When the victim's browser or application attempted to decode the image, the overflow would occur. The attacker could control the overflow data to corrupt heap metadata and adjacent objects.
• The Impact: Remote code execution with no user interaction beyond viewing a web page or opening an image. Exploited as a zero-day in the wild before public disclosure. The vulnerability affected billions of devices across multiple platforms (Windows, macOS, Linux, Android, iOS).
• The Fix: libWebP 1.3.2 (September 2023) fixed the bounds checking in BuildHuffmanTable(). Chrome 116.0.5845.187, Firefox 117.0.1, and other affected software released emergency patches.
• Why It Matters: Heap buffer overflows in image parsers are particularly dangerous because images are ubiquitous and processed automatically. This vulnerability demonstrated the supply chain risk of widely-used libraries - a single bug in libWebP affected dozens of major applications. Modern heap exploitation techniques can bypass ASLR and other protections when combined with information leaks.

Out-of-Bounds Read (Info Leak)

What It Is: Reading past buffer bounds without modifying memory. Frequently used to leak pointers, object metadata, and kernel layout to defeat KASLR and build arbitrary read/write primitives.

Case Study - CVE-2024-53108 (Linux AMDGPU Display Driver OOB Read):

• The Bug: In the AMD display driver’s EDID/VSDB parsing path, insufficient bounds checking allowed out-of-bounds reads when extracting identifiers, leading to slab-out-of-bounds access under KASAN.
• The Attack: A crafted display/EDID data stream could trigger an OOB read in kernel space. While not directly granting write primitives, the info leak can expose kernel memory contents and aid in bypassing KASLR.
• The Impact: Information disclosure and potential system instability.
• The Fix: Kernel updates tightened length validation within the AMD display capability parsing logic to ensure all reads stay within EDID buffer bounds. DIFF
• Why It Matters: Pure OOB reads are valuable for building reliable exploit chains (e.g., pairing with separate write primitives), especially in kernel contexts where defeating KASLR is pivotal.

Uninitialized Memory Use

What It Is: Using stack/heap/pool memory before it is initialized. Contents may include stale pointers, capability flags, or structure fields.

Case Study - CVE-2024-26581 (Linux Kernel Netfilter Uninitialized Variable):

• The Bug: The Linux kernel's netfilter subsystem contained an uninitialized variable vulnerability in the nf_tables component. When processing netlink messages to configure firewall rules, the nft_pipapo_walk() function failed to initialize a local variable before use. The uninitialized stack variable could contain residual data from previous function calls, including kernel pointers and sensitive memory addresses. POC
• The Attack: An attacker with CAP_NET_ADMIN capability (obtainable via unprivileged user namespaces on many distributions) could trigger specific netfilter operations that caused the uninitialized variable to be read and copied back to userspace through netlink responses. By repeatedly triggering the vulnerable code path and analyzing returned data, an attacker could extract kernel memory contents including heap/stack addresses.
• The Impact: Information disclosure leading to KASLR (Kernel Address Space Layout Randomization) bypass. The leaked kernel addresses could then be used to reliably exploit other kernel vulnerabilities, turning potential denial-of-service bugs into privilege escalation or code execution. This vulnerability was particularly dangerous when combined with other netfilter bugs for full LPE chains.
• The Fix: Linux kernel 6.8-rc1 (February 2024) added proper initialization of the variable using designated initializers: struct nft_pipapo_match *m = NULL; and added explicit zero-initialization for stack structures. Additionally, the patch enabled stricter compiler warnings (-Wuninitialized) for the netfilter subsystem.
• Why It Matters: Uninitialized memory reads are frequently the first stage in exploit chains, providing the entropy reductions needed to bypass modern mitigations like KASLR. They're particularly valuable in kernel exploitat