Subject: Re: FreeBSD Security Advisory: FreeBSD-SA-98:03.ttcp
To: Manuel Bouyer <bouyer@antioche.lip6.fr>
From: Jason Thorpe <thorpej@nas.nasa.gov>
List: tech-security
Date: 05/15/1998 08:23:00
On Fri, 15 May 1998 12:37:55 +0200 
 Manuel Bouyer <bouyer@antioche.lip6.fr> wrote:

 > Does someone know if we are affected by this ?

No, NetBSD does not have T/TCP.

 > 
 > On May 14, FreeBSD Security Officer wrote
 > > -----BEGIN PGP SIGNED MESSAGE-----
 > > 
 > > =============================================================================
 > > FreeBSD-SA-98:03                                            Security Advisory
 > >                                                                 FreeBSD, Inc.
 > > 
 > > Topic:          Problems with TTCP
 > > 
 > > Category:       core
 > > Module:         kernel
 > > Announced:      1998-05-14
 > > Affects:        FreeBSD 2.1.*
 > > 		FreeBSD 2.2.*,
 > > 		FreeBSD-stable before 1998/05/14 and
 > > 		FreeBSD-current before 1998/05/05 suffer from this problem.
 > > Corrected:      FreeBSD-3.0-current as of 1998/05/14
 > > 		FreeBSD-2.2-stable as of 1998/05/05
 > > FreeBSD only:   No. Any other system incorporating TTCP extentions may be
 > >                 affected.
 > > 
 > > Patches:        ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-98:03/
 > > 
 > > I.   Background    
 > > 
 > > 
 > >      RFC 1644 provides an extension to TCP called TCP Extensions for
 > >      Transactions, or shortly T/TCP. It provides a way of bypassing
 > >      the standard three-way handshake found in TCP, thus speeding up
 > >      transactions.
 > >      T/TCP has been incorporated in FreeBSD since FreeBSD 2.0.5.
 > > 
 > > II.  Problem Description
 > > 
 > >      An accelerated open is initiated by a client by sending a new
 > >      TCP option, called CC, to the server.  The kernel keeps a
 > >      special cache for each host it communicated with, among others
 > >      containing the value of the last CC option used by the client.
 > >      A new accelerated open is allowed when the CC sent is larger
 > >      than the one in the per-host cache. Thus one can spoof complete
 > >      connections.
 > >      
 > > III. Impact
 > >      
 > >      The hole can be used to obtain unauthorized acces to the system
 > >      by spoofing connections to the r*-services. This can only be
 > >      done in the case where an .rhost file and/or a host.equiv file
 > >      is used as the sole method of authentication.
 > > 
 > > IV.  Workaround
 > > 
 > >      Disable all r-* services. Note that setting the kernel variable
 > >      net.inet.tcp.rfc1644 to 0 does not solve the problem. This
 > >      variable controls whether the system will initiate rfc1644
 > >      based connections and does not affect the ability to receive
 > >      such connections.
 > > 
 > > V.   Solution
 > > 
 > > 
 > >      Apply the following patch, rebuild your kernel, install it
 > >      and reboot your system. the patch is valid for 2.2.* as well as
 > >      2.2-stable and 3.0-current systems.
 > > 
 > >      The patch below can be found on
 > > 	ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-98:03/
 > > 
 > >   Index: tcp_input.c
 > >   ===================================================================
 > >   RCS file: /home/cvsup/freebsd/CVS/src/sys/netinet/tcp_input.c,v
 > >   retrieving revision 1.74
 > >   retrieving revision 1.75
 > >   diff -u -r1.74 -r1.75
 > >   --- tcp_input.c	1998/04/24 10:08:57	1.74
 > >   +++ tcp_input.c	1998/05/04 17:59:52	1.75
 > >   @@ -680,7 +680,9 @@
 > >    		 * - otherwise do a normal 3-way handshake.
 > >    		 */
 > >    		if ((to.to_flag & TOF_CC) != 0) {
 > >   -		    if (taop->tao_cc != 0 && CC_GT(to.to_cc, taop->tao_cc)) {
 > >   +		    if (tp->t_state & TF_NOPUSH &&
 > >   +			taop->tao_cc != 0 && CC_GT(to.to_cc, taop->tao_cc)) {
 > >   +
 > >    			taop->tao_cc = to.to_cc;
 > >    			tp->t_state = TCPS_ESTABLISHED;
 > >    
 > >   
 > >   
 > > =============================================================================
 > > FreeBSD, Inc.
 > > 
 > > Web Site:                       http://www.freebsd.org/
 > > Confidential contacts:          security-officer@freebsd.org
 > > Security notifications:         security-notifications@freebsd.org
 > > Security public discussion:     freebsd-security@freebsd.org
 > > PGP Key:                ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc
 > > 
 > > Notice: Any patches in this document may not apply cleanly due to
 > >         modifications caused by digital signature or mailer software.
 > >         Please reference the URL listed at the top of this document
 > >         for original copies of all patches if necessary.
 > > =========================================================================
 > > 
 > > -----BEGIN PGP SIGNATURE-----
 > > Version: 2.6.2
 > > 
 > > iQCVAwUBNVtEuVUuHi5z0oilAQGIqQP9FTHxJWljLSFskaF34/GvPBfCuxiJdxPo
 > > LLPG3GF2NsUFYSwuj5PnM61n6ByX9Ryoq/FO5kXr6nF6gOt3H+1YbgCUmWfpx5aN
 > > GFRdanUzuVJ7ipusehwmgULMXknaDJksV+j7VyaYfa0VheYwbMXKkzdG03/0kioz
 > > 2Scwf+BJ8CI=
 > > =F0vQ
 > > -----END PGP SIGNATURE-----
 > > 
 > > This is the moderated mailing list freebsd-announce.
 > > The list contains announcements of new FreeBSD capabilities,
 > > important events and project milestones.
 > > See also the FreeBSD Web pages at http://www.freebsd.org
 > > 
 > > 
 > > To Unsubscribe: send mail to majordomo@FreeBSD.org
 > > with "unsubscribe freebsd-announce" in the body of the message
 > 
 > -- 
 > --
 > Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
 >      {Net,Free}BSD: 21 ans d'experience feront toujours la difference
 > --

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                            Home: +1 408 866 1912
NAS: M/S 258-5                                       Work: +1 650 604 0935
Moffett Field, CA 94035                             Pager: +1 650 428 6939