Enjoy.... ugh.
Dan
____________________________________________________________________________
Dan Yocum | Phone: (630) 840-8525
Computing Division OSS/FSS | Fax: (630) 840-6345 .~. L
Fermi National Accelerator Lab | email: yocum@fnal.gov /V\ I
P.O. Box 500 | WWW: www-oss.fnal.gov/~yocum/ // \\ N
Batavia, IL 60510 | "TANSTAAFL" /(
)\ U
________________________________|_________________________________ ^`~'^__X_
------- Forwarded Message
Return-Path: stox@fnal.gov
Received: from FNAL.FNAL.Gov (SYSTEM@fnal.fnal.gov [131.225.9.8])
by sapphire.fnal.gov (8.8.7/8.8.7) with ESMTP id NAA04891
for <yocum@sapphire.fnal.gov>; Wed, 17 Mar 1999 13:13:16 -0600
Received: from dcdsv0.fnal.gov ("port 41503"@dcdsv0.fnal.gov)
by FNAL.FNAL.GOV (PMDF V5.1-12 #3998)
with ESMTP id <01J8XS3BVVF00000MA@FNAL.FNAL.GOV> for
yocum@sapphire.fnal.gov;
Wed, 17 Mar 1999 13:13:13 -0600 CDT
Received: from localhost (stox@localhost) by dcdsv0.fnal.gov (8.7.5/8.7.1)
with ESMTP id NAA10196; Wed, 17 Mar 1999 13:13:12 -0600 (CST)
Date: Wed, 17 Mar 1999 13:13:11 -0600 (CST)
From: Ken Stox <stox@fnal.gov>
Subject: CIAC Bulletin J-035: Linux Blind TCP Spoofing (fwd)
To: csieh@fnal.gov, yocum@fnal.gov
Reply-to: stox@fnal.gov
Message-id: <Pine.GS4.4.05.9903171312520.5361-100000@dcdsv0.fnal.gov>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
X-Authentication-warning: dcdsv0.fnal.gov: stox owned process doing -bs
FYI...
- ---------- Forwarded message ----------
Date: Wed, 17 Mar 1999 10:38:50 -0800 (PST)
From: CIAC Mail User <ciac@rumpole.llnl.gov>
To: ciac-doe@rumpole.llnl.gov
Subject: CIAC Bulletin J-035: Linux Blind TCP Spoofing
[ For Public Release ]
- -----BEGIN PGP SIGNED MESSAGE-----
__________________________________________________________
The U.S. Department of Energy
Computer Incident Advisory Capability
___ __ __ _ ___
/ | /_\ /
\___ __|__ / \ \___
__________________________________________________________
INFORMATION BULLETIN
Linux Blind TCP Spoofing
March 16, 1999 18:00 GMT Number J-035
______________________________________________________________________________
PROBLEM: An implementation flaw has been identified in the Linux TCP/IP
stack.
PLATFORM: Linux kernels up to and including 2.0.35.
DAMAGE: Remote attackers could forge TCP connections without predicting
sequence numbers and pass data to the application layer before
a connection is established.
SOLUTION: Install upgrade.
______________________________________________________________________________
VULNERABILITY Risk is high. To eliminate this vulnerability, kernels below
ASSESSMENT: version 2.0.36 should upgrade as soon as possible.
______________________________________________________________________________
[ Start Network Associates Advisory ]
=====================================================================
Network Associates, Inc.
SECURITY ADVISORY
March 9, 1999
Linux Blind TCP Spoofing
======================================================================
SYNOPSIS
An implementation flaw in the Linux TCP/IP stack allows remote
Attackers to forge TCP connections without predicting sequence
numbers and pass data to the application layer before a connection
is established.
======================================================================
VULNERABLE HOSTS
This problem is present in Linux kernels up to and including 2.0.35.
Any distribution containing a kernel revision less than this is
vulnerable.
======================================================================
DETAILS
TCP is a reliable connection-oriented protocol which requires the
completion of a three way handshake to establish a connection. To
implement reliable and unduplicated delivery of data, the TCP
protocol uses a sequence based acknowledgment system. During connection
establishment each host selects an initial sequence number which is
sent in the first packet of the connection. Each subsequent byte
transmitted in the TCP connection is assigned a sequence number.
To prevent duplicate or invalid segments from impacting established
connections TCP utilizes a state based model. In a typical
client-server application, the client initiates a connection by
transmitting a TCP segment to a listening server process. This
causes the state of the process to move from the LISTEN state into
SYN_RECEIVE if a SYN flag is present. During this state the server
acknowledges the clients request setting both the SYN and ACK
flags. To complete the three way handshake the client acknowledges
the servers response, moving the server from SYN_RECEIVE to
ESTABLISHED state.
To establish a forged TCP session an attacker must have knowledge
of or be able to predict the initial sequence number that is selected
by the server. An implementation flaw in the Linux kernel allows
data to be delivered to the application layer before the handshake
has completed.
=====================================================================
TECHNICAL DETAILS
The combination of three flaws in the Linux TCP/IP implementation
contribute to the existence of a security vulnerability. Firstly,
Linux only verifies the acknowledgment number of incoming segments
if the ACK flag has been set. Linux also queues data from TCP
segments without acknowledgment information prior to the
completion of the three way handshake but after the initial SYN
has been acknowledged by the server. Finally, Linux passes data to
the application layer upon the receipt of a packet containing the
FIN flag regardless of whether a connection has been established.
Together, these flaws allow an attacker to spoof an arbitrary
connection and deliver data to an application without the need to
predict the servers initial sequence number.
According to the standard, there is only one case wherein a correct
TCP/IP stack can accept data in a packet that does not have the ACK
flag set --- the initial connection-soliciting SYN packet can
contain data, but must not have the ACK flag set. In any other case,
a data packet not bearing the ACK flag should be discarded.
When a TCP segment carries an ACK flag, it must have a correct
acknowledgement sequence number (which is the sequence number of the
next byte of data expected from the other side of the connection).
TCP packets bearing the ACK flag are verified to ensure that their
acknowledgement numbers are correct.
Vulnerable Linux kernels accept data segments that do not have the
ACK flag set. Because the ACK flag is not set, the acknowledgement
sequence number is not verified. This allows an attacker to send
data over a spoofed connection without knowing the target's current
(or initial) sequence number.
Linux does not deliver data received from a TCP connection when the
connection is in SYN_RECEIVE state. Thus, an attacker cannot
successfully spoof a TCP transaction to a Linux host without somehow
completing the TCP handshake. However, an implementation flaw in
some Linux kernels allows an attacker to bypass the TCP handshake
entirely, by "prematurely" closing it with a FIN packet.
When a FIN packet is received for a connection in SYN_RECEIVE state,
Linux behaves as if the connection was in ESTABLISHED state and moves
the connection to CLOSE_WAIT state. In the process of doing this,
data queued on the connection will be delivered to listening
applications. If the ACK flag is not set on the FIN segment, the
target's sequence number is not verified in the segment.
======================================================================
RESOLUTION
It is recommended that kernels below version 2.0.36 be upgraded to
eliminate this vulnerability.
Updated kernel packages for Red Hat Linux which are not vulnerable to
This problem are available from
http://www.redhat.com/support/docs/errata.html.
Both Debian and Caldera Linux have been contacted regarding this
vulnerability although no official response has been received.
The latest stable versions of the Linux kernel are available from
http://www.kernel.org.
======================================================================
CREDITS
Analysis and documentation of this problem was conducted by Anthony
Osborne with the Security Labs at Network Associates. This
Vulnerability was discovered on the October 5, 1998.
======================================================================
ABOUT THE NETWORK ASSOCIATES SECURITY LABS
The Security Labs at Network Associates hosts some of the most
Important research in computer security today. With over 30 published
Security advisories published in the last 2 years, the Network Associates
Security auditing teams have been responsible for the discovery of many of
The Internet's most serious security flaws. This advisory represents our
ongoing commitment to provide critical information to the security
community.
For more information about the Security Labs at Network Associates,
see our website at http://www.nai.com or contact us at
<seclabs@nai.com>.
======================================================================
[ End Network Associates Advisory ]
______________________________________________________________________________
CIAC wishes to acknowledge the contributions of Network Associates, Inc. for
the information contained in this bulletin.
______________________________________________________________________________
CIAC, the Computer Incident Advisory Capability, is the computer
security incident response team for the U.S. Department of Energy
(DOE) and the emergency backup response team for the National
Institutes of Health (NIH). CIAC is located at the Lawrence Livermore
National Laboratory in Livermore, California. CIAC is also a founding
member of FIRST, the Forum of Incident Response and Security Teams, a
global organization established to foster cooperation and coordination
among computer security teams worldwide.
CIAC services are available to DOE, DOE contractors, and the NIH. CIAC
can be contacted at:
Voice: +1 925-422-8193
FAX: +1 925-423-8002
STU-III: +1 925-423-2604
E-mail: ciac@llnl.gov
For emergencies and off-hour assistance, DOE, DOE contractor sites,
and the NIH may contact CIAC 24-hours a day. During off hours (5PM -
8AM PST), call the CIAC voice number 925-422-8193 and leave a message,
or call 800-759-7243 (800-SKY-PAGE) to send a Sky Page. CIAC has two
Sky Page PIN numbers, the primary PIN number, 8550070, is for the CIAC
duty person, and the secondary PIN number, 8550074 is for the CIAC
Project Leader.
Previous CIAC notices, anti-virus software, and other information are
available from the CIAC Computer Security Archive.
World Wide Web: http://www.ciac.org/
(or http://ciac.llnl.gov -- they're the same
machine)
Anonymous FTP: ftp.ciac.org
(or ciac.llnl.gov -- they're the same machine)
Modem access: +1 (925) 423-4753 (28.8K baud)
+1 (925) 423-3331 (28.8K baud)
CIAC has several self-subscribing mailing lists for electronic
publications:
1. CIAC-BULLETIN for Advisories, highest priority - time critical
information and Bulletins, important computer security information;
2. SPI-ANNOUNCE for official news about Security Profile Inspector
(SPI) software updates, new features, distribution and
availability;
3. SPI-NOTES, for discussion of problems and solutions regarding the
use of SPI products.
Our mailing lists are managed by a public domain software package
called Majordomo, which ignores E-mail header subject lines. To
subscribe (add yourself) to one of our mailing lists, send the
following request as the E-mail message body, substituting
ciac-bulletin, spi-announce OR spi-notes for list-name:
E-mail to ciac-listproc@llnl.gov or majordomo@rumpole.llnl.gov:
subscribe list-name
e.g., subscribe ciac-bulletin
You will receive an acknowledgment email immediately with a confirmation
that you will need to mail back to the addresses above, as per the
instructions in the email. This is a partial protection to make sure
you are really the one who asked to be signed up for the list in question.
If you include the word 'help' in the body of an email to the above
address,
it will also send back an information file on how to subscribe/unsubscribe,
get past issues of CIAC bulletins via email, etc.
PLEASE NOTE: Many users outside of the DOE, ESnet, and NIH computing
communities receive CIAC bulletins. If you are not part of these
communities, please contact your agency's response team to report
incidents. Your agency's team will coordinate with CIAC. The Forum of
Incident Response and Security Teams (FIRST) is a world-wide
organization. A list of FIRST member organizations and their
constituencies can be obtained via WWW at http://www.first.org/.
This document was prepared as an account of work sponsored by an
agency of the United States Government. Neither the United States
Government nor the University of California nor any of their
employees, makes any warranty, express or implied, or assumes any
legal liability or responsibility for the accuracy, completeness, or
usefulness of any information, apparatus, product, or process
disclosed, or represents that its use would not infringe privately
owned rights. Reference herein to any specific commercial products,
process, or service by trade name, trademark, manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation or favoring by the United States Government or the
University of California. The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government or the University of California, and shall not be used for
advertising or product endorsement purposes.
LAST 10 CIAC BULLETINS ISSUED (Previous bulletins available from CIAC)
J-024: Windows NT Remote Explorer
J-025: W97M.Footprint Macro Virus Detected
J-026: HP-UX rpc.pcnfsd Vulnerability
J-027: Digital Unix Vulnerabilities ( at , inc )
J-028: Sun Solaris Vulnerabilities (sdtcm_convert, man/catman, CDE)
J-029: Buffer Overflows in Various FTP Servers
J-030: Microsoft BackOffice Vulnerability
J-031: Debian Linux "Super" package Buffer Overflow
J-032: Windows Backdoors Update II:
J-033: SIG X server font path Vulnerability
J-034: Cisco 7xx TCP and HTTP Vulnerabilities
- -----BEGIN PGP SIGNATURE-----
Version: 4.0 Business Edition
iQCVAwUBNu/mx7nzJzdsy3QZAQGv3gQA3eVs+amlxGxs7US67TjhAOsRSii9dOXY
hqC5wvBjtu7V0EGnAWhQtxPFeVVOJ8CGz8OXqRt6h8SwRN0p/JhZ2NprTalwtlLz
QjQPkvE1Pfu6Nmp5B4OVrLfl/SVhJdpy3WUHD6S+Iub6uP6Y1f/vMPvEIKL5cBPt
Q6jyFW0ho/4=OWZr
- -----END PGP SIGNATURE-----
------- End of Forwarded Message
