Original release date: December 12, 2001<BR>
Last revised: April 11, 2002<br>
Source: CERT/CC<BR>

<P>A complete revision history can be found at the end of this file.

<A NAME="affected">
<H3>Systems Affected</H3>
<UL>
<LI>Cisco applications running on a unpatched Sun Solaris OS
</LI>
<LI>Hewlett-Packard's HP-UX 
</LI>
<LI>IBM AIX versions 4.3 and earlier and 5.1
</LI>
<LI>SCO OpenServer 5.0.6a and earlier
</LI>
<LI>SGI IRIX 3.x
</LI>
<LI>Sun Solaris 8 and earlier
</LI>
</UL>

<A NAME="overview">
<H2>Overview</H2>

<P>Several applications use <i>login</i> for authentication to
the system. A remotely exploitable buffer overflow exists in <i>login</i>
derived from System V. Attackers can exploit this vulnerability to gain
root access to the server.

<A NAME="description">
<H2>I. Description</H2>

<P>Several implementations of <i>login</i> that are derived 
from System V allow a user to specify arguments such as environment 
variables to the process. An array of buffers is used to store these 
arguments. A flaw exists in the checking of the number of arguments 
accepted. This flaw permits the array of buffers to be overflowed.  

<P>On most systems, <i>login</i> is not suid; therefore, it runs as the
user who called it. If, however, <i>login</i> is called by an application
that runs with greater privileges than those of the user, such as telnetd
or rlogind, then the user can exploit this vulnerability to gain the
privileges of that program. In the case of telnetd or rlogind, root access
is gained.

<P>Since in.telnetd and in.rlogind are available over the network, a
remote attacker without any previous access to the system could use this
vulnerability to gain root access to the system.

<P>If a program that invokes <i>login</i> is suid (or sgid) USER_A, then
this can be exploited to gain the privileges of USER_A.

<p>An exploit exists and may be circulating.</p>
</P>


<A NAME="impact">
<H2>II. Impact</H2>

<p>This vulnerability can be remotely exploited to gain privileges of the
invoker of <i>login</i>. In the case of a program such as telnetd,
rlogind, or other suid root programs, root access is gained. </p>


<A NAME="solution">
<H2>III. Solution</H2>

<H4>Apply a patch from your vendor</H4>

<P><A HREF="#vendors">Appendix A</A> contains information provided by
vendors for this advisory.  As vendors report new information to the
CERT/CC, we will update this section and note the changes in our revision
history.  If a particular vendor is not listed below, we have not
received their comments. Please review <a
href="http://www.kb.cert.org/vuls/id/569272">VU#569272</a> for your
vendor's status or contact your vendor directly.</P>

<br>
<H4>Restrict access to login</H4>

<p>We recommend disabling TELNET, RLOGIN and other programs that use
<i>login</i> for authentication. Do not use programs that use a vulnerable
<i>login</i> for authentication. Note that some SSH applications can be
configured to use <i>login</i> for authentication. If this configuration 
is selected, then you will still be vulnerable.

<p>If you cannot disable the service, you can limit your exposure to
these vulnerabilities by using a router or firewall to restrict access to
port 23/TCP (telnet) and port 513/TCP (rlogin). Note that this does not
protect you against attackers from within your network.


<A NAME="vendors">
<H2>Appendix A. - Vendor Information</H2>

<P>This appendix contains information provided by vendors for this
advisory.  As vendors report new information to the CERT/CC, we will
update this section and note the changes in our revision history.  If a
particular vendor is not listed below, we have not received their
comments.</P>

<!-- end vendor -->

<A NAME="apple">
<H4>Apple Computer, Inc.</H4>

Mac OS X and Mac OS X Server are not vulnerable.

<!-- end vendor -->

<A NAME="caldera">
<H4>Caldera</H4>

We are not using a SystemV based /bin/login, we are using the BSD 
originated rlogin tools. All OpenLinux products are 'Not Vulnerable'.

<!-- end vendor -->

<A NAME="cisco">
<H4>Cisco</H4>

See <a 
href="http://www.cisco.com/warp/public/707/Solaris-bin-login.shtml">http://www.cisco.com/warp/public/707/Solaris-bin-login.shtml</a>

<!-- end vendor -->


<A NAME="compaq">
<H4>Compaq Computer Corporation</H4>

Compaq's Tru64 Software is not impacted by this reported problem.

<!-- end vendor -->

<A NAME="cray">
<H4>Cray Inc.</H4>

Cray Inc. has determined that its implementation of login is not 
vulnerable to the situation described in VU#569272.

<!-- end vendor -->

<A NAME="hp">
<H4>Hewlett-Packard</H4>

<p>HP-UX is NOT Exploitable. It is NOT a security issue with HP-UX. HP-UX does have a benign buffer overflow which is the only reason HP-UX is listed as "effected" above. 
In any case, the buffer overflow has been fixed by HP.

<!-- end vendor -->


<A NAME="IBM">
<H4>IBM</H4>

<p>IBM's AIX operating system, versions 4.3 and 5.1, are susceptible to
this vulnerability. We have prepared an emergency fix ("efix"),
"tsmlogin_efix.tar.Z", and it is available for downloading from:</p>

<a 
href="ftp://aix.software.ibm.com/aix/efixes/security">ftp://aix.software.ibm.com/aix/efixes/security</a>

<p>The APAR assignment for AIX 5.1 is IY26221. The APAR for AIX 4.3 is
IY26443. Both will be available soon. The "README" file at the above FTP
site will be updated to provide the official fix information and
availability.

<p>Update: Incomplete installation instructions were included in the first 
posting of the efix on Wednesday, 12 December 2001. The installation
instructions were rewritten and tarballed with the efixes. The efix
tarball was then reposted to the FTP download site on the afternoon
of Thursday, 13 December. An amended advisory reflecting the correct
instructions has also been issued. Customers may wish to consult
the amended advisory, or download the most recent efix, to obtain
the new instructions.

<p>IBM is developing an emergency fix for AIX 4.2.1 at Maintenance Level
06 (the last ML done). Also, we are developing efixes for AIX 4.3.3 at
maintenance levels 06 and 08.


<!-- end vendor -->

<A NAME="netbsd">
<H4>NetBSD</H4>

NetBSD does not use a System V derived login, and therefore, NetBSD is 
not vulnerable.

<!-- end vendor -->

<A NAME="redhat">
<H4>Red Hat</H4>

Red Hat Linux does not use a System V derived /bin/login, and is 
therefore not vulnerable to this.

<!-- end vendor -->

<A NAME="sco">
<H4>SCO</H4>

<p>Open UNIX 8 and UnixWare are not vulnerable to this login issue.
<br><br><a
href="ftp://stage.caldera.com/pub/security/openserver/CSSA-2001-SCO.40/CSSA-2001-SCO.40.txt">ftp://stage.caldera.com/pub/security/openserver/CSSA-2001-SCO.40/CSSA-2001-SCO.40.txt</a>

<!-- end vendor -->

<A NAME="sgi">
<H4>SGI</H4>

<p>SGI Has released a <a
href="http://www.kb.cert.org/vuls/id/JARL-54EQRL">security bulletin</a> to
address this issue.

<!-- end vendor -->

<A NAME="sun">
<H4>Sun Microsystems</H4>

<p>Sun has developed a fix and T-patches are being tested. Official
patches will be released shortly and Sun will issue a Sun Security
Bulletin when they are available.

<p>Update: Sun has released a <a
href="http://www.kb.cert.org/vuls/id/JARL-53NUCU">security bulletin and
patches</a> for this issue.</p>

<!-- end vendor -->


<HR NOSHADE>

<P>The CERT Coordination Center thanks <a
href="http://xforce.iss.net/alerts/advise105.php">Internet Security
Systems </a> and Sun Microsystems for the technical information they
provided.</P>

<P></P>

<HR NOSHADE>

<P>Feedback on this document can be directed to the author, <A 
HREF="mailto:cert@cert.org?subject=CA-2001-34%20Feedback%20VU%23569272">Jason 
A. Rafail</A>

<p></p>

<HR NOSHADE>

<p>References</p>
<ul>
<li>   <a
href="http://www.kb.cert.org/vuls/id/569272">http://www.kb.cert.org/vuls/id/569272</a>
<li>    <a
href="http://www.kb.cert.org/vuls">http://www.kb.cert.org/vuls</a>
</ul>

<P></P>

<!--#include virtual="/include/footer_nocopyright.html" -->

<P>Copyright 2001 Carnegie Mellon University.</P>

<P>Revision History
<PRE>
December 12, 2001: Initial Release
December 13, 2001: Update Hewlett-Packard Vendor Statement
December 14, 2001: Added SCO Vendor Statement
December 14, 2001: Updated IBM Vendor Statement
December 14, 2001: Updated Systems Affected
December 17, 2001: Updated Sun Microsystems Vendor Statement
December 18, 2001: Updated IBM Vendor Statement
December 18, 2001: Added SGI Vendor Statement
April 11, 2002: Added Cisco Vendor Statement
</PRE>