Original issue date: January 27, 1997<BR>
Last revised: September 26, 1997<BR>
Updated copyright statement 

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

<P>The CERT Coordination Center has received reports of a vulnerability in
<I>talkd(8)</I> program used by <I>talk(1)</I>. By constructing DNS data
with particular characteristics, an intruder can remotely execute arbitrary
commands with root privileges. </P>

<P>An exploitation script for this problem has been made publicly available,
and we have received reports of successful root compromises involving the
use of this script. </P>

<P>You may be aware of advisories that have been published by other response
teams about this problem. Note that this advisory contains additional material
and covers additional aspects of the vulnerability related to a broader
set of problems of which this particular problem is only a specific instance.</P>

<P>The CERT/CC team recommends taking steps to solve the general problem
<A HREF="#I">(Sec. III.A)</A> and installing a vendor patch to address this particular instance
of the problem <A HREF="#II"> (Sec. III.B)</A>. Until you can install a patch, we urge you
to disable the talkd program(s) at your site. </P>

<P>We will update this advisory as we receive additional information. Please
check advisory files regularly for updates that relate to your site. 
</P>

<P>
<HR></P>

<H2>I. Description</H2>

<P>The CERT Coordination Center has received information of a vulnerability
in the <I>talkd(8)</I> program used by <I>talk(1)</I>. talk is a communication
program that copies text from one user's terminal to that of another, possibly
remote, user. talkd is the daemon that notifies a user that someone else
wishes to initiate a talk conversation. </P>

<P>As part of the talk connection, talkd does a DNS lookup for the name
of the host that the connection is being initiated from. Because there
is insufficient bounds checking on the buffer where the hostname is stored,
it is possible to overwrite the internal stack space of talkd. </P>

<P>It is possible to force talkd to execute arbitrary commands by carefully
manipulating the hostname information. As talkd runs with root privileges,
this may allow intruders to remotely execute arbitrary commands with these
privileges. </P>

<P>This attack requires an intruder to be able to make a network connection
to a vulnerable talkd program and provide corrupt DNS information to that
host. </P>

<P>This type of attack is a particular instance of the problem described
in CERT advisory CA-96.04, &quot;Corrupt Information from Network Servers,&quot;
available from </P>

<P><A HREF="http://www.cert.org/advisories/CA-96.04.corrupt_info_from_servers.html">http://www.cert.org/advisories/CA-96.04.corrupt_info_from_servers</A>
</P>

<P>Sites that use BIND 4.9.4 Patch Level 1 or later are NOT vulnerable
to the general class of hostname/ip-address-based buffer overflow attacks
(including this specific problem). </P>

<P>Be aware that there are different versions of the talkd program. Depending
on your system, the program may have any of the following names: talkd,
otalkd, ntalkd. </P>

<P>To determine whether your site allows talk sessions, check /etc/inetd.conf:</P>

<P># grep -i &quot;^[a-z]*talk&quot; /etc/inetd.conf </P>

<P>Note: An exploitation script for this problem has been made publicly
available. The CERT/CC has received reports of successful root compromises
involving the use of this script. </P>

<H2>II. Impact</H2>

<P>Intruders may be able to remotely execute arbitrary commands with root
privileges. They do not need access to an account on the system to exploit
this vulnerability. <BR>
</P>

<H2>III. Solution</H2>

<P>There are several options available to avoid this problem. We recommend
that all sites defend against the general class of problem (Sec. A) and
also install a patch from your vendor (Sec. B). Until you can install a
patch, we urge you to disable the talkd program(s) at your site (Sec C).
</P>

<P>Note that disabling the talkd program will defend against the particular
attack described in this advisory, but will not defend against the general
class of network-based attacks that manipulate hostname/ip-address information
to exploit a vulnerability. </P>
<A name="I">
<H3>A. Defend against the general class of problem</H3>

<P>In the general case, the problem described in this advisory is one in
which the attacker uses particular hostname/ip-address data to exploit
a vulnerability. The exploitation script mentioned above uses the specific
case of DNS attacks, but attackers can use other hostname/ip-address resolution
methods, such as NIS, /etc/hosts, and so on. </P>

<P>If the following measures are in place for all hostname/address transformation
techniques on your system, then your system would be immune not only to
this particular talkd exploit, but also to the general class of hostname/ip-address-based
buffer overflow attacks. </P>

<H4>1. DNS-Based Attacks</H4>

<P>To defend against a DNS-based attack, we encourage you to upgrade to
BIND 4.9.4 Patch level 1 or later (or your vendor's equivalent). The reason
is that BIND 4.9.4 Patch Level 1 conforms to the RFC (RFC 952) defining
valid hostname syntax (described in CERT advisory CA-96.04, &quot;Corrupt
Information from Network Servers&quot;). </P>

<P>Keep in mind that an upgrade to 4.9.5 may require a sendmail upgrade
because of the POSIX extensions in the latest version of BIND (described
in CA-96.04). For the latest available version of sendmail, please consult
the file </P>

<P><A HREF="ftp://ftp.cert.org/pub/latest_sw_versions/sendmail">ftp://ftp.cert.org/pub/latest_sw_versions/sendmail</A>
</P>

<H4>2. Other Network Information Services</H4>

<P>For systems that rely on additional name/address transformation techniques
(such as NIS, netinfo, and flat files like /etc/hosts), using the recommended
version of BIND may be insufficient since DNS lookups--and therefore hostname/ip-address
validation--may be bypassed in favor of the alternative technique (NIS,
netinfo, etc). Thus, we also encourage sites and vendors to include in
the suite of resolution techniques the same code that BIND uses to validate
hostnames and IP addresses. This code is described in the next section.
</P>

<H4>3. In-house Software</H4>

<P>Use the hostname and IP address validation subroutines available at
the locations listed below. Include them in all programs that use the result
of the hostname lookups in any way. </P>

<P><A HREF="ftp://ftp.cert.org/pub/tools/ValidateHostname/IsValid.c">ftp://ftp.cert.org/pub/tools/ValidateHostname/IsValid.c</A></P>

<P><A HREF="ftp://ftp.cert.dfn.de/pub/tools/net/ValidateHostname/IsValid.c">ftp://ftp.cert.dfn.de/pub/tools/net/ValidateHostname/IsValid.c</A>
</P>

<P>The IsValid.c file contains code for the IsValidHostname and IsValidIPAddress
subroutines. This code can be used to check host names and IP addresses
for validity according to RFCs 952 and 1123, as well as names containing
characters drawn from common practice, namely &quot;_&quot; and &quot;/&quot;.
</P>

<P>The following files are in the directory (from the README): </P>

<TABLE BORDER=1 CELLSPACING=0 CELLPADDING=0 WIDTH="100%" >
<TR>
<TD VALIGN=TOP>IsValid.1</TD>

<TD>The Lex/Flex file containing the code for<BR>
IsValidHostname and IsValidIPAddress<BR>
MD5 (IsValid.1 = 2d35040aacae4fb12906eblb48957776</TD>
</TR>

<TR>
<TD VALIGN=Top>IsValid-raw.c</TD>

<TD>The C File created by running flex<BR>
on is IsValid.l<BR>
MD5 (IsValid-raw.c) = 367c77d3ef84bc63a5c23d90eeb69330</TD>
</TR>

<TR>
<TD VALIGN=Top>IsValid.c</TD>

<TD>The edited file created by internalizing<BR>
variable and function definititions in <BR>
IsValid-raw.c<BR>
MD5 (IsValid.c) = ffe45f1256210aeb71691f4f7cdad27f</TD>
</TR>

<TR>
<TD Valign=Top>IsValid.diffs</TD>

<TD>The set of diffs between IsValid-raw.c<BR>
and IsValid.c<BR>
MD5 (IsValid.diffs) = 3619022cf31d735151f8e8c83cce3744</TD>
</TR>

<TR>
<TD valign=top>htest.c</TD>

<TD>A main routing for testing IsValidHostname <BR>
and IsValidIPAddress<BR>
MD5 (htest.c) = 2d50b2bffb537cc4e637dd1f07a187f4</TD>
</TR>
</TABLE>
<A NAME="II">
<H3>B. Install a patch from your vendor</H3>

<P>Below is a list of the vendors who have provided information. Details
are in Appendix A of this advisory; we will update the appendix as we receive
additional information. </P>

<P>If your vendor's name is not on this list, we have not received any
information. Please contact the vendor directly.

<P>Berkeley Software Design, Inc. (BSDI)<BR>
Cisco Systems<BR>
Data General Corporation<BR>
FreeBSD, Inc.<BR>
Hewlett-Packard Company<BR>
IBM Corporation<BR>
Linux<BR>
NEC Corporation<BR>
The Santa Cruz Operation, Inc. (SCO)<BR>
Silicon Graphics Inc. (SGI)<BR>
Solbourne (Grumman System Support)<BR>
Sun Microsystems, Inc. <BR>
</P>

<H3>C. Disable the talkd program(s)</H3>

Until you can install a vendor patch, disable any talkd programs found
in /etc/inetd.conf by commenting out those lines and restarting inetd.


<P>Example commands executed as root: </P>

<P># grep -i talk /etc/inetd.conf </P>

<TABLE CELLSPACING=0 CELLPADDING=0 WIDTH="85%" >
<TR>
<TD>talk</TD>

<TD>dgram</TD>

<TD>udp</TD>

<TD>wait</TD>

<TD>root</TD>

<TD>/usr/etc/in.talkd</TD>

<TD>in.talkd</TD>
</TR>
</TABLE>

<P>Comment out *all* references to talkd, otalkd or ntalkd.<BR>
(Comments in # /etc/inetd.conf begin with &quot;#&quot;.) </P>

<P>After editing /etc/inetd.conf, restart inetd. On many Unix systems,
this is done by sending the inetd process a HUP signal. </P>

<P>For SYSV:</P>

<P># ps -ef | grep inetd | grep -v grep<BR>
# kill -HUP {inetd PID} </P>

<P>For BSD:</P>

<P># ps -aux | grep inetd | grep -v grep<BR>
# kill -HUP {inetd PID}</P>

<P>Note that disabling talkd will solve the specific problem discussed
in this advisory. However it will not solve the general problem of network-based
attacks that manipulate hostname/ip-address information to exploit a vulnerability.
</P>

<P><HR>
<H2>Appendix A - Vendor Information</H2>


Below is a list of the vendors who have provided information for this advisory.
We will update this appendix as we receive additional information. If you
do not see your vendor's name, please contact the vendor directly. 
<H3>Berkeley Software Design, Inc. (BSDI)</H3>

<P>We have released an official patch (U210-035). It's available from our
<A HREF="mailto:patches@BSDI.COM">patches@BSDI.COM</A> mail-back server
or via anonymous ftp at: </P>

<P><A HREF="ftp://ftp.bsdi.com/bsdi/patches/patches-2.1/U210-035">ftp://ftp.bsdi.com/bsdi/patches/patches-2.1/U210-035</A>
</P>

<H3>Cisco Systems</H3>

<P>Cisco MultiNet for OpenVMS - not vulnerable. </P>

<H3>Data General Corporation</H3>

<P>Data General is not vulnerable. </P>

<H3>FreeBSD, Inc.</H3>

<P>We have released an advisory dated 1997-01-18, FreeBSD-SA-96:21. <BR>
The advisory can be found at</P>

<P><A HREF="ftp://freebsd.org/pub/CERT/advisories/FreeBSD-SA-96:21.talkd.asc">ftp://freebsd.org/pub/CERT/advisories/FreeBSD-SA-96:21.talkd.asc</A></P>

<P>Patches are available at</P>

<P><A HREF="ftp://freebsd.org/pub/CERT/patches/SA-96:21">ftp://freebsd.org/pub/CERT/patches/SA-96:21</A>
</P>

<H3>Hewlett-Packard Company</H3>

<P><BR>
HPSBUX9704-061<BR>
HEWLETT-PACKARD SECURITY BULLETIN: #00061 <BR>
Description: Security Vulnerability in talkd <BR>
Security Bulletins are available from the HP Electronic<BR>
Support Center via electronic mail. <BR>
User your browser to get to the HP Electronic Support<BR>
Center page at: </P>

<P><A HREF="http://us-support.external.hp.com">http://us-support.external.hp.com</A>
(for US, Canada, Asia-Pacific, &amp; Latin-America) <BR>
<A HREF="http://europe-support.external.hp.com">http://europe-support.external.hp.com</A>
(for Europe) </P>

<H3>IBM Corporation</H3>

<P>The version of talkd shipped with AIX is vulnerable to the conditions
described in this advisory. The APARs listed below will be available shortly.
It is recommended that the talkd daemon be turned off until the APARs are
applied. </P>

<TABLE ALIGN=LEFT CELLSPACING=0 CELLPADDING=0 >
<TR>
<TD>AIX 3.2:</TD>

<TD>APAR IX65474</TD>
</TR>

<TR>
<TD>AIX 4.1:</TD>

<TD>APAR IX65472</TD>
</TR>

<TR>
<TD>AIX 4.2:</TD>

<TD>APAR IX65473</TD>
</TR>
</TABLE>

<H4>To Order</H4>


APARs may be ordered using Electronic Fix Distribution (via FixDist) or
from the IBM Support Center. For more information on FixDist, reference
URL: <BR>
<A HREF="http://service.software.ibm.com/aixsupport/">http://service.software.ibm.com/aixsupport/</A>
</P>

<P>or send e-mail to <A HREF="mailto:aixserv@austin.ibm.com">aixserv@austin.ibm.com</A>
with a subject of &quot;FixDist&quot;. </P>

<P>IBM and AIX are registered trademarks of International Business Machines
Corporation. </P>

<H3>Linux</H3>


This bug was fixed in Linux NetKit 0.08 which is shipped with all reasonably
up to date Linux distributions. Linux users using NetKit 0.07 or earlier
should upgrade to NetKit 0.09. NetKit 0.09 has fixed other bugs and it
is strongly recommended Linux users upgrade from NetKit 0.08 to NetKit
0.09. This is available from

<P><A HREF="ftp://ftp.uk.linux.org/pub/linux/Networking/base/NetKit-0.09.tar.gz">ftp://ftp.uk.linux.org/pub/linux/Networking/base/NetKit-0.09.tar.gz</A>
</P>

<P>Some vendors have opted to issue NetKit 0.08 with additional fixes rather
than 0.09. Consult your vendor for detailed information. </P>

<P>The Linux community would like to thank David A Holland for his continuing
work on Linux network security. </P>

<H3>NEC Corporation</H3>

<TABLE CELLSPACING=0 CELLPADDING=0 >
<TR>
<TD>UX/4800</TD>

<TD>Vulnerable for all versions.</TD>
</TR>

<TR>
<TD>EWS-UX/V(Rel4.2MP) </TD>

<TD>Vulnerable for all versions.</TD>
</TR>

<TR>
<TD>EWS-UX/V(Rel4.2)</TD>

<TD>Vulnerable for all versions.</TD>
</TR>

<TR>
<TD>UP-UX/V(Rel4.2MP)</TD>

<TD>Vulnerable for all versions.</TD>
</TR>
</TABLE>

<P>Patches for these vulnerabilities are in progress. <BR>
Contacts for further information by e-mail: <BR>
<A HREF="mailto:UX48-security-support@nec.co.jp">UX48-security-support@nec.co.jp</A>


<H3>The Santa Cruz Operation, Inc. (SCO)</H3>


SCO is investigating the problem with talkd and will provide updated information
for this advisory as it becomes available. At this time SCO recommends
disabling talkd on your SCO system as described herein. 
<H3>Silicon Graphics Inc. (SGI)</H3>

For additional information refer to the Silicon Graphics Inc. Security
Advisory Number 19970701-01-PX. <BR>
The SGI anonymous FTP site is sgigate.sgi.com (204.94.209.1) or its mirror,
ftp.sgi.com. Security information and patches can be found in the ~ftp/security
and ~ftp/patches directories, respectfully. 
<H3>Solbourne (Grumman System Support)</H3>


We have examined the Solbourne implementation and found that it is vulnerable.
Solbourne distributed the Sun application under license. We will distribute
a Solbourne patch based on the Sun patch when it becomes available. For
the latest information on our patches go to <A HREF="http://ftp.nts.gssc.com/solbourne.html">http://ftp.nts.gssc.com/solbourne.html</A>

<P>The workaround of disabling in.talkd can be used.<BR>
as root: 

<PRE>/etc/inetd.conf - comment out the talkd program
# ps -aux | grep inetd | grep -v grep
# kill -HUP {inetd PID listed in output of last command} 
</PRE>
<H3>Sun Microsystems, Inc.</H3>

For additional information refer to the Sun Microsystems,<BR>
Inc. Security Bulletin Number #00147. <BR>
Patches are available to all Sun customers via World Wide Web at: 

<P><A
HREF="ftp://sunsolve1.sun.com/pub/patches/patches.html">ftp://sunsolve1.sun.com/pub/patches/patches.html</A>

<P>Customers with Sun support contracts can also obtain patches from local
Sun answer centers and SunSITEs worldwide. </P>

<P>Sun security bulletins are available via World Wide Web at: </P>

<P><A HREF="http://sunsolve1.sun.com/sunsolve/secbulletins">http://sunsolve1.sun.com/sunsolve/secbulletins</A>
</P>

<!--#include virtual="/include/footer_nocopyright.html" -->
<P>Copyright 1997 Carnegie Mellon University.</P>

<HR>

Revision History
<PRE>
September 26, 1997 Updated copyright statement
July 28, 1997 Appendix A - updated patch information for Silicon Graphics,
                                Inc. and Sun Microsystems, Inc.
May 8, 1997 Appendix A - updated patch information for Hewlett-Packard.
Feb. 7, 1997 Appendix A - added an entry for Cisco Systems.
</PRE>