Vulnerability

    Hursley Software Laboratories Consumer Transaction Framework

Affected

    HSLCTF 1.0 for AIX

Description

    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...