Stack Buffer Overflow in ASP Handler

Executive Summary

A binary analysis of the web CGI/ASP handling paths identified 1 confirmed vulnerability The issue is a critical stack out-of-bounds write in the wlscan ASP handler, caused by an unchecked copy length derived from parsed input. The path is marked reachable from network, so remote exploitation is feasible.

Binary Profile

• Security Flags: PIE absent, NX absent, stack_canary absent, RELRO absent
• Risk Level: Critical

Findings

1. Stack OOB Write in wlscan ASP Handler — Critical

• Function: sub_415370 (wlscan ASP handler entry) @ 0x415370
• CWE: CWE-787 — Out-of-bounds Write (also CWE-121 — Stack-based Buffer Overflow)
• Category: memory_corruption
• Reachability: reachable_from_network

Description

The handler performs strncpy(&str_1, &var_744, len) at 0x415730, where str_1 is only 0x80 bytes. The copy length is computed from pointer arithmetic ($s2_1 - &var_744) at 0x415734, based on parsed data from an input line buffer, with no upper-bound check against the destination size. If len exceeds 0x80, adjacent stack data can be overwritten. This creates a controllable memory-corruption primitive in a network-reachable code path.

Taint Chain

fgets @ 0x4156a0 (up to 0x200 bytes into &var_748)
→ strrchr(&var_748, ':') @ 0x415710
→ $s2_1 = strrchr_result - 0xe @ 0x415718
→ len = $s2_1 - &var_744 @ 0x415734 (no len <= 0x80 guard)
→ strncpy(&str_1, &var_744, len) @ 0x415730

Mitigations

• Present: none
• Absent: bounds_check, stack_canary, NX, PIE, RELRO