themalwareguardian/cve-2002-1120Classic stack-based buffer overflow in Savant Web Server 3.1 demonstrating early-2000s remote memory corruption through a crafted HTTP request.
Classic stack-based buffer overflow in Savant Web Server 3.1 demonstrating early-2000s remote memory corruption through a crafted HTTP request (a 2002 vulnerability that demands more from a beginner than most buffer overflow CVEs from 2025).
This repository is part of the material I use when teaching memory corruption exploitation (in addition to my regular work, I also teach in different cybersecurity courses where I help train the next generation of reverse engineers). When I cover stack-based buffer overflows in class, I work through real cases rather than toy examples, and this CVE is one I return to specifically when I want to challenge students who already have some experience with basic EIP overwrites.
The reason is that the year in a CVE identifier tells you nothing about how hard the exploitation is. Most students assume that older CVEs must be simpler, a straightforward overflow, a JMP ESP, done. This one proves otherwise. Some CVEs I teach from 2025 are fundamentally more basic than this, because the vulnerability class is simpler or the constraints are fewer. CVE-2002-1120 requires understanding things that some modern exploits do not demand: why certain opcodes cannot be used in certain parts of the request, how to craft a conditional jump that always fires when the unconditional one is blocked, how to deliver shellcode when it does not fit where you would normally put it, and how an egghunter solves a space problem that would otherwise make the exploit impossible.
It is the CVE I assign when I want to see if someone actually understands what they are doing.
This vulnerability affects Savant 3.1, a freeware Windows HTTP server from 2002. What makes it worth studying in 2025 is not the age but the combination of constraints it introduces and the techniques required to work around them:
Each one of these constraints is a lesson in itself.
Savant is a freeware open-source Windows HTTP server originally designed to turn any desktop computer into a web server. It listens on TCP port 80 and processes standard HTTP GET requests. The overflow occurs in the handler that copies the URI path into a fixed-size stack buffer without validating its length.
Key technical details:
Savant processes incoming HTTP GET requests and copies the URI path into a fixed-size stack buffer without checking its length. A simplified version of the vulnerable logic looks like this:
char uri_buffer[270];
strcpy(uri_buffer, uri_path);
Sending a GET request with a URI of approximately 271 bytes overwrites the saved return address on the stack. The overflow is constrained, sending significantly more than that causes the crash in a way that EIP is no longer controlled, so the usable window is narrow.
The exploitation is more complex than a standard EIP overwrite because of two additional properties of the server: the HTTP method field is also copied into memory and executed, and the body of the HTTP request is stored in a separate heap region rather than on the stack (both of these properties become essential parts of the exploit chain).
The crash can be reproduced by sending a GET request with a sufficiently long URI. No authentication is required. Example using Python:
import socket
HOST = '127.0.0.1'
PORT = 80
payload = b"A" * 271
request = (
b"GET /" + payload + b" HTTP/1.1\r\n"
b"Host: 127.0.0.1\r\n"
b"Connection: close\r\n"
b"\r\n"
)
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((HOST, PORT))
s.send(request)
s.close()
When executed under a debugger, the crash shows EIP overwritten with user-controlled data:
EIP = 41414141
confirming that the saved return address has been corrupted by the overflow.
The goal of this repository is not only to demonstrate the crash, but to walk through the complete exploitation process step by step, including every constraint that makes this case harder than a standard EIP overwrite and every decision made to work around them.
To keep the main README clean, the detailed exploitation notes, scripts, and debugger steps are placed inside the Vulnerability 📂 folder of this repository.
There you will find the complete workflow used to exploit this CVE, including: