Message-ID: <4332B43B.11121.5DFF3A8@localhost>
Date: Thu, 22 Sep 2005 13:40:11 +0200
From: "Amit Klein (AKsecurity)" <aksecurity@...pop.com>
To: bugTraq <bugtraq@...urityfocus.com>
Subject: HTTP Request Smuggling - ERRATA (the IIS 48K buffer phenomenon)


Hi 

With respect to the IIS/5.0 48K "bug" (see "HTTP Request Smuggling", 
http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf, pages 6-7 or 4-5),
Noam Ben-Yochanan commented that IIS/5.x provides with the programmer with a way to consume
the request body (beyond the 48K usually read), thus disabling the HTTP Request Smuggling
caused by this anomaly. Noam sent me a link that explains this:

Microsoft Knowledge Base article #810957:
http://support.microsoft.com/default.aspx?scid=kb;en-us;810957

The short story is that IIS reads the body in buffers of 48KB (the default
value of UploadReadAheadSize in the MetaBase registry). It probably always reads
the first buffer. 
Now, the HTTP Request Smuggling trick works by sending any Content-Type
OTHER THAN application/x-www-form-urlencoded. This means that IIS has nobody parsing
the data and consuming more data, so it stops reading after those 48K, and whatever
comes next is considered the next request (while MS says it is "by design", in my
opinion this is still a bug, and with security implications).

As Noam noted, it is possible to "artificially" consume the data using
Request.BinaryRead, e.g. something like:

  Dim data
  data = Request.BinaryRead(Request.TotalBytes) 

And by this, restore order.

So a possible solution is to insert the above code in every ASP page.

However, there is a serious downside to this method: if a page accesses
Request.BinaryRead, it cannot access the Form collection (see the documentation of 
BinaryRead in 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iissdk/html/c84b1f88-1a8a-
4370-95de-e907f7fdd5e7.asp).

Here's an improved solution. Note that the Content-Type of the request
must be anything other than application/x-www-form-urlencoded for the attack to work (I
understand now that this is due to the fact that in application/x-www-form-urlencoded, the 
IIS ASP.dll consumes the request body in fullness). So if a script wants to secure itself, 
it should check whether the Content-Type (accessible via 
ServerVariables("HTTP_CONTENT_TYPE") is application/x-www-form-urlencoded.
If it is, then the script can proceed as usual, and access the data through the 
Request.Form collection. If the Content-Type is not
"application/x-www-form-urlencoded", then the script 
should consume the data (as in the above example), and log the event
(since this is probably an attack). Ideally, the script would terminate the TCP
connection, but I don't know whether a script can terminate the TCP connection in a
reliable manner. 
Perhaps sending a "Connection: Close" header can do the trick (or a 400
status code?). 

So the proposed solution would be something like (pardon me for any ASP syntax error):

If (Request.ServerVariables("HTTP_CONTENT_TYPE") <> _
"application/x-www-form-urlencoded") Then
	' Log a security error condition
	' Consume leftover data
	Dim data
	data = Request.BinaryRead(Request.TotalBytes) 
	' Exit gracefully - do not proceed to normal flow
EndIf
' Work as usual, can access Request.Form

Still, it requires every ASP page to embed this kind of code. I think this
makes the solution infeasible. And frankly I still call this a bug (be it by design or
not) - an ASP page should not worry about its content-type or consuming the request body.

Thanks again to Noam!
-Amit

Powered by blists - more mailing lists