-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

===============================================================================
>>                                                      CERT-NL, 01-Mar-2000 <<
>> All CERT-NL information has been moved to http://cert.surfnet.nl.  Links  <<
>> to CERT-NL information contained in this advisory are therefore outdated. <<
>>                                                                           <<
>> CERT-NL also has stopped the CERT-CC-Mirror service.  Due to this the     <<
>> links to the CERT-CC mirror are obsolete. Visit the CERT-CC site for the  <<
>> complete CERT-CC advisory texts:                     http://www.cert.org  <<
===============================================================================
===============================================================================
Security Advisory                                                       CERT-NL
===============================================================================
Author/Source : Don Stikvoort                               Index  :    S-95-10
Distribution  : World                                       Page   :          1
Classification: External                                    Version:          1
Subject       : SATAN / SANTA                               Date   :  05-Apr-95
===============================================================================

We announced you the arrival of the SATAN network/computer security 
scanner on Monday March 27th.

SATAN will be made publicly available 05 April 1995, 16:00 (Dutch time, 
GMT+2).

SATAN enables you to find the most obvious holes in your IP network's 
security very easily, so that you can remove these holes.

Of course SATAN also enables hackers to find these holes. They could have 
found these holes anyway, for there is no mystery to what SATAN is 
testing, but it does make life easier for hackers - as it does for you.

HENCE WE URGE YOU TO OBTAIN A COPY OF SATAN AND USE IT. 
You find SATAN at:  ftp://ftp.win.tue.nl/pub/security/satan*

Use SATAN inside your network and from the outside towards your network:
attacks most often originate from outside your network, but attacks from
the inside (either directly or indirectly) must not be ruled out. 

To get things straight: SATAN does NOT itself break into networks or
computers - it tries to detect security holes - not exploit them. 

(Those of you that disapprove of the name SATAN: inside the distribution 
kit is a program named 'repent' which changes both name and graphics to 
SANTA.)

Many people and CERT's, CERT-NL being one of them, have been beta-testing
SATAN in the last few weeks. We are not alone in being impressed. SATAN is
easy to install and handle. The WWW oriented user interface is a blessing. 

Much text has been written on SATAN the last week, almost none of it so 
good as the original documentation by Wietse Venema and Dan Farmer, 
authors of SATAN, which is strongly recommended. The exception to this 
rule is the outstanding advisory on SATAN by the Australian CERT (AUSCERT)
which we replicate below. 

=============================================================================
AA-95.03                AUSCERT  Advisory
       April 3, 1995
          An overview of SATAN
- - -----------------------------------------------------------------------------

There has been a lot of speculation in the internet community in
anticipation of the release of the Security Administrator Tool for
Analyzing Networks (SATAN).  AUSCERT have decided to release this advisory 
in order to dispel some of the confusion about the nature of the tool and 
its uses.  Questions that we will be answering in this document are:

   1.0 General
       1.1 What is SATAN?
       1.2 Does SATAN break into systems?
       1.3 Preparing for the release of SATAN
       1.4 What vulnerabilities does SATAN check for?
   2.0 Requirements
       2.1 What will you need in order to run SATAN?
   3.0 Availability
       3.1 Where can you get a copy of SATAN?
       3.2 When will SATAN be available?
   4.0 Post Release
       4.1 What are the possible effects of the release of a tool such as 
     SATAN?
       4.2 How can you tell if you are being scanned by someone using SATAN?

   Appendix A: Discussion of vulnerabilities identified by SATAN.

Much of the detail in this advisory is drawn from the pre-release SATAN 
documentation available via anonymous ftp from:
  ftp://ftp.win.tue.nl/pub/security/satan*

- - -------------------------------------------------------------------------------
1.0 General 

1.1 What is SATAN?

    SATAN (the Security Administrator Tool for Analyzing Networks) is a
    testing and reporting tool that collects a variety of information
    about networked hosts.

    SATAN has been designed to help systems administrators to automate the 
    process of testing their systems for known vulnerabilities that can be
    exploited via the network.  This will be particularly useful for
    networked systems with multiple hosts.  It will also be particularly
    useful to would-be intruders looking for systems with security holes. 
    Herein lies the controversy.

    SATAN is written mostly in Perl and utilizes a HTML Web browser such as
    Netscape, Mosaic or Lynx to provide the user interface.  This easy to
    use interface drives the scanning process and presents the results in
    summary format.  As well as reporting the presence of vulnerabilities,
    SATAN also gathers large amounts of general network information, such
    as which hosts are connected to subnets, what types of machines they
    are and which services they offer.

    SATAN can be configured to scan at 3 levels:

    light    
   This is the least intrusive scan. SATAN collects information from
   the DNS (Domain Name System), tries to establish what RPC (Remote
   Procedure Call) services the host offers and what file systems it
   shares via the network. With this information, SATAN finds out the
   general character of a host (file server, diskless workstation). 

    normal   (includes light scan probes) 
   At this level, SATAN probes for the presence of common network
   services including finger, remote login, ftp, WWW, Gopher and email.
   With this information, SATAN establishes the operating system type 
   and, where possible, the software release version. 

    heavy    (includes normal scan probes) 
   After it has found out what services are offered by the target,
   SATAN looks at them in more depth and does a more exhaustive scan 
   for network services offered by the target.  At this scanning level
   it checks for the vulnerabilities it is configured to check.  (see
   below for a list of these).

    These are the default settings for each level.  SATAN can easily be
    configured to do more or less scanning at each level.

    It is worth noting that SATAN can only scan hosts that are visible on
    the network.  External users can not probe hosts behind a suitably 
    configured firewall.


1.2 Does SATAN break into systems?

    SATAN is a reporting and analysis tool only.  As distributed, it does not 
    break into systems.  However SATAN is modular and easily extended, so after
    it is released modified versions could be designed to compromise systems.


1.3 Preparing for the release of SATAN

    SATAN tests for the presence of several known vulnerabilities, each of
    which has a workaround or solution available.  It is strongly
    recommended that you apply the workarounds and solutions discussed in
    Appendix A as soon as possible.  The discussions in Appendix A draw
    directly from the SATAN documentation.  

    Please note that securing your hosts against the vulnerabilities tested
    for by SATAN does not necessarily make your hosts secure.  It is
    imperative that you continue to take all of the usual security
    measures, like applying all security patches and performing regular
    monitoring activities.

    It is strongly recommended that you review all Unix hosts with the
    Unix Security Checklist listed in S-95-11.


1.4 What vulnerabilities does SATAN check for?

    SATAN comes configured to test for the following eleven vulnerabilities.

    1.    Are NFS file systems exported to unprivileged programs?
    2.    Are NFS file systems exported to arbitrary hosts?
    3.    Are NFS file systems exported via the portmapper?
    4.    Is there NIS password file access from arbitrary hosts?
    5.    Is there REXD access from arbitrary hosts?
    6.    Are arbitrary files accessible via TFTP?
    7.    Is remote shell access available from arbitrary hosts?
    8.    Is X server access control disabled?
    9.    Is there a writable anonymous FTP home directory?
    10.   Is there an insecure version of sendmail in use?
    11.   Is there an insecure version of wu-ftpd in use?

    None of these vulnerabilities/problems are new.  All of them are well
    known and have been used by intruders in the past. 

    SATAN makes spotting these vulnerabilities simple, both for the systems
    administrator and for anyone else looking for vulnerabilities on the
    network.  

    See Appendix A for a detailed overview of these vulnerabilities and their
    suggested solutions.

    SATAN is also configurable. You can add program modules to implement
    checks of your own devising.

- - -------------------------------------------------------------------------------
2.0 Requirements

2.1 What will you need in order to run SATAN?

    The pre-release implementation of SATAN is supported for SunOS 4.1.x,
    Solaris and IRIX.  The official release should support many more systems.
    In order to run it effectively you will need:

  32M memory
  20M disk space(Includes space for supplementary packages such as
           perl5 and Mosaic)

  HTML viewer (like Mosaic/Netscape/Lynx)
  perl5
  C compiler

- - ------------------------------------------------------------------------------
3.0 Availability

3.1 Where can you get a copy of SATAN?

    Right from the source:
    ftp://ftp.win.tue.nl/pub/security/satan*
    
    A pre-release documentation package is already available.  It contains 
    a copy of SATAN with all the processing software removed.  It is worth 
    getting a copy of this, installing it and having a look at the sample 
    database and documentation pages.  This is a good introduction to the
    product and should help answer any questions you have about it. 
    

3.2 When will SATAN be available.

    SATAN is scheduled for release on April 5, 14:00 GMT.  This is
    16:00 Dutch Time on the 5th of April. 

- - ------------------------------------------------------------------------------
4.0 Post Release 

4.1 What are the possible effects of the release of a tool such as SATAN?

    1) Increased interest in computer cracking by everyone including the
       media.
    2) Increased awareness of the specific vulnerabilites that SATAN tests
       for.
    3) Increased interest in the specific vulnerabilites that SATAN tests
       for by intruders and wannabees.
    4) Increased accessability/knowledge of what services are available on
       hosts visible on the network.
    5) Increased probing of sites by outsiders (both intentionally and 
       unintentionally). 


4.2 How can you tell if you are being scanned by someone using SATAN?

    As part of a heavy scan, SATAN will attempt to access many ports and 
    services in a very short space of time.  However, many UNIX network daemons
    do not provide sufficient logging to determine if a system is being probed 
    by SATAN.  

    For daemons started by inetd (rshd, telnetd, ftpd and so on) this
    level of logging can be provided by tcp_wrappers.  A heavy scan should 
    be identified readily in tcp_wrapper logs.

    As well as logging, tcp_wrappers also provide access control to most 
    network services.
  
    tcp_wrappers is available via anonymous ftp from:
    ftp://ftp.win.tue.nl/pub/security/tcp_wrappers*  (currently v7.2)

    We strongly recommend that you install and run tcp_wrappers.

    Other tools which also provide extra logging (plus other features including
    access control) include portmap_3, rpcbind-1.1 and logdaemon-4.7.  Details
    of these can be found in "Appendix A" as they directly provide workarounds 
    or solutions to certain vulnerabilities.

    CIAC (U.S. Dept. of Energy's Computer Incident Advisory Capability)
    have written a tool to monitor the network and identify the source of a
    port scanner (such as used by SATAN in heavy scan).  The program, 
    called Courtney, monitors connections to the ports probed by SATAN.  
    When a scan is noticed, the probing host is reported.  

    This tool is available via anonymous ftp from:
    ftp://ciac.llnl.gov/pub/ciac/sectools/unix/courtney*

==========================================================================
Appendix A      Discussion of vulnerabilities identified by SATAN

The discussions in this appendix draw directly from the SATAN documentation,
"Vulnerabilities -- a Tutorial."  The "See also" sections may include added
material and references not found in the original SATAN documentation.

It is suggested that the CERT advisories referenced in the vulnerability
information be reviewed to gain a greater understanding of the workarounds
and solutions to particular vulnerabilities.  Also the advisories often give
more detailed instructions for applying the solutions/workarounds.

- - ------------------------------------------------------------------------------
A.1             Writable FTP home directory

A.1.1  The Problem

When the FTP home directory of a UNIX host is writable, a remote intruder
can upload a .rhosts or .forward file to gain access to the system, or may
be able  to replace files. 

When a PC (DOS or MAC) permits anonymous users write access to its file
system, a remote intruder may be able to replace arbitrary programs or
configuration files, or corrupt the file system by filling it up. 

A.1.2  Fix for UNIX Systems

Make sure that the FTP home directory, and all system files and directories
below it, are owned by root. 

Make sure that they are not writable by anonymous users. As a rule, no file
or directory should be owned by the FTP account. 

A.1.3  Other tips for UNIX Systems

Change the login shell of the ftp account to /bin/false. 

A.1.4  See also

1) The UNIX Security Checklist (section 3.0) in S-95-11
2) CERT document about secure writable anonymous ftp from
   ftp://ftp.cert.org/pub/tech_tips/anonymous_ftp
3) CIAC document about anonymous ftp from
   ftp://ciac.llnl.gov/pub/ciac/ciacdocs/ciac2308*

- - ---------------------------------------------------------------------------
A.2             Unprivileged NFS access

A.2.1  Background

When an NFS client host wants to access a remote file or directory, its
operating system sends a request to the NFS server. The request specifies,
among others, a file identifier, the operation (read, write, change
permission, etc.), and the identity of the user on whose behalf the
operation is to be done. 

By default, the user identity is specified with the UNIX numeric user and
group ids. With this scheme, also called AUTH_UNIX, the server simply
believes anything that the client sends it. 

A.2.2  The Problem

An NFS request is nothing but a network message. Any user can run a program
that generates arbitrary NFS requests. Such programs have been available
for several years, and writing them does not require unusual programming
skills. 

When an NFS server accepts requests with AUTH_UNIX authentication from
unprivileged user programs, a malicious user can execute file access
requests on behalf of any user. Reason: with AUTH_UNIX authentication, the
user identity is nothing but a few user and group ID numbers in a network
message. 

A.2.3  Fix

The fix is to avoid AUTH_UNIX authentication and to use something that
involves cryptography. For example, secure NFS with DES or Kerberos
credentials. Unfortunately, many NFS implementations support AUTH_UNIX
authentication only. Consult your system documentation. 

A partial, but more common, solution is to configure the NFS server, and
where possible, the mount daemon, to accept requests only from privileged
system programs (such as UNIX kernels), and to reject NFS requests that are
sent by unprivileged user programs. 

   SunOS 4 administrators modify /etc/rc.local 
      rpc.mountd (no -n option) 
      echo "nfs_portmon/W1" | adb -w /vmunix
      /dev/kmem 

   SunOS 5 administrators modify /etc/system 
      set nfs:nfs_portmon = 1 

On other systems, the mountd command-line options differ, and the kernel
variable may be called nfsportmon or something similar. 

Note: rejecting NFS requests from unprivileged user programs does not
protect your servers against malicious superusers or against malicious PC
programs. 

A.2.4  Other tips

Where practical, export file systems read-only. 

Consider blocking ports 2049 (nfs) and 111 (portmap) on your routers. 

A.2.5  See also

1) The UNIX Security Checklist (section 2.5) in S-95-11

- - ---------------------------------------------------------------------------
A.3             Unrestricted NFS export

A.3.1  The Problem

When a file system is exported without restriction, an intruder can
remotely compromise user or system files, and then take over the machine.
For example, an intruder can remotely replace a system program or
configuration file, like .rhosts (to obtain interactive access) or .forward
(to obtain non-interactive access). 

A.3.2  Fix

Make sure all file exports specify an explicit list of clients or
netgroups.  Export file systems read-only where possible. 

A.3.3  Other tips

Some versions of the NFS mount daemon cannot expand large netgroups and
will export to the world anyway; see also Cert advisory CA-94:02. 

Check your vendor patch list.  

In NIS netgroup members, empty host fields are treated as wildcards and
cause the mount daemon to grant access to any host.  

Consider blocking ports 2049 (nfs) and 111 (portmap) on your routers. 

A.3.4  See also

1) The UNIX Security Checklist (section 2.5) in S-95-11

- - ---------------------------------------------------------------------------
A.4             NIS password file access

A.4.1  Background

The NIS (Network Information Service) implements network-wide access to
administrative information. Examples of databases (also called NIS maps)
that are shared via NIS: 

   the password file that describes what users have access to the system, 
   the table with names and addresses of hosts on the network, 
   electronic mail aliases. 

NIS databases are organized in domains. One NIS server can serve multiple
NIS domains. In order to perform a query, a client sends a request to a NIS
server and specifies 

   a NIS domain name, 
   the name of the database (NIS map) to be searched, 
   a search key. 

A.4.2  The Problem

Many NIS implementations provide no access control. Every host that asks
for information will receive a reply. In order to perform a query, one
needs to know the server's NIS domain name. Often, this name is easy to
guess, or it can be obtained via the bootparam network service. 

When the local network is accessible from other networks, a remote intruder
can collect password file information and run a password guessing program.
Many people (including Dan Klein) have demonstrated that people tend to
choose passwords that are easy to guess. 

A.4.3  Fix

Several vendors have added access control to their ypserv implementation.

Check your system documentation or vendor patch list. The control file is
sometimes called securenets. 

A.4.4  Workarounds

Run a portmapper with access control. 

A.4.5  Other tips

Consider blocking ports 111 (portmap) on your network gateway. This makes
attacks on NIS and NFS mount daemons much harder. 

Enforce a policy for choosing passwords by installing an alternative passwd
command, for example anlpasswd. 

A.4.6  See also

1) The UNIX Security Checklist (sections 2.3, 2.12 and 4.4 ) in S-95-11
2) CERT advisory CA-92:13.SunOS.NIS.vulnerability
   CERT advisory CA-93:01.REVISED.HP.NIS.ypbind.vulnerability
    ftp://ftp.cert.org/pub/cert_advisories/{CA-92:13*,CA-93:01*}
3) anlpasswd is available from 
     ftp://info.mcs.anl.gov/pub/systems/anlpasswd* (currently v2.3)

- - ---------------------------------------------------------------------------
A.5             Portmapper exports

A.5.1  Background

In order to perform operations via the NFS network file system protocol, a
client host sends NFS requests to the NFS server daemon with: 

   an NFS file handle that specifies the target of the operation, 
   the operation (lookup, read, write, change permissions), 
   the user on whose behalf the request is sent. 

When an NFS client host wants to access a remote file system for the first
time, it first needs to obtain an NFS file handle. To this end, the client
host sends a mount request to the server's mount daemon. The server's
mount daemon verifies that the client host has permission to access the
requested file system. When the mount daemon grants access, it sends a
(directory) file handle back to the NFS client. 

A.5.2  The problem

For efficiency reasons, most NFS export restrictions are enforced by the
mount daemon. Individual file access operations are handled by the NFS
daemon, and the origin of such requests is examined only in special cases
such as remote superuser access. 

Instead of talking directly to the mount daemon, a malicious NFS client can
ask the server's portmapper daemon to forward the request to the mount
daemon. When the mount daemon receives the request from the portmapper, the
mount daemon will believe that the request comes from the file server, and
not from the malicious client.

When the file server exports file systems to itself (for example, because
the server is a netgroup member) the mount daemon grants access and replies
with a file handle. The portmapper forwards the handle to the malicious
client. From now on, the client can talk directly to the server's NFS
daemon to access the directory and all files below it. 

A.5.3  Fix

Run a portmapper (or rpcbind program in case of System V.4) that does not
forward mount etc. requests. Consult your vendor's patch list. See also:
Cert Advisory 94:15. 

A.5.4  Other tips

Export file systems read-only where possible. 

Consider blocking ports 2049 (nfs) and 111 (portmap) on your routers. 

A.5.5  See also

1) CERT Advisory CA-94:15.NFS.Vulnerabilities
    ftp://ftp.cert.org/pub/cert_advisories/CA-94:15.*
2) Wietse Venema has written a portmapper with access control plus other
   enhancements, portmap_3.  Also available is a replacement rpcbind 
   (currently v1.1). These can can be found on:
     ftp://ftp.win.tue.nl/pub/security/{portmap_3*,rpcbind*}

- - ---------------------------------------------------------------------------
A.6             REXD access

A.6.1  Background

The rexd service, and the on client program, implement remote command
execution via the network. To the extent that it is possible, the complete
client environment, including working directory and environment variables,
is made available on the remote system. 

A.6.2  The problem

A request for remote command execution contains, among others, the command
to be executed, and a user and group id. By default, the rexd server
believes everything that the client sends it. An intruder can exploit the
service to execute commands as any user (except perhaps root). The typical
rexd server has no protection against abuse: most implementations have no
provision for access control, nor do they require that the client uses a
privileged network port. 

A.6.3  Fix

Disable the rexd service. Usually this is accomplished by editing the 
inetd.conf file, and by sending a HUP signal to the inetd process. 

Some rexd implementations can be configured to use a more secure protocol.
Consult your manual pages for details. 

A.6.4  See also

1) CERT advisory CA-92:05.AIX.REXD.Daemon.vulnerability
    ftp://ftp.cert.org/pub/cert_advisories/CA-92:05*
- - ---------------------------------------------------------------------------
A.7             Remote shell access

A.7.1  The Problem

When the remote login/remote shell service trusts every host on the
network, a malicious superuser on an arbitrary host can gain access as any
user (except perhaps  root). Once inside, the intruder can replace system
programs or configuration files (such as the password file) and take over
the machine. 

In addition, there are guest or administrative accounts that might not have
passwords protecting the account, which allows anyone to remotely login as
that user and gain access to the host. 

A.7.2  Fix

Remove the wildcard (+) from the /etc/hosts.equiv file. Be careful with the
use of the -@group netgroup feature, as there are many incorrect
implementations. 

Delete or disable any accounts without a password from the system or NIS
password file. 

A.7.3  Other tips

Give system accounts such as bin and daemon a non-functional shell (such as 
/bin/false) and put them in the /etc/ftpusers file so they cannot use ftp. 

A.7.4  See also

1) The UNIX Security Checklist (sections 2.3 and 2.4) in S-95-11
2) Wietse Venema's logdaemon package, includes replacements for rsh and rlogin
   daemons.  By default these versions do not accept wild cards in host.equiv 
   or .rhost files.  They also have an option to disable user .rhost files. 
   logdaemon is available via anonymous ftp from:
    ftp://ftp.win.tue.nl/pub/security/logdaemon* (currently v4.7)

- - -----------------------------------------------------------------------------
A.8            Sendmail vulnerabilities

A.8.1  The Problem

With almost every sendmail version that was built before February 1995, a
malicious user can gain unauthorized privileges by exploiting newlines in
command-line arguments or in the process environment. Intruders need to
have access to an account on your system to exploit this problem. 

In addition, pre-8.6.10 versions of sendmail that support IDENT (RFC 1413)
functionality have a problem that could allow an intruder to gain
unauthorized access to your system remotely (that is, without having access
to an account on the system). 

A.8.2  Fix

Ensure that you are running the most recent version of sendmail.

A.8.3  See also

1) The UNIX Security Checklist (section 2.13) in S-95-11
2) CERT advisory CA-95:05.sendmail.vulnerabilities
    ftp://ftp.cert.org/pub/cert_advisories/CA-95:05*

- - -----------------------------------------------------------------------------
A.9            TFTP file access

A.9.1  Background

The TFTP (trivial file transfer protocol) service provides remote access to
files, without asking for a password. It is typically used for the
initialization of diskless computers, of X terminals, or of other dedicated
hardware. 

A.9.2  The problem

When the TFTP daemon does not limit access to specific files or hosts, a
remote intruder can use the service to obtain copies of the password file
or of other system or user files, or to remotely overwrite files. 

A.9.3  Fix

Restrict TFTP access to only limited subtree of the file system. Consult
your tftpd manual pages for details.  When no access restriction is
possible, restrict TFTP access by using a tcp wrapper. 

A.9.4  See also

1) The UNIX Security Checklist (section 2.9) in S-95-11
2) AUSCERT Advisory SA-93.05.tftp.Attacks:
    ftp://ftp.auscert.org.au/pub/auscert/auscert-advisory/SA-93.05.tftp.Attacks 
3) CERT advisories
    CA-91:18.Active.Internet.tftp.Attacks
    CA-91:19.AIX.TFTP.daemon.vulnerability
    ftp://ftp.cert.org/pub/cert_advisories/{CA-91:18*,CA-91:19*}
4) If your version of tftp does not have a chroot option (which would allow
   you to limit access to a directory subtree) then you can use the 
   chrootuid program to provide this functionality.  It is available from:
    ftp://ftp.win.tue.nl/pub/security/chrootuid* (currently v1.2)

- - ----------------------------------------------------------------------------
A.10           X server access

A.10.1  Background

The X Window system implements an environment where applications use the
network to interact with a user workstation's display, keyboard and mouse.
There are two classes of programs: 
The X server: the program that manages the user's workstation display and
input devices.  X clients: the applications that run on the user's
workstation or elsewhere in the network. 

A.10.2  The problem

When the X server permits access from arbitrary hosts on the network, a
remote intruder can connect to the X server and: 

   Read the user's keyboard, including any passwords that the user types, 
   Read everything that is sent to the screen, 
   Write arbitrary information to the screen, 
   Start or terminate arbitrary applications, 
   Take control of the user's session. 

A.10.3  Fix

Remove all instances of the xhost + command from the system-wide Xsession
file, from user .xsession files, and from any application programs or shell
scripts that use the X window system. 

A.10.4  Other tips

Use the X magic cookie mechanism or equivalent. With logins under control
of xdm, you turn on authentication by editing the xdm-config file and
setting  the DisplayManager*authorize attribute to true.  When granting
access to the screen from another machine, use the xauth command in
preference to the xhost command. 

A.10.5  See also

1) The UNIX Security Checklist (section 8) in S-95-11

- - ----------------------------------------------------------------------------
A.11          WU-FTPD Vulnerability
 (This may not be listed in the pre-release documentation version)

A.11.1  Background

The wuarchive FTPD daemon (or WU-FTPD) is a highly modified version (and
significantly larger) version of FTPD that provides extra logging, limited
remote command support, and other features to the standard BSD version of
FTPD. The additional code adds greatly to the complexity, and multiple
significant software bugs have been found in it. 

A.11.2  The problem

There is a race condition in the code, as well as a bug in the SITE EXEC
command, that allows anyone (remote or local) root access on a host running
a vulnerable FTPD daemon. Support for anonymous FTP is not required to
exploit this vulnerability. 

A.11.3  Fix

Don't use extended or modified FTPD daemons unless they are necessary -
vendors code is typically more stable and secure.  Upgrade to a more recent
version of WU-FTPD; it can be found at the  wuarchive ftp site.  Restrict
FTP access by using a tcp wrapper. 

A.11.4  See also: 

1) The UNIX Security Checklist (section 3) in S-95-11
2) CERT Advisory 93:06.wuarchive.ftpd.vulnerability and
   CERT Advisory 94:07.wuarchive.ftpd.trojan.horse
    ftp://ftp.cert.org/pub/cert_advisories/{CA-93:06*,CA-94:07*}
==============================================================================
CERT-NL is the Computer Emergency Response Team for SURFnet customers. SURFnet
is the Dutch network for educational, research and related institutes. CERT-NL
is a member of the Forum of Incident Response and Security Teams (FIRST).

All CERT-NL material is available under:
  http://cert.surfnet.nl/

In case of computer or network security problems please contact your local
CERT/security-team or CERT-NL  (if your institute is NOT a SURFnet customer
please address the appropriate (local) CERT/security-team).

CERT-NL is one/two hour(s) ahead of UTC (GMT) in winter/summer,
i.e. UTC+0100 in winter and UTC+0200 in summer (DST).

   Email:     cert-nl@surfnet.nl     ATTENDED REGULARLY ALL DAYS
   Phone:     +31 302 305 305        BUSINESS HOURS ONLY
   Fax:       +31 302 305 329        BUSINESS HOURS ONLY
   Snailmail: SURFnet bv
              Attn. CERT-NL
              P.O. Box 19035
              NL - 3501 DA  UTRECHT
              The Netherlands

NOODGEVALLEN:    06 22 92 35 64      ALTIJD BEREIKBAAR
EMERGENCIES : +31 6 22 92 35 64      ATTENDED AT ALL TIMES
CERT-NL'S EMERGENCY PHONENUMBER IS ONLY TO BE USED IN CASE OF EMERGENCIES:
THE SURFNET HELPDESK OPERATING THE EMERGENCY NUMBER HAS A *FIXED*
PROCEDURE FOR DEALING WITH YOUR ALERT AND WILL IN REGULAR CASES RELAY IT
TO CERT-NL IN AN APPROPRIATE MANNER. CERT-NL WILL THEN CONTACT YOU.
===============================================================================

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1i

iQA/AwUBOL6IETSYjBqwfc9jEQJpcwCgpAUpwDVmssPv/Q+m+ZyLziQBLJ4Anizd
IvNqvW60z5QjZM2Vv7al+BWK
=81dd
-----END PGP SIGNATURE-----