Vulnerability

    inetd

Affected

    Data General (DG/UX 5.4R3.10)

Description

    Following is based on BlackHats Security Advisory.  The inetd (see
    also: "man  8 inetd")  daemon in  any UNIX  like operating  system
    is used  to listen  to any  incoming connections  on the  ports as
    specified in  the /etc/inetd.conf  (also described  in the  manual
    page)  file  and  start  the  service   connected  to that port as
    specified in the same file.  The purpose of having one such  super
    daemon is to save memory space and make it easier to startup other
    daemons  as  well.   The  overhead  of  the necessary fork/exec is
    justified for a normally loaded system.  Processes started by  the
    inetd daemon include, but are not limited to, "ftp", "telnet"  and
    "finger".

    When  using  the  nmap  scanner,  developed  by  Fyodor to try and
    determine  what  operating  system  the  remote target is actually
    running  (using  a  technique  named  "stack fingerprinting"), the
    inetd daemon  will change  to such  a state  that it  is therafter
    no longer  capable of  spawning new  services.   The only  current
    solution being a  restart of the  inetd daemon by  the operator of
    the Data General system.

    Affected are Data General systems running DG/UX R4.20MU04/05 and
    R4.11MU06 (M88k) and perhaps other versions of this operating
    system as well (unable to verify this because these were
    unavailable).

    The following  is the  minimal command  used to  actually deny all
    services started by inetd (which listens to the ftp port (21)):

        nmap -O -p 21 <target>

    To be on the safe side  (and the actual command issued which  lead
    to this  advisory) you  can also  use the  following stealty  scan
    of the reserved ports of the Data General DG/UX system:

        nmap -v -O -sS -p1-1023 <target>

Solution

    The  only  exception  able  to  verify  was  the  DG/UX  B2 system
    (R4.20MU04), which seemed not effected  by this scan.  Black  Hats
    notified  Data  General  of  this  problem  in  the second week of
    february, and finally received patch tcpip_R4.20MU04.p11.