TinyWeb HTTP Server - MITRE CVE Advisories

Description

TinyWeb 1.94 and below allows unauthenticated remote attackers to cause a denial of service (Buffer Overflow) when sending excessively large elements in the request line.

Technical Details - Vulnerable Code

The vulnerability exists in TCollector.Collect() function in SrvMain.pas. The vulnerable code grew the CollectStr buffer without bounds when parsing HTTP request lines:

// VULNERABLE CODE (before fix):
for i := 0 to j - 1 do begin
  if l <= CollectLen then begin
    Inc(l, j + 100);
    SetLength(CollectStr, l);    // NO LIMIT - grew to 2GB!
  end;
  Inc(CollectLen);               // NO CHECK - unbounded growth!
  CollectStr[CollectLen] := Buf[i];
end;
Result := True;                  // ALWAYS TRUE - never rejected!

Attack Vector

The PoC sends ~900MB of data as HTTP method field without CRLF terminator:

• Attacker sends 'P' * 941114855 bytes before " / HTTP/1.1\r\n"
• CollectStr grows via SetLength() calls: 1KB -> 2KB -> ... -> 2GB
• No CRLF means line never completes, buffer never resets
• Hits 32-bit address space limit, causes runtime error 203 (Heap Overflow)
• Thread crashes but memory not freed -> memory leak
• Repeated attacks exhaust all 2GB, causing complete DoS

Fix Implementation (SrvMain.pas lines 95-96, 715-788)

Added two constants defining maximum sizes:

const
  CMaxHeaderLineLength = 8192;   // Max 8KB per request line
  CMaxTotalHeaderSize = 65536;   // Max 64KB total headers

Modified TCollector.Collect() to check bounds before each byte stored:

function TCollector.Collect(var Buf: THTTPServerThreadBuffer;
  j: Integer): Boolean;
var
  i, l, TotalSize: Integer;
begin
  Result := True;
  if not CollectEntityBody then
  begin
    l := Length(CollectStr);
    // Calculate total header size
    TotalSize := 0;
    for i := 0 to Lines.Count - 1 do
      Inc(TotalSize, Length(Lines[i]));
    Inc(TotalSize, CollectLen);

    for i := 0 to j - 1 do
    begin
      // Check for excessive line length
      if CollectLen >= CMaxHeaderLineLength then
      begin
        Result := False;
        Exit;
      end;
      // Check for excessive total header size
      if TotalSize >= CMaxTotalHeaderSize then
      begin
        Result := False;
        Exit;
      end;
      // ... rest of processing
    end;
  end;
end;

How to Test the Fix

1. Start TinyWeb v1.99: tiny.exe C:\www 8080
2. Send oversized request line (Python):

   import socket
   s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
   s.connect(('127.0.0.1', 8080))
   s.send(b'GET /' + b'A' * 10000 + b' HTTP/1.1\r\nHost: test\r\n\r\n')
   response = s.recv(1024)
   print(response)  # Should receive HTTP error, not crash
   s.close()

3. Verify server remains responsive after attack
4. Expected: Server rejects request, continues serving other clients

Fix Commits

• d49c3da - Initial fix implementation
• 2584082 - Documentation and CVE details

Description

TinyWeb 1.9 allows remote attackers to read source code of scripts via "/./" in the URL.

Technical Details

The vulnerability occurs because /./ (current directory reference) bypasses the CGI script detection logic. Windows ExpandFileName() normalizes /cgi-bin/./script.pl to /cgi-bin/script.pl, but the original URL path comparison fails, causing the file to be served as static content instead of executed.

Vulnerable Code (v0.6 - December 1997)

In SrvMain.pas, the WebServerHttpResponse() function had no check for \.\ pattern:

// VULNERABLE (v0.6): No check for \.\ pattern
s := d.URIPath;
Replace('/', '\', s);
if (s='') or (s[1]<>'\') then
begin
  Result := THttpResponseErrorCode.Create(403);
  Exit;
end;
if (Pos('..', s)>0) or      // Only checks ..
   (Pos(':',s)>0) or        // Only checks :
   (Pos('\\',s)>0) then     // Only checks \\
begin                        // MISSING: No check for \.\ or #0
  Result := THttpResponseErrorCode.Create(403);
  Exit;
end;
LocalFName := ParamStr1 + s;  // VULNERABLE: No ExpandFileName + StrEnds check

Fixed Code (v1.93 - June 3, 2004)

Added two-level protection in WebServerHttpResponse():

// FIXED (v1.93): Added \.\ check and StrEnds verification
if (Pos(#0, s)>0) or              // NEW: Block null bytes
   (Pos('..', s)>0) or
   (Pos(':',s)>0) or
   (Pos('\.\', s) > 0) or         // NEW: Block \.\ pattern (level #1)
   (Pos('\\',s)>0) then
begin
  Result := THttpResponseErrorCode.Create(403);
  Exit;
end;

LocalFName := ExpandFileName(ParamStr1 + s);  // NEW: Normalize path

if not StrEnds(LocalFName, s) then  // NEW: Level #2 - detect normalization
begin
  Result := THttpResponseErrorCode.Create(403);
  Exit;
end;

if not LocalFNameSafe(LocalFName) then  // NEW: Level #3 - validate components
begin
  Result := THttpResponseErrorCode.Create(403);
  Exit;
end;

Diff URL

Compare v0.6 to v1.93 on GitHub

How to Test the Fix

1. Create test CGI script: C:\www\cgi-bin\test.pl
2. Start TinyWeb v1.99: tiny.exe C:\www 8080
3. Test attack vector:

   curl -v "http://127.0.0.1:8080/cgi-bin/./test.pl"

4. Expected result: HTTP 403 Forbidden (not script source code)
5. Test normal access:

   curl -v "http://127.0.0.1:8080/cgi-bin/test.pl"

6. Expected result: Script executes normally

Description

TinyWeb 1.9 allows remote attackers to cause a denial of service (CPU consumption) via a ".%00." in an HTTP GET request to the cgi-bin directory.

Technical Details

The null byte (%00) in the path causes string functions to behave unexpectedly. When processed, the path /cgi-bin/.%00./file may cause infinite loops or excessive processing in path validation routines because null terminates C-style strings prematurely while Pascal strings use length prefix.

Vulnerable Code (v0.6 - December 1997)

In SrvMain.pas, no null byte check existed:

// VULNERABLE (v0.6): No null byte (#0) check
s := d.URIPath;
Replace('/', '\', s);
if (Pos('..', s)>0) or
   (Pos(':',s)>0) or
   (Pos('\\',s)>0) then    // MISSING: No Pos(#0, s) check!
begin
  Result := THttpResponseErrorCode.Create(403);
  Exit;
end;
LocalFName := ParamStr1 + s;
// VULNERABLE: No LocalFNameSafe() or FileIsRegular() validation

Fixed Code (v1.93 - June 3, 2004)

Added null byte blocking and path validation functions:

// FIXED (v1.93): Added null byte check
if (Pos(#0, s)>0) or       // NEW: Block null bytes
   (Pos('..', s)>0) or
   (Pos(':',s)>0) or
   (Pos('\.\', s) > 0) or
   (Pos('\\',s)>0) then
begin
  Result := THttpResponseErrorCode.Create(403);
  Exit;
end;

// NEW: Validate path components
if not LocalFNameSafe(LocalFName) then
begin
  Result := THttpResponseErrorCode.Create(403);
  Exit;
end;

New FileIsRegular() function validates files are disk files, not device names:

// NEW in v1.93: FileIsRegular() function
function FileIsRegular(const FN: string): Boolean;
const
  fDevices: string = #1'CON'#1'PRN'#1'AUX'#1'NUL'#1'CLOCK$'...#1'LPT9'#1;
begin
  // Block Windows reserved device names (CON, PRN, AUX, NUL, COM1-9, LPT1-9)
  s := UpperCase(ExtractFileName(FN));
  Result := (s = '') or (Pos(#1 + s + #1, fDevices) = 0);
  if Result then
  begin
    // Verify file is actually a disk file via GetFileType() API
    F := CreateFile(...);
    FT := GetFileType(F);
    Result := (FT = FILE_TYPE_DISK) or (FT = FILE_TYPE_UNKNOWN);
  end;
end;

New LocalFNameSafe() function validates all path components:

// NEW in v1.93: LocalFNameSafe() function
function LocalFNameSafe(const AFName: string): Boolean;
begin
  // Traverse each directory in path
  // Check file attributes (reject hidden/system files)
  // Call FileIsRegular() for each component
end;

Diff URL

Compare v0.6 to v1.93 on GitHub

How to Test the Fix

1. Start TinyWeb v1.99: tiny.exe C:\www 8080
2. Test attack vector:

   curl -v "http://127.0.0.1:8080/cgi-bin/.%00./test"

3. Expected result: HTTP 403 Forbidden (immediate response, no CPU spike)
4. Monitor CPU usage during request - should remain normal
5. Verify server remains responsive to other requests