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

SecurityTracker
Archives


 


Category:   Application (Generic)  >   Telnet Vendors:   [Multiple Authors/Vendors]
(Sun Issues Fix) Re: Telnet Daemons May Give Remote Users Root Level Access Privileges
SecurityTracker Alert ID:  1003938
SecurityTracker URL:  http://securitytracker.com/id/1003938
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Apr 1 2002
Impact:   Execution of arbitrary code via network, Root access via network, User access via network
Fix Available:  Yes  Vendor Confirmed:  Yes  

Description:   TESO reported that many BSD-derived Telnet daemons (servers) contain a vulnerability that may allow a remote user to obtain root level access on the server.

The vulnerability is reportedly due to a buffer overflow in the telnet option handling.

The following systems are reported to be vulnerable:

BSDI 4.x default, FreeBSD [2345].x default, IRIX 6.5, Linux netkit-telnetd < 0.14, NetBSD 1.x default, OpenBSD 2.x, Solaris 2.x sparc, and "almost any other vendor's telnetd".

A remote user can send a specially formatted option string to the remote telnet server and overwrite sensitive memory, causing arbitrary code to be executed with the privileges of the telnet server (which is typically root level privileges).

Telnet options are reportedly processed by the 'telrcv' function. The results of the parsing, which are to be send back to the client, are stored in the 'netobuf' buffer. It is apparently assumed that the reply data is smaller than the buffer size, so no bounds checking is performed. By using a combination of options, especially the 'AYT' Are You There option, it is possible for a remote user to append data to the buffer. It is reported that the characters that can be written to the buffer are limited, which makes constructing a successful exploit difficult.

The report states that a working exploit has been developed for BSDI, NetBSD and FreeBSD. However, the exploit was not released.

Impact:   A remote user can execute arbitrary code on the server with the privileges of the telnet server, which is typically root level privileges.
Solution:   Sun has issued the following patches:

SPARC

Solaris 2.5.1 with patch 103640-39 or later
Solaris 2.6 with patch 106049-04 or later
Solaris 2.6 and SEAM 1.0 without patch 110057-04 or later
Solaris 7 with patch 107475-04 or later
Solaris 7 and SEAM 1.0 without patch 110057-04 or later
Solaris 8 with patch 110668-03 or later
Solaris 8 and SEAM 1.0.1 without patch 110060-10 or later

Intel

Solaris 2.5.1 with patch 103641-39 or later
Solaris 2.6 with patch 106050-04 or later
Solaris 2.6 and SEAM 1.0 with patch 110058-04 or later
Solaris 7 with patch 107476-04 or later
Solaris 7 and SEAM 1.0 with patch 110058-04 or later
Solaris 8 with patch 110669-03 or later
Solaris 8 and SEAM 1.0.1 with patch 110061-10 or later

Cause:   Boundary error
Underlying OS:  UNIX (Solaris - SunOS)
Underlying OS Comments:  Solaris 2.5.1, 2.6, 7, and 8

Message History:   This archive entry is a follow-up to the message listed below.
Jul 18 2001 Telnet Daemons May Give Remote Users Root Level Access Privileges



 Source Message Contents

Subject:  Buffer Overflow in "in.telnetd" or "telnetd" Process


DOCUMENT ID: 28063 
SYNOPSIS: Buffer Overflow in "in.telnetd" or "telnetd" Process 
DETAIL DESCRIPTION: 

Sun(sm) Alert Notification 

     Sun Alert ID: 28063 

     Synopsis: Buffer Overflow in "in.telnetd" or "telnetd" Process 

     Category: Security 

     Product: Solaris 
     BugIDs: 4484541, 4483514 
     Avoidance: Patch 

     State: Resolved 
     Date Released: 21-Mar-2001 
     Date Closed: 21-Mar-2001 
     Date Modified: 

1. Impact 

Unprivileged local and remote users may be able to kill the "in.telnetd"
daemon. The "in.telnetd" daemon is normally spawned by the inetd daemon
(see inetd(1M)) in response to a connection to the TELNET port as
indicated by the /etc/services file (see services(4)).
Sun does not believe that this issue can be exploited on Solaris systems
to gain elevated privileges. 

This issue is described in CERT Advisory CA-2001-21 'Buffer Overflow in
telnetd' (see
http://www.cert.org/advisories/CA-2001-21.html). 

2. Contributing Factors 

This issue can occur in the following releases: 

SPARC 

     Solaris 2.5.1 without patch 103640-39 
     Solaris 2.6 without patch 106049-04 
     Solaris 2.6 and SEAM 1.0 without patch 110057-04 
     Solaris 7 without patch 107475-04 
     Solaris 7 and SEAM 1.0 without patch 110057-04 
     Solaris 8 without patch 110668-03 
     Solaris 8 and SEAM 1.0.1 without patch 110060-10 

Intel 

     Solaris 2.5.1 without patch 103641-39 
     Solaris 2.6 without patch 106050-04 
     Solaris 2.6 and SEAM 1.0 without patch 110058-04 
     Solaris 7 without patch 107476-04 
     Solaris 7 and SEAM 1.0 without patch 110058-04 
     Solaris 8 without patch 110669-03 
     Solaris 8 and SEAM 1.0.1 without patch 110061-10 

Note: both the default "in.telnetd" shipped with Solaris and the
Kerberos modified version of "telnetd" as shipped with the unbundled
product "Solaris Enterprise Authentication Mechanism (SEAM)" are
affected. 

3. Symptoms 

Should the described issue occur, the affected "in.telnetd" or "telnetd"
process may die due to a segmentation violation ("SEGV" signal).
A core file will be generated in the root directory ("/"). 


SOLUTION SUMMARY: 

4. Relief/Workaround 

To minimize the risk imposed by this issue, restrict incoming telnet
connections to origins within trustworthy networks, e.g. by using
firewalls, packet filtering software, or TCP-wrappers. 

Alternatively, it might be considered to completely disable incoming
telnet connections by commenting out the "in.telnetd" related line in
the "/etc/inetd/inetd.conf" file using the hash ("#") character as in
the following example: 

    #telnet  stream  tcp6    nowait  root    /usr/sbin/in.telnetd
in.telnetd              

In addition, for Solaris with SEAM, the kerberized version of the telnet
service might be disabled by commenting out the related line in the
"/etc/inetd/inetd.conf" file as in the following example: 

    #telnet stream  tcp      nowait  root    /usr/krb5/lib/telnetd
telnetd            

For the changes to become active, the "inetd" process has to be sent a
"HUP" signal by issuing the following command as root user: 

    # kill -HUP <pid of
inetd>                                                

(here, "<pid of inetd>" has to be replaced by the process ID of the
"inetd" process). 

5. Resolution 

SPARC 

     Solaris 2.5.1 with patch 103640-39 or later 
     Solaris 2.6 with patch 106049-04 or later 
     Solaris 2.6 and SEAM 1.0 without patch 110057-04 or later 
     Solaris 7 with patch 107475-04 or later 
     Solaris 7 and SEAM 1.0 without patch 110057-04 or later 
     Solaris 8 with patch 110668-03 or later 
     Solaris 8 and SEAM 1.0.1 without patch 110060-10 or later 

Intel 

     Solaris 2.5.1 with patch 103641-39 or later 
     Solaris 2.6 with patch 106050-04 or later 
     Solaris 2.6 and SEAM 1.0 with patch 110058-04 or later 
     Solaris 7 with patch 107476-04 or later 
     Solaris 7 and SEAM 1.0 with patch 110058-04 or later 
     Solaris 8 with patch 110669-03 or later 
     Solaris 8 and SEAM 1.0.1 with patch 110061-10 or later 

This Sun Alert notification is being provided to you on an "AS IS"
basis. Sun makes no representations, warranties, or guaranties as to the
quality, suitability, truth, accuracy or completeness of any of the
information contained herein. This Sun Alert notification may contain
information provided by third parties. ANY AND ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE HEREBY
DISCLAIMED. The issues described in this Sun
Alert notification may or may not impact your system(s). 

BY ACCESSING THIS DOCUMENT YOU ACKNOWLEDGE THAT SUN SHALL IN NO EVENT BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, PUNITIVE, OR CONSEQUENTIAL
DAMAGES THAT ARISE OUT OF YOUR USE OR FAILURE TO USE THE INFORMATION
CONTAINED HEREIN. 

This Sun Alert notification contains Sun proprietary and confidential
information. It is being provided to you pursuant to the provisions of
your Confidential Disclosure Agreement or the confidentiality provisions
of your agreement to purchase services from Sun. In the event that you
do not have one of the above-referenced agreements with Sun, this
information is provided pursuant to the confidentiality provisions of
the Sun.com Terms of Use. This Sun Alert notification may only be used
for the purposes contemplated by these agreements. 

Copyright 2001, 2002 Sun Microsystems, Inc., 901 San Antonio Road, Palo
Alto, CA 94303 U.S.A. All rights reserved.


 
 


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 2019, SecurityGlobal.net LLC