SecurityTracker.com
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 


Category:   Application (Commerce)  >   Consumer Transaction Framework Vendors:   IBM
IBM's Consumer Transaction Framework Can Be Crashed By Remote Users
SecurityTracker Alert ID:  1001134
SecurityTracker URL:  http://securitytracker.com/id/1001134
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Mar 22 2001
Impact:   Denial of service via network
Fix Available:  Yes  Vendor Confirmed:  Yes  Exploit Included:  Yes  
Version(s): HSLCTF 1.0 for AIX
Description:   Defcom Labs discovered a vulnerability in IBM's Hursley Software Laboratories Consumer Transaction Framework (CTF), a Java-based commerce system. Remote users can cause the software and related services (such as e-mail) to crash.

As described in Defcom Labs Advisory def-2001-12, the Hursley Software Laboratories CTF HTTP web server contains a vulnerability that could allow a remote attacker to crash the web server and interconnected objects such as a mail server.

An "endless" HTTP GET request will crash the HTTP service, and can also bring down the internal mail system:

GET / HTTP/1.0\r\nhost:www.foo.org\r\nreferrer: aaaaaaa..aaaaaaaaaaaa

If a remote user generates a script that continues to send characters to the socket, the server will eventually exhaust all memory on the server.

Impact:   A remote user can cause the server to exhaust all memory on the server.
Solution:   A workaround has been supplied by IBM Hursley Software Laboratories (see the source message for the code).
Vendor URL:  www.ibm.com (Links to External Site)
Cause:   Resource error
Underlying OS:  UNIX (AIX)

Message History:   None.


 Source Message Contents

Subject:  def-2001-12: Hursley Software Laboratories Consumer Transaction


======================================================================
                  Defcom Labs Advisory def-2001-12

  Hursley Software Laboratories Consumer Transaction Framework DoS

Release Date: 2001-03-20
======================================================================
------------------------=[Brief Description]=-------------------------
The HSLCTF HTTP object contains a flaw that could allow a malicious
attacker to crash the web object and interconnected objects (eg. SMTP)

------------------------=[Affected Systems]=--------------------------
- HSLCTF 1.0 for AIX

----------------------=[Detailed Description]=------------------------
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: http://www.securityfocus.com/bid/2465

---------------------------=[Workaround]=-----------------------------
The following workaround example has been supplied by IBM Hursley
Software Laboratories, see "Vendor Response":


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                 */
    }
  }

-------------------------=[Vendor Response]=--------------------------
This issue was brought to the vendor's attention on the 9th of
November, 2000 and a workaround was received by the vendor on the 20th
of March 2001. The Danish Vendor replied (translated to English):

"Support on the CTF toolkit stopped at the end of 2000, but customers
can protect themselves against http header overflow, see workaround
from IBM hursley"

Hursley Software Laboratories replied:

"The customer can put in what ever extra checks or controls they wish.
In the following example I 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..."

======================================================================
            This release was brought to you by Defcom Labs

              labs@defcom.com             www.defcom.com
======================================================================

 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2022, SecurityGlobal.net LLC