COMMAND
Hursley Software Laboratories Consumer Transaction Framework
SYSTEMS AFFECTED
HSLCTF 1.0 for AIX
PROBLEM
Following is based on a Defcom Labs Advisory def-2001-12 by Peter
Grundl. The HSLCTF HTTP object contains a flaw that could allow
a malicious attacker to crash the web object and interconnected
objects (eg. SMTP).
A never-ending HTTP request will crash the HTTP service, and can
also bring down the internal mail system. The request looks like
this:
GET / HTTP/1.0\r\nhost:www.foo.org\r\nreferrer: aaaaaaa..aaaaaaaaaaaa
This means a script that will continue to fire in "a"'s in the
socket, until it exhausts the server.
This vulnerability is closely coupled with def-2001-11, as the
method of triggering the crash in HSLCTF is the same is the one in
Websweeper (see Others section for more details).
SOLUTION
The following workaround example has been supplied by IBM Hursley
Software Laboratories:
import com.ibm.CTF.Adapters.*;
import java.io.*;
public class LimitHttpTcpipAdapter extends CTFTcpipHttpAdapter
{
protected String ReadLine( ) throws Exception
{
int intChar;
int i = 0;
StringBuffer Result = new StringBuffer( 1024 );
/* read Header from input stream */
while ( true ) /* repeat until "newline"*/
{
intChar = Stream_in.read(); /* read a character */
switch ( intChar ) /* what character */
{
case -1: /* ... no character */
i = i + 1; /* error count */
if ( i > 3 ) /* more than threshold ? */
throw new EOFException(); /* ... yes, EOF */
else /* ... no */
Thread.sleep( 10 ); /* wait a bit */
break;
case 10: /* line feed */
BytesRead = BytesRead + Result.length();
/* data received so far */
return( Result.toString() ); /* all done */
case 13: /* carridge return */
BytesRead = BytesRead + 1; /* data received so far */
break;
default: /* real data */
i = 0; /* timeout count reset */
Result.append( (char) intChar ); /* append to string */
if ( Result.length( ) > 1024 )
throw new IOException( "missing cr-lf delimiter" );
} /* switch */
} /* while */
}
}
Support on the CTF toolkit stopped at the end of 2000, but
customers can protect themselves against http header overflow,
see workaround above.
The customer can put in what ever extra checks or controls they
wish. In the following example we have shown how a check can be
made for header records not exceeding 1024 characters in length
by creating a descendent of the CTFTcpipHttpAdapter this
descendent adapter would then be used in place of the
CTFTcpipHttpAdapter in the start up information for the webserver
i.e. in the web server ini file (or equivalent AddAdapter
statement in the server start up code):
[Adapter]
TCPIPHTTP=LimitHttpTcpipAdapter
Only the customer will know what limits they want to impose and
what they want to do if the limits are exceeded, since it depends
on the sending application, any additional information proxy's or
firewalls may add etc...