Pages in the Historical section of this site are provided for historical purposes, they are no longer maintained. Links may not work.

Original issue date: February 25, 1992
Last revised: September 19, 1997
Attached copyright statement

A complete revision history is at the end of this file.

The Computer Emergency Response Team/Coordination Center (CERT/CC) has received information concerning a vulnerability in AT&T TCP/IP Release 4.0 running on SVR4 systems for both the 386/486 and 3B2 RISC platforms.

The existing error, in the remote execution server /usr/etc/rexecd, has been corrected, and a new executable for rexecd is available from AT&T by calling 800-543-9935. Patches may be obtained outside the U.S. by calling your local technical support. The numbers associated with the fix are 5127 (3.5" media) and 5128 (5.25" media).

The problem does not exist in TCP/IP release 3.2 for SVR3, or any earlier versions of the TCP/IP product running on either the 3B2 or 386 platforms.

The version of TCP/IP distributed with SVR4 by UNIX(r) System Laboratories, Inc. (a subsidiary of AT&T) does not contain this vulnerability.

UNIX(r) is a registered trademark of UNIX System Laboratories, Inc.


I. Description

A vulnerability has been identified where root privileges may be accessed through the use of /usr/etc/rexecd.

II. Impact

A user on a remote machine may be able to run commands as root on the target host (the host running the affected /usr/etc/rexecd).

III. Solution

  1. Administrators of affected systems should execute, as root, the following command to immediately turn off access to rexecd until the new binary can be obtained.
    # chmod 400 /usr/etc/rexecd
    
  2. Obtain and install the new patch. The fix will be supplied as one diskette, and it comes with one page of instructions documenting the procedure to replace the existing /usr/etc/rexecd binary.

The CERT/CC wishes to thank Bradley E. Smith, Network & Technical Services, Bradley University, for bringing this vulnerability to our attention and for providing a corresponding solution. We would also like to thank AT&T for their very quick response to this problem.


Copyright 1992 Carnegie Mellon University.


Revision History
September 19,1997  Attached Copyright Statement
  • No labels