1. Gentoo Linux Security Advisory
Version Information
Advisory Reference GLSA 200701-13 / fetchmail
Release Date January 22, 2007
Latest Revision January 22, 2007: 01
Impact normal
Exploitable remote
Package Vulnerable versions Unaffected versions Architecture(s)
net-mail/fetchmail < 6.3.6 >= 6.3.6 All supported architectures
Related bugreports: #160463
Synopsis
Fetchmail has been found to have numerous vulnerabilities allowing for Denial of Service and password disclosure.
2. Impact Information
Background
Fetchmail is a remote mail retrieval and forwarding utility.
Description
Neil Hoggarth has discovered that when delivering messages to a message delivery agent by means of the "mda" option, Fetchmail passes a NULL pointer to the ferror() and fflush() functions when refusing a message. Isaac Wilcox has discovered numerous means of plain-text password disclosure due to errors in secure connection establishment.
Impact
An attacker could deliver a message via Fetchmail to a message delivery agent configured to refuse the message, and crash the Fetchmail process. SMTP and LMTP delivery modes are not affected by this vulnerability. An attacker could also perform a Man-in-the-Middle attack, and obtain plain-text authentication credentials of users connecting to a Fetchmail process.
3. Resolution Information
Workaround
There is no known workaround at this time.
Resolution
All fetchmail users should upgrade to the latest version:
Code Listing 3.1
# emerge --sync
# emerge --ask --oneshot --verbose ">=net-mail/fetchmail-6.3.6"
4. References
CVE-2006-5867
CVE-2006-5974
Print
Updated January 22, 2007
Summary: This is a Gentoo Linux Security Advisory
security@gentoo.org
Contact Address
Donate to support our development efforts.
VR Hosted
Tek Alchemy
SevenL.net
php|architect
Search for in Google by Dino
The Best Communities Underground - Hacking etico
Mis Sitios en Internet
jueves, enero 25, 2007
Fetchmail: Denial of Service and password disclosure GENTOO
Mod_auth_kerb: Denial of Service GENTOO
1. Gentoo Linux Security Advisory
Version Information
Advisory Reference GLSA 200701-14 / mod_auth_kerb
Release Date January 22, 2007
Latest Revision January 22, 2007: 01
Impact normal
Exploitable remote
Package Vulnerable versions Unaffected versions Architecture(s)
net-www/mod_auth_kerb < 5.0_rc7-r1 >= 5.0_rc7-r1 All supported architectures
Related bugreports: #155782
Synopsis
Mod_auth_kerb is vulnerable to a buffer overflow possibly allowing a Denial of Service.
2. Impact Information
Background
Mod_auth_kerb is an Apache authentication module using Kerberos.
Description
Mod_auth_kerb improperly handles component byte encoding in the der_get_oid() function, allowing for a buffer overflow to occur if there are no components which require more than one byte for encoding.
Impact
An attacker could try to access a Kerberos protected resource on an Apache server with an incorrectly configured service principal and crash the server process. It is important to note that this buffer overflow is not known to allow for the execution of code.
3. Resolution Information
Workaround
There is no known workaround at this time.
Resolution
All mod_auth_kerb users should upgrade to the latest version:
Code Listing 3.1
# emerge --sync
# emerge --ask --oneshot --verbose ">=net-www/mod_auth_kerb-5.0_rc7-r1"
4. References
CVE-2006-5989
Print
Updated January 22, 2007
Summary: This is a Gentoo Linux Security Advisory
security@gentoo.org
Contact Address
Donate to support our development efforts.
VR Hosted
Tek Alchemy
SevenL.net
php|architect
Mod_auth_kerb: Denial of Service GENTOO
1. Gentoo Linux Security Advisory
Version Information
Advisory Reference GLSA 200701-14 / mod_auth_kerb
Release Date January 22, 2007
Latest Revision January 22, 2007: 01
Impact normal
Exploitable remote
Package Vulnerable versions Unaffected versions Architecture(s)
net-www/mod_auth_kerb < 5.0_rc7-r1 >= 5.0_rc7-r1 All supported architectures
Related bugreports: #155782
Synopsis
Mod_auth_kerb is vulnerable to a buffer overflow possibly allowing a Denial of Service.
2. Impact Information
Background
Mod_auth_kerb is an Apache authentication module using Kerberos.
Description
Mod_auth_kerb improperly handles component byte encoding in the der_get_oid() function, allowing for a buffer overflow to occur if there are no components which require more than one byte for encoding.
Impact
An attacker could try to access a Kerberos protected resource on an Apache server with an incorrectly configured service principal and crash the server process. It is important to note that this buffer overflow is not known to allow for the execution of code.
3. Resolution Information
Workaround
There is no known workaround at this time.
Resolution
All mod_auth_kerb users should upgrade to the latest version:
Code Listing 3.1
# emerge --sync
# emerge --ask --oneshot --verbose ">=net-www/mod_auth_kerb-5.0_rc7-r1"
4. References
CVE-2006-5989
Sun JDK/JRE: Multiple vulnerabilities GENTOO
1. Gentoo Linux Security Advisory
Version Information
Advisory Reference GLSA 200701-15 / java
Release Date January 22, 2007
Latest Revision January 22, 2007: 01
Impact normal
Exploitable remote
Package Vulnerable versions Unaffected versions Architecture(s)
dev-java/sun-jdk < 1.4.2.13, < 1.5.0.09 >= 1.4.2.13, >= 1.5.0.09 All supported architectures
dev-java/sun-jre-bin < 1.4.2.13, < 1.5.0.09 >= 1.4.2.13, >= 1.5.0.09 All supported architectures
Related bugreports: #158659
Synopsis
Multiple unspecified vulnerabilities have been identified in Sun Java Development Kit (JDK) and Java Runtime Environment (JRE).
2. Impact Information
Background
The Sun Java Development Kit (JDK) and the Sun Java Runtime Environment (JRE) provide the Sun Java platform.
Description
Chris Evans has discovered multiple buffer overflows in Sun JDK and Sun JRE possibly related to various AWT or font layout functions. Tom Hawtin has discovered an unspecified vulnerability in Sun JDK and Sun JRE relating to unintended applet data access. He has also discovered multiple other unspecified vulnerabilities in Sun JDK and Sun JRE allowing unintended Java applet or application resource acquisition.
Impact
An attacker could entice a user to run a specially crafted Java applet or application that could read, write, or execute local files with the privileges of the user running the JVM; access data maintained in other Java applets; or escalate the privileges of the currently running Java applet or application allowing for unauthorized access to system resources.
3. Resolution Information
Workaround
There is no known workaround at this time.
Resolution
All Sun Java Development Kit users should upgrade to the latest version:
Code Listing 3.1
# emerge --sync
# emerge --ask --oneshot --verbose "dev-java/sun-jdk"
All Sun Java Runtime Environment users should upgrade to the latest version:
Code Listing 3.2
# emerge --sync
# emerge --ask --oneshot --verbose "dev-java/sun-jre-bin"
4. References
CVE-2006-6731
CVE-2006-6736
CVE-2006-6737
CVE-2006-6745
Adobe Acrobat Reader: Multiple vulnerabilities GENTOO
1. Gentoo Linux Security Advisory
Version Information
Advisory Reference GLSA 200701-16 / acroread
Release Date January 22, 2007
Latest Revision January 22, 2007: 01
Impact normal
Exploitable remote
Package Vulnerable versions Unaffected versions Architecture(s)
app-text/acroread < 7.0.9 >= 7.0.9 All supported architectures
Related bugreports: #159874
Synopsis
Adobe Acrobat Reader is vulnerable to remote code execution, Denial of Service, and cross-site scripting attacks.
2. Impact Information
Background
Adobe Acrobat Reader is a PDF reader released by Adobe.
Description
Adobe Acrobat Reader in stand-alone mode is vulnerable to remote code execution via heap corruption when loading a specially crafted PDF file.
The browser plugin released with Adobe Acrobat Reader (nppdf.so) does not properly handle URLs, and crashes if given a URL that is too long. The plugin does not correctly handle JavaScript, and executes JavaScript that is given as a GET variable to the URL of a PDF file. Lastly, the plugin does not properly handle the FDF, xml, xfdf AJAX request parameters following the # character in a URL, allowing for multiple cross-site scripting vulnerabilities.
Impact
An attacker could entice a user to open a specially crafted PDF file and execute arbitrary code with the rights of the user running Adobe Acrobat Reader. An attacker could also entice a user to browse to a specially crafted URL and either crash the Adobe Acrobat Reader browser plugin, execute arbitrary JavaScript in the context of the user's browser, or inject arbitrary HTML or JavaScript into the document being viewed by the user. Note that users who have emerged Adobe Acrobat Reader with the "nsplugin" USE flag disabled are not vulnerable to issues with the Adobe Acrobat Reader browser plugin.
3. Resolution Information
Workaround
There is no known workaround at this time.
Resolution
All Adobe Acrobat Reader users should upgrade to the latest version:
Code Listing 3.1
# emerge --sync
# emerge --ask --oneshot --verbose ">=app-text/acroread-7.0.9"
4. References
CVE-2006-5857
CVE-2007-0044
CVE-2007-0045
CVE-2007-0046
CVE-2007-0048
Print
Updated January 22, 2007
Summary: This is a Gentoo Linux Security Advisory
security@gentoo.org
Contact Address
Donate to support our development efforts.
VR Hosted
Tek Alchemy
SevenL.net
php|architect
libgtop: Privilege escalation GENTOO
1. Gentoo Linux Security Advisory
Version Information
Advisory Reference GLSA 200701-17 / libgtop
Release Date January 23, 2007
Latest Revision January 23, 2007: 01
Impact normal
Exploitable local
Package Vulnerable versions Unaffected versions Architecture(s)
gnome-base/libgtop < 2.14.6 >= 2.14.6 All supported architectures
Related bugreports: #162169
Synopsis
libgtop improperly handles filenames, possibly allowing for the execution of arbitrary code.
2. Impact Information
Background
libgtop facilitates the libgtop_daemon, which is used by GNOME to obtain information about remote systems.
Description
Liu Qishuai discovered that glibtop_get_proc_map_s() in sysdeps/linux/procmap.c does not properly allocate memory for storing a filename, allowing certain filenames to cause the buffer to overflow on the stack.
Impact
By tricking a victim into executing an application that uses the libgtop library (e.g. libgtop_daemon or gnome-system-monitor), a local attacker could specify a specially crafted filename to be used by libgtop causing a buffer overflow and possibly execute arbitrary code with the rights of the user running the application.
3. Resolution Information
Workaround
There is no known workaround at this time.
Resolution
All libgtop users should upgrade to the latest version:
Code Listing 3.1
# emerge --sync
# emerge --ask --oneshot --verbose ">=gnome-base/libgtop-2.14.6"
4. References
CVE-2007-0235
xine-ui: Format string vulnerabilities
1. Gentoo Linux Security Advisory
Version Information
Advisory Reference GLSA 200701-18 / xine-ui
Release Date January 23, 2007
Latest Revision January 23, 2007: 01
Impact normal
Exploitable remote
Package Vulnerable versions Unaffected versions Architecture(s)
media-video/xine-ui < 0.99.5_pre20060716 >= 0.99.5_pre20060716 All supported architectures
Related bugreports: #161558
Synopsis
xine-ui improperly handles format strings, possibly allowing for the execution of arbitrary code.
2. Impact Information
Background
xine-ui is a skin-based user interface for xine. xine is a free multimedia player. It plays CDs, DVDs, and VCDs, and can also decode other common multimedia formats.
Description
Due to the improper handling and use of format strings, the errors_create_window() function in errors.c does not safely write data to memory.
Impact
An attacker could entice a user to open a specially crafted media file with xine-ui, and possibly execute arbitrary code.
3. Resolution Information
Workaround
There is no known workaround at this time.
Resolution
All xine-ui users should upgrade to the latest version:
Code Listing 3.1
# emerge --sync
# emerge --ask --oneshot --verbose ">=media-video/xine-ui-0.99.5_pre20060716"
4. References
CVE-2007-0254
OpenLDAP: Insecure usage of /tmp during installation
1. Gentoo Linux Security Advisory
Version Information
Advisory Reference GLSA 200701-19 / openldap
Release Date January 23, 2007
Latest Revision January 23, 2007: 01
Impact low
Exploitable local
Package Vulnerable versions Unaffected versions Architecture(s)
net-nds/openldap < 2.1.30-r10, < 2.2.28-r7, < 2.3.30-r2 >= 2.1.30-r10, >= 2.2.28-r7, >= 2.3.30-r2 All supported architectures
Related bugreports: #159508
Synopsis
A shell script commonly released with OpenLDAP makes insecure usage of files in /tmp during the emerge process.
2. Impact Information
Background
OpenLDAP Software is an open source implementation of the Lightweight Directory Access Protocol.
Description
Tavis Ormandy of the Gentoo Linux Security Team has discovered that the file gencert.sh distributed with the Gentoo ebuild for OpenLDAP does not exit upon the existence of a directory in /tmp during installation allowing for directory traversal.
Impact
A local attacker could create a symbolic link in /tmp and potentially overwrite arbitrary system files upon a privileged user emerging OpenLDAP.
3. Resolution Information
Workaround
There is no known workaround at this time.
Resolution
All OpenLDAP users should upgrade to the latest version:
Code Listing 3.1
# emerge --sync
# emerge --ask --oneshot --verbose "net-nds/openldap"
Print
Updated January 23, 2007
Summary: This is a Gentoo Linux Security Advisory
security@gentoo.org
Contact Address
Donate to support our development efforts.
VR Hosted
Tek Alchemy
SevenL.net
php|architect
Centericq: Remote buffer overflow in LiveJournal handling
1. Gentoo Linux Security Advisory
Version Information
Advisory Reference GLSA 200701-20 / centericq
Release Date January 24, 2007
Latest Revision January 24, 2007: 01
Impact normal
Exploitable remote
Package Vulnerable versions Unaffected versions Architecture(s)
net-im/centericq <= 4.21.0-r2 All supported architectures
Related bugreports: #160793
Synopsis
Centericq does not properly handle communications with the LiveJournal service, allowing for the remote execution of arbitrary code.
2. Impact Information
Background
Centericq is a text mode menu-driven and window-driven instant messaging interface.
Description
When interfacing with the LiveJournal service, Centericq does not appropriately allocate memory for incoming data, in some cases creating a buffer overflow.
Impact
An attacker could entice a user to connect to an unofficial LiveJournal server causing Centericq to read specially crafted data from the server, which could lead to the execution of arbitrary code with the rights of the user running Centericq.
3. Resolution Information
Workaround
There is no known workaround at this time.
Resolution
Currently, Centericq is unmaintained. As such, Centericq has been masked in Portage until it is again maintained.
Code Listing 3.1
# emerge --ask --verbose --unmerge "net-im/centericq"
4. References
CVE-2007-0160
MIT Kerberos 5: Arbitrary Remote Code Execution
1. Gentoo Linux Security Advisory
Version Information
Advisory Reference GLSA 200701-21 / mit-krb5
Release Date January 24, 2007
Latest Revision January 24, 2007: 01
Impact high
Exploitable remote
Package Vulnerable versions Unaffected versions Architecture(s)
app-crypt/mit-krb5 < 1.5.2 >= 1.5.2 All supported architectures
Related bugreports: #158810
Synopsis
Multiple vulnerabilities in MIT Kerberos 5 could potentially result in the execution of arbitrary code.
2. Impact Information
Background
MIT Kerberos 5 is a suite of applications that implement the Kerberos network protocol.
Description
The Kerberos administration daemon, and possibly other applications using the GSS-API or RPC libraries, could potentially call a function pointer in a freed heap buffer, or attempt to free an uninitialized pointer.
Impact
A remote attacker may be able to crash an affected application, or potentially execute arbitrary code with root privileges.
3. Resolution Information
Workaround
There is no known workaround at this time.
Resolution
All MIT Kerberos 5 users should upgrade to the latest version:
Code Listing 3.1
# emerge --sync
# emerge --ask --oneshot --verbose ">=app-crypt/mit-krb5-1.5.2"
4. References
CVE-2006-6143
CVE-2006-6144
wget (denial of service)
rPSA-2007-0011-1 wget
rPath Update Announcements announce-noreply at rpath.com
Tue Jan 23 03:45:02 EST 2007
Previous message: rPSA-2007-0007-1 kdenetwork
Next message: rPSA-2007-0012-1 ed
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
--------------------------------------------------------------------------------
rPath Security Advisory: 2007-0011-1
Published: 2007-01-23
Products: rPath Linux 1
Rating: Informational
Exposure Level Classification:
Indirect Deterministic Denial of Service
Updated Versions:
wget=/conary.rpath.com at rpl:devel//1/1.10.2-4-0.1
References:
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6719
https://issues.rpath.com/browse/RPL-930
Description:
Previous versions of the wget package can crash if they contact a
malicious FTP server. No further vulnerability is enabled by this
minor flaw; system security is not threatened in any way.
ed (symlink attack)
rPSA-2007-0012-1 ed
rPath Update Announcements announce-noreply at rpath.com
Tue Jan 23 03:45:58 EST 2007
Previous message: rPSA-2007-0011-1 wget
Next message: rPSA-2007-0013-1 poppler tetex tetex-afm tetex-dvips tetex-fonts tetex-latex tetex-xdvi
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
--------------------------------------------------------------------------------
rPath Security Advisory: 2007-0012-1
Published: 2007-01-23
Products: rPath Linux 1
Rating: Minor
Exposure Level Classification:
Local User Non-deterministic Vulnerability
Updated Versions:
ed=/conary.rpath.com at rpl:devel//1/0.4-1-0.1
References:
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6939
https://issues.rpath.com/browse/RPL-962
Description:
Previous versions of the ed package are vulnerable to a symlink
attack which allows a local attacker to overwrite arbitrary files
writeable by the user running ed with contents provided by the
user running the ed program.
poppler (denial of service, code execution)
rPSA-2007-0013-1 poppler tetex tetex-afm tetex-dvips tetex-fonts tetex-latex tetex-xdvi
rPath Update Announcements announce-noreply at rpath.com
Tue Jan 23 03:47:10 EST 2007
Previous message: rPSA-2007-0012-1 ed
Next message: rPSA-2007-0014-1 libgtop
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
--------------------------------------------------------------------------------
rPath Security Advisory: 2007-0013-1
Published: 2007-01-23
Products: rPath Linux 1
Rating: Major
Exposure Level Classification:
Indirect User Deterministic Denial of Service
Updated Versions:
poppler=/conary.rpath.com at rpl:devel//1/0.4.5-1.1-1
tetex=/conary.rpath.com at rpl:devel//1/2.0.2-28.4-1
tetex-afm=/conary.rpath.com at rpl:devel//1/2.0.2-28.4-1
tetex-dvips=/conary.rpath.com at rpl:devel//1/2.0.2-28.4-1
tetex-fonts=/conary.rpath.com at rpl:devel//1/2.0.2-28.4-1
tetex-latex=/conary.rpath.com at rpl:devel//1/2.0.2-28.4-1
tetex-xdvi=/conary.rpath.com at rpl:devel//1/2.0.2-28.4-1
References:
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0104
https://issues.rpath.com/browse/RPL-964
Description:
Previous versions of the poppler and tetex packages are vulnerable to
an attack in which an intentionally malformed PDF file can create at
least a minor Denial of Service attack on the PDF application, and
may possibly allow for directed or arbitrary code execution.
libgtop (denial of service, code execution)
rPSA-2007-0014-2 libgtop
rPath Update Announcements announce-noreply at rpath.com
Wed Jan 24 15:38:41 EST 2007
Previous message: rPSA-2007-0015-1 libsoup
Next message: rPSA-2007-0019-1 gtk
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
--------------------------------------------------------------------------------
rPath Security Advisory: 2007-0014-2
Published: 2007-01-23
Updated:
2007-01-24 locale information restored
Products: rPath Linux 1
Rating: Major
Exposure Level Classification:
Local User Deterministic Denial of Service
Updated Versions:
libgtop=/conary.rpath.com at rpl:devel//1/2.12.0-1.3-1
References:
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0235
https://issues.rpath.com/browse/RPL-972
Description:
Previous versions of the libgtop package are vulnerable to an attack
in which a local user can at least cause programs that use libgtop
(such as gnome-system-monitor) to crash, and possibly to execute
arbitrary code as the user running the program.
24 January 2007 Update: The initial fix for this vulnerability
inadvertently removed locale information. This has been resolved.
libsoup (denial of service)
rPSA-2007-0015-1 libsoup
rPath Update Announcements announce-noreply at rpath.com
Tue Jan 23 03:49:02 EST 2007
Previous message: rPSA-2007-0014-1 libgtop
Next message: rPSA-2007-0014-2 libgtop
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
--------------------------------------------------------------------------------
rPath Security Advisory: 2007-0015-1
Published: 2007-01-23
Products: rPath Linux 1
Rating: Minor
Exposure Level Classification:
Indirect Denial of Service
Updated Versions:
libsoup=/conary.rpath.com at rpl:devel//1/2.2.99-1-0.1
References:
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5876
https://issues.rpath.com/browse/RPL-965
Description:
Previous versions of the libsoup package are vulnerable to an indirect
denial of service in which a malicious or faulty server responds to
requests with malformed HTTP headers, causing the application that
uses libsoup to crash.
xine (multiple format string flaws)
Date: Tue, 23 Jan 2007 11:07:59 +0100
From: Thomas Biege
To: suse-security-announce@suse.com
Subject: SUSE Security Announcement: xine (SUSE-SA:2007:013)
-----BEGIN PGP SIGNED MESSAGE-----
______________________________________________________________________________
SUSE Security Announcement
Package: xine-ui,xine-lib,xine-extra,xine-devel
Announcement ID: SUSE-SA:2007:013
Date: Tue, 23 Jan 2007 08:00:00 +0000
Affected Products: SUSE LINUX 9.3
SUSE LINUX 10.0
SUSE LINUX 10.1
openSUSE 10.2
SUSE SLED 10
SLE SDK 10
Vulnerability Type: remote code execution
Severity (1-10): 4
SUSE Default Package: no
Cross-References: CVE-2007-0017
Content of This Advisory:
1) Security Vulnerability Resolved:
format string bug
Problem Description
2) Solution or Work-Around
3) Special Instructions and Notes
4) Package Location and Checksums
5) Pending Vulnerabilities, Solutions, and Work-Arounds:
none
6) Authenticity Verification and Additional Information
______________________________________________________________________________
1) Problem Description and Brief Discussion
This update fixes several format string bugs that can be exploited remotely
with user-assistance to execute arbitrary code.
Since SUSE Linux version 10.1 format string bugs are not exploitable
anymore. (CVE-2007-0017)
2) Solution or Work-Around
No temporary work-around known.
3) Special Instructions and Notes
none
4) Package Location and Checksums
The preferred method for installing security updates is to use the YaST
Online Update (YOU) tool. YOU detects which updates are required and
automatically performs the necessary steps to verify and install them.
Alternatively, download the update packages for your distribution manually
and verify their integrity by the methods listed in Section 6 of this
announcement. Then install the packages using the command
rpm -Fhv
to apply the update, replacing
downloaded RPM package.
x86 Platform:
openSUSE 10.2:
ftp://ftp.suse.com/pub/suse/update/10.2/rpm/i586/xine-devel-1.1.2-40.1.i586.rpm
2cacbb4f4e177362149518481480165a
ftp://ftp.suse.com/pub/suse/update/10.2/rpm/i586/xine-extra-1.1.2-40.1.i586.rpm
73cbdd8d443596547875804bd8e2ca8f
ftp://ftp.suse.com/pub/suse/update/10.2/rpm/i586/xine-lib-1.1.2-40.1.i586.rpm
2114f7c6a4c8351adab588c173419778
ftp://ftp.suse.com/pub/suse/update/10.2/rpm/i586/xine-ui-0.99.4-84.1.i586.rpm
5d4dd945a812ba0b17619c267ec8f2b5
SUSE LINUX 10.1:
ftp://ftp.suse.com/pub/suse/update/10.1/rpm/i586/xine-extra-1.1.1-24.17.i586.rpm
3eb1465401e5e1c6f36d8e2d7ca3e114
ftp://ftp.suse.com/pub/suse/update/10.1/rpm/i586/xine-lib-1.1.1-24.17.i586.rpm
e2fbf53b629e835dbc2558e87fabf926
ftp://ftp.suse.com/pub/suse/update/10.1/rpm/i586/xine-ui-0.99.4-32.14.i586.rpm
d710db4b4d20f7ea4485d16845cb4be2
SUSE LINUX 10.0:
ftp://ftp.suse.com/pub/suse/i386/update/10.0/rpm/i586/xine-extra-1.1.0-0.1.i586.rpm
06753ebd3608223077c95c01f8bc3122
ftp://ftp.suse.com/pub/suse/i386/update/10.0/rpm/i586/xine-lib-1.1.0-0.1.i586.rpm
60ab4fd7c193d687d9484e5691aa3f01
ftp://ftp.suse.com/pub/suse/i386/update/10.0/rpm/i586/xine-ui-0.99.4-84.1.i586.rpm
4bc3f28d7e600fbb78c65f6b0dcfc436
SUSE LINUX 9.3:
ftp://ftp.suse.com/pub/suse/i386/update/9.3/rpm/i586/xine-lib-1.0-10.14.i586.rpm
c944ed72f913771f0c2300883573e111
ftp://ftp.suse.com/pub/suse/i386/update/9.3/rpm/i586/xine-ui-1.0-10.14.i586.rpm
cee2a8a9669b429dde4e465e83aae70f
Power PC Platform:
openSUSE 10.2:
ftp://ftp.suse.com/pub/suse/update/10.2/rpm/ppc/xine-lib-1.1.2-40.1.ppc.rpm
a1fcfa82deed685446a213439639a579
ftp://ftp.suse.com/pub/suse/update/10.2/rpm/ppc/xine-ui-0.99.4-84.1.ppc.rpm
bc2dcf2266dbb56b1a0291209aad2dd7
SUSE LINUX 10.1:
ftp://ftp.suse.com/pub/suse/update/10.1/rpm/ppc/xine-extra-1.1.1-24.17.ppc.rpm
c337440571123263478dd2a64059a4e8
ftp://ftp.suse.com/pub/suse/update/10.1/rpm/ppc/xine-lib-1.1.1-24.17.ppc.rpm
3cf476901522d7b5abd5bf3cb18484a9
ftp://ftp.suse.com/pub/suse/update/10.1/rpm/ppc/xine-ui-0.99.4-32.14.ppc.rpm
a9e762bad246963a7564c1f36a5f0392
SUSE LINUX 10.0:
ftp://ftp.suse.com/pub/suse/i386/update/10.0/rpm/ppc/xine-extra-1.1.0-0.1.ppc.rpm
930dc314de3ab49a8655e6cdb89ff50d
ftp://ftp.suse.com/pub/suse/i386/update/10.0/rpm/ppc/xine-lib-1.1.0-0.1.ppc.rpm
ddd255708abfb433a3497d790491be55
ftp://ftp.suse.com/pub/suse/i386/update/10.0/rpm/ppc/xine-ui-0.99.4-84.1.ppc.rpm
827125d558472b685f0f1843d0eb3850
x86-64 Platform:
openSUSE 10.2:
ftp://ftp.suse.com/pub/suse/update/10.2/rpm/x86_64/xine-devel-1.1.2-40.1.x86_64.rpm
1dac6b23d257670ca7182f018c12a69b
ftp://ftp.suse.com/pub/suse/update/10.2/rpm/x86_64/xine-extra-1.1.2-40.1.x86_64.rpm
11dae8e2ecb5a78eb6b1cd39713f6322
ftp://ftp.suse.com/pub/suse/update/10.2/rpm/x86_64/xine-lib-1.1.2-40.1.x86_64.rpm
519480f44a28d4e3cab37aceca7e7c13
ftp://ftp.suse.com/pub/suse/update/10.2/rpm/x86_64/xine-lib-32bit-1.1.2-40.1.x86_64.rpm
3b5db06dab41a4ff2a53d22b3f6f6238
ftp://ftp.suse.com/pub/suse/update/10.2/rpm/x86_64/xine-ui-0.99.4-84.1.x86_64.rpm
b1a06bf5fd93c905bf5008859c88690d
ftp://ftp.suse.com/pub/suse/update/10.2/rpm/x86_64/xine-ui-32bit-0.99.4-84.1.x86_64.rpm
aa85b56d559aca4960693bad80a451bd
SUSE LINUX 10.1:
ftp://ftp.suse.com/pub/suse/update/10.1/rpm/x86_64/xine-extra-1.1.1-24.17.x86_64.rpm
72f6cfc29f428a5d7dc40fbcb285cfe6
ftp://ftp.suse.com/pub/suse/update/10.1/rpm/x86_64/xine-lib-1.1.1-24.17.x86_64.rpm
34382ef5b0ec94524678bdf842a21ecb
ftp://ftp.suse.com/pub/suse/update/10.1/rpm/x86_64/xine-lib-32bit-1.1.1-24.17.x86_64.rpm
316fd37892ef25073cf9d6ae11fb510b
ftp://ftp.suse.com/pub/suse/update/10.1/rpm/x86_64/xine-ui-0.99.4-32.14.x86_64.rpm
ee0a3ce52f3bf431ced82dbd0148890c
SUSE LINUX 10.0:
ftp://ftp.suse.com/pub/suse/i386/update/10.0/rpm/x86_64/xine-extra-1.1.0-0.1.x86_64.rpm
83094481db18fb55447a19b86db281ff
ftp://ftp.suse.com/pub/suse/i386/update/10.0/rpm/x86_64/xine-lib-1.1.0-0.1.x86_64.rpm
0e1b36454127be6815d1f52325ee1a70
ftp://ftp.suse.com/pub/suse/i386/update/10.0/rpm/x86_64/xine-lib-32bit-1.1.0-0.1.x86_64.rpm
45829c44efd83afaefe570d81f8a7568
ftp://ftp.suse.com/pub/suse/i386/update/10.0/rpm/x86_64/xine-ui-0.99.4-84.1.x86_64.rpm
bfe5d54a07d28cb9fef528c0257d4db7
SUSE LINUX 9.3:
ftp://ftp.suse.com/pub/suse/i386/update/9.3/rpm/x86_64/xine-lib-1.0-10.14.x86_64.rpm
e829f9cbd5e02a0498f03a2180b57963
ftp://ftp.suse.com/pub/suse/i386/update/9.3/rpm/x86_64/xine-lib-32bit-9.3-0.1.x86_64.rpm
064665c8b3ac38f71634734c101f1602
ftp://ftp.suse.com/pub/suse/i386/update/9.3/rpm/x86_64/xine-ui-1.0-10.14.x86_64.rpm
8e7011003db37a1799bbd531ae957a28
Sources:
openSUSE 10.2:
ftp://ftp.suse.com/pub/suse/update/10.2/rpm/src/xine-lib-1.1.2-40.1.src.rpm
f92b96c21a6e45ede2faa81c9efade83
ftp://ftp.suse.com/pub/suse/update/10.2/rpm/src/xine-ui-0.99.4-84.1.src.rpm
ed0382a57f117bcf04236ca660092afe
SUSE LINUX 10.1:
ftp://ftp.suse.com/pub/suse/update/10.1/rpm/src/xine-lib-1.1.1-24.17.src.rpm
1d347a598b2e8dfc5eaa4f7b9c951242
SUSE LINUX 10.0:
ftp://ftp.suse.com/pub/suse/i386/update/10.0/rpm/src/xine-lib-1.1.0-0.1.nosrc.rpm
d1d2036b46056a00b3c5a0cee5371ad8
SUSE LINUX 9.3:
ftp://ftp.suse.com/pub/suse/i386/update/9.3/rpm/src/xine-lib-1.0-10.14.nosrc.rpm
02ae3f6c9a88ec0aabcce701bba20542
Our maintenance customers are notified individually. The packages are
offered for installation from the maintenance web:
SLE SDK 10
http://support.novell.com/techcenter/psdb/3850f4cb30959892275d84ebf0b1dfc6.html
SUSE SLED 10
http://support.novell.com/techcenter/psdb/3850f4cb30959892275d84ebf0b1dfc6.html
______________________________________________________________________________
5) Pending Vulnerabilities, Solutions, and Work-Arounds:
none
______________________________________________________________________________
6) Authenticity Verification and Additional Information
- Announcement authenticity verification:
SUSE security announcements are published via mailing lists and on Web
sites. The authenticity and integrity of a SUSE security announcement is
guaranteed by a cryptographic signature in each announcement. All SUSE
security announcements are published with a valid signature.
To verify the signature of the announcement, save it as text into a file
and run the command
gpg --verify
replacing
announcement. The output for a valid signature looks like:
gpg: Signature made
gpg: Good signature from "SuSE Security Team
where
If the security team's key is not contained in your key ring, you can
import it from the first installation CD. To import the key, use the
command
gpg --import gpg-pubkey-3d25d3d9-36e12d04.asc
- Package authenticity verification:
SUSE update packages are available on many mirror FTP servers all over the
world. While this service is considered valuable and important to the free
and open source software community, the authenticity and the integrity of
a package needs to be verified to ensure that it has not been tampered
with.
There are two verification methods that can be used independently from
each other to prove the authenticity of a downloaded file or RPM package:
1) Using the internal gpg signatures of the rpm package
2) MD5 checksums as provided in this announcement
1) The internal rpm package signatures provide an easy way to verify the
authenticity of an RPM package. Use the command
rpm -v --checksig
to verify the signature of the package, replacing
filename of the RPM package downloaded. The package is unmodified if it
contains a valid signature from build@suse.de with the key ID 9C800ACA.
This key is automatically imported into the RPM database (on
RPMv4-based distributions) and the gpg key ring of 'root' during
installation. You can also find it on the first installation CD and at
the end of this announcement.
2) If you need an alternative means of verification, use the md5sum
command to verify the authenticity of the packages. Execute the command
md5sum
after you downloaded the file from a SUSE FTP server or its mirrors.
Then compare the resulting md5sum with the one that is listed in the
SUSE security announcement. Because the announcement containing the
checksums is cryptographically signed (by security@suse.de), the
checksums show proof of the authenticity of the package if the
signature of the announcement is valid. Note that the md5 sums
published in the SUSE Security Announcements are valid for the
respective packages only. Newer versions of these packages cannot be
verified.
- SUSE runs two security mailing lists to which any interested party may
subscribe:
opensuse-security@opensuse.org
- General Linux and SUSE security discussion.
All SUSE security announcements are sent to this list.
To subscribe, send an e-mail to
suse-security-announce@suse.com
- SUSE's announce-only mailing list.
Only SUSE's security announcements are sent to this list.
To subscribe, send an e-mail to
=====================================================================
SUSE's security contact is
The
=====================================================================
______________________________________________________________________________
The information in this advisory may be distributed or reproduced,
provided that the advisory is not modified in any way. In particular, the
clear text signature should show proof of the authenticity of the text.
SUSE Linux Products GmbH provides no warranties of any kind whatsoever
with respect to the information contained in this security advisory.
squid (denial of service)
Date: Tue, 23 Jan 2007 11:07:29 +0100
From: Thomas Biege
To: suse-security-announce@suse.com
Subject: SUSE Security Announcement: squid (SUSE-SA:2007:012)
-----BEGIN PGP SIGNED MESSAGE-----
______________________________________________________________________________
SUSE Security Announcement
Package: squid
Announcement ID: SUSE-SA:2007:012
Date: Tue, 23 Jan 2007 09:00:00 +0000
Affected Products: SUSE LINUX 9.3
SUSE LINUX 10.0
SUSE LINUX 10.1
openSUSE 10.2
UnitedLinux 1.0
SuSE Linux Enterprise Server 8
SuSE Linux Openexchange Server 4
SuSE Linux Standard Server 8
SuSE Linux School Server
SUSE LINUX Retail Solution 8
SUSE SLES 9
Open Enterprise Server
Novell Linux POS 9
SUSE SLED 10
SUSE SLES 10
Vulnerability Type: remote denial of service
Severity (1-10): 4
SUSE Default Package: no
Cross-References: CVE-2007-0247
CVE-2007-0248
Content of This Advisory:
1) Security Vulnerability Resolved:
remote denial of service
Problem Description
2) Solution or Work-Around
3) Special Instructions and Notes
4) Package Location and Checksums
5) Pending Vulnerabilities, Solutions, and Work-Arounds:
none
6) Authenticity Verification and Additional Information
______________________________________________________________________________
1) Problem Description and Brief Discussion
This update fixes a remotely exploitable denial-of-service
bug in squid that can be triggered by using special ftp://
URLs. (CVE-2007-0247)
Additionally the 10.2 package needed a fix for another DoS
bug (CVE-2007-0248) and for max_user_ip handling in
ntlm_auth.
2) Solution or Work-Around
No temporary work-around known.
3) Special Instructions and Notes
Restart squid.
4) Package Location and Checksums
The preferred method for installing security updates is to use the YaST
Online Update (YOU) tool. YOU detects which updates are required and
automatically performs the necessary steps to verify and install them.
Alternatively, download the update packages for your distribution manually
and verify their integrity by the methods listed in Section 6 of this
announcement. Then install the packages using the command
rpm -Fhv
to apply the update, replacing
downloaded RPM package.
x86 Platform:
openSUSE 10.2:
ftp://ftp.suse.com/pub/suse/update/10.2/rpm/i586/squid-2.6.STABLE6-0.4.i586.rpm
c1a38e8dc8301158fe717a9115e60001
SUSE LINUX 10.1:
ftp://ftp.suse.com/pub/suse/update/10.1/rpm/i586/squid-2.5.STABLE12-18.6.i586.rpm
b390a43cd014988f3444fc8a3f89af7d
SUSE LINUX 10.0:
ftp://ftp.suse.com/pub/suse/i386/update/10.0/rpm/i586/squid-2.5.STABLE10-5.5.i586.rpm
171ae4d1ae9941da3641391f0cbb020e
SUSE LINUX 9.3:
ftp://ftp.suse.com/pub/suse/i386/update/9.3/rpm/i586/squid-2.5.STABLE9-4.9.i586.rpm
5abca23e37cee2bf20085951b8a59953
Power PC Platform:
openSUSE 10.2:
ftp://ftp.suse.com/pub/suse/update/10.2/rpm/ppc/squid-2.6.STABLE6-0.4.ppc.rpm
ffb0c8fe4086a913fede3cba0f1b473c
SUSE LINUX 10.1:
ftp://ftp.suse.com/pub/suse/update/10.1/rpm/ppc/squid-2.5.STABLE12-18.6.ppc.rpm
bec76f3f1c4a445801117f696d438925
SUSE LINUX 10.0:
ftp://ftp.suse.com/pub/suse/i386/update/10.0/rpm/ppc/squid-2.5.STABLE10-5.5.ppc.rpm
87fc216ed79eee0d5eecf2ba24d4adfe
x86-64 Platform:
openSUSE 10.2:
ftp://ftp.suse.com/pub/suse/update/10.2/rpm/x86_64/squid-2.6.STABLE6-0.4.x86_64.rpm
6b37f676418485c52d262cc8f17347f0
SUSE LINUX 10.1:
ftp://ftp.suse.com/pub/suse/update/10.1/rpm/x86_64/squid-2.5.STABLE12-18.6.x86_64.rpm
ddc9aaba2e99eeb2d8215acf799b8ecb
SUSE LINUX 10.0:
ftp://ftp.suse.com/pub/suse/i386/update/10.0/rpm/x86_64/squid-2.5.STABLE10-5.5.x86_64.rpm
100ed655a1fbdcf4a8ed1bd98598e2bb
SUSE LINUX 9.3:
ftp://ftp.suse.com/pub/suse/i386/update/9.3/rpm/x86_64/squid-2.5.STABLE9-4.9.x86_64.rpm
599d0bb6f1cd872816eb371abf24a44e
Sources:
openSUSE 10.2:
ftp://ftp.suse.com/pub/suse/update/10.2/rpm/src/squid-2.6.STABLE6-0.4.src.rpm
8467df81f96919f3a1c6d55905581735
SUSE LINUX 10.1:
ftp://ftp.suse.com/pub/suse/update/10.1/rpm/src/squid-2.5.STABLE12-18.6.src.rpm
5da1a897fdb953cb3f9801d0eda1899b
SUSE LINUX 10.0:
ftp://ftp.suse.com/pub/suse/i386/update/10.0/rpm/src/squid-2.5.STABLE10-5.5.src.rpm
794090e751edceb8355c4706a28c2aa5
SUSE LINUX 9.3:
ftp://ftp.suse.com/pub/suse/i386/update/9.3/rpm/src/squid-2.5.STABLE9-4.9.src.rpm
6c6c1a9a0e0db47a3336d51551a859e9
Our maintenance customers are notified individually. The packages are
offered for installation from the maintenance web:
UnitedLinux 1.0
http://support.novell.com/techcenter/psdb/e4f5424c0eb495e52b8739b57f62405b.html
SuSE Linux Openexchange Server 4
http://support.novell.com/techcenter/psdb/e4f5424c0eb495e52b8739b57f62405b.html
Open Enterprise Server
http://support.novell.com/techcenter/psdb/e4f5424c0eb495e52b8739b57f62405b.html
Novell Linux POS 9
http://support.novell.com/techcenter/psdb/e4f5424c0eb495e52b8739b57f62405b.html
SuSE Linux Enterprise Server 8
http://support.novell.com/techcenter/psdb/e4f5424c0eb495e52b8739b57f62405b.html
SuSE Linux Standard Server 8
http://support.novell.com/techcenter/psdb/e4f5424c0eb495e52b8739b57f62405b.html
SuSE Linux School Server
http://support.novell.com/techcenter/psdb/e4f5424c0eb495e52b8739b57f62405b.html
SUSE LINUX Retail Solution 8
http://support.novell.com/techcenter/psdb/e4f5424c0eb495e52b8739b57f62405b.html
SUSE SLES 10
http://support.novell.com/techcenter/psdb/e4f5424c0eb495e52b8739b57f62405b.html
SUSE SLED 10
http://support.novell.com/techcenter/psdb/e4f5424c0eb495e52b8739b57f62405b.html
SUSE SLES 9
http://support.novell.com/techcenter/psdb/e4f5424c0eb495e52b8739b57f62405b.html
______________________________________________________________________________
5) Pending Vulnerabilities, Solutions, and Work-Arounds:
none
______________________________________________________________________________
6) Authenticity Verification and Additional Information
- Announcement authenticity verification:
SUSE security announcements are published via mailing lists and on Web
sites. The authenticity and integrity of a SUSE security announcement is
guaranteed by a cryptographic signature in each announcement. All SUSE
security announcements are published with a valid signature.
To verify the signature of the announcement, save it as text into a file
and run the command
gpg --verify
replacing
announcement. The output for a valid signature looks like:
gpg: Signature made
gpg: Good signature from "SuSE Security Team
where
If the security team's key is not contained in your key ring, you can
import it from the first installation CD. To import the key, use the
command
gpg --import gpg-pubkey-3d25d3d9-36e12d04.asc
- Package authenticity verification:
SUSE update packages are available on many mirror FTP servers all over the
world. While this service is considered valuable and important to the free
and open source software community, the authenticity and the integrity of
a package needs to be verified to ensure that it has not been tampered
with.
There are two verification methods that can be used independently from
each other to prove the authenticity of a downloaded file or RPM package:
1) Using the internal gpg signatures of the rpm package
2) MD5 checksums as provided in this announcement
1) The internal rpm package signatures provide an easy way to verify the
authenticity of an RPM package. Use the command
rpm -v --checksig
to verify the signature of the package, replacing
filename of the RPM package downloaded. The package is unmodified if it
contains a valid signature from build@suse.de with the key ID 9C800ACA.
This key is automatically imported into the RPM database (on
RPMv4-based distributions) and the gpg key ring of 'root' during
installation. You can also find it on the first installation CD and at
the end of this announcement.
2) If you need an alternative means of verification, use the md5sum
command to verify the authenticity of the packages. Execute the command
md5sum
after you downloaded the file from a SUSE FTP server or its mirrors.
Then compare the resulting md5sum with the one that is listed in the
SUSE security announcement. Because the announcement containing the
checksums is cryptographically signed (by security@suse.de), the
checksums show proof of the authenticity of the package if the
signature of the announcement is valid. Note that the md5 sums
published in the SUSE Security Announcements are valid for the
respective packages only. Newer versions of these packages cannot be
verified.
- SUSE runs two security mailing lists to which any interested party may
subscribe:
opensuse-security@opensuse.org
- General Linux and SUSE security discussion.
All SUSE security announcements are sent to this list.
To subscribe, send an e-mail to
suse-security-announce@suse.com
- SUSE's announce-only mailing list.
Only SUSE's security announcements are sent to this list.
To subscribe, send an e-mail to
=====================================================================
SUSE's security contact is
The
=====================================================================
______________________________________________________________________________
The information in this advisory may be distributed or reproduced,
provided that the advisory is not modified in any way. In particular, the
clear text signature should show proof of the authenticity of the text.
SUSE Linux Products GmbH provides no warranties of any kind whatsoever
with respect to the information contained in this security advisory.
Type Bits/KeyID Date User ID
pub 2048R/3D25D3D9 1999-03-06 SuSE Security Team
pub 1024D/9C800ACA 2000-10-19 SuSE Package Signing Key
Cisco Security Advisory: IPv6 Routing Header Vulnerability
Document ID: 72372
Advisory ID: cisco-sa-20070124-IOS-IPv6
http://www.cisco.com/warp/public/707/cisco-sa-20070124-IOS-IPv6.shtml
1.0
For Public Release 2007 January 24 1600 UTC (GMT)
--------------------------------------------------------------------------------
Please provide your feedback on this document.
--------------------------------------------------------------------------------
Contents
Summary
Affected Products
Details
Impact
Software Version and Fixes
Workarounds
Obtaining Fixed Software
Exploitation and Public Announcements
Status of this Notice:FINAL
Distribution
Revision History
Cisco Security Procedures
--------------------------------------------------------------------------------
Summary
Processing a specially crafted IPv6 Type 0 Routing header can crash a device running Cisco IOS software. This vulnerability does not affect IPv6 Type 2 Routing header which is used in mobile IPv6. IPv6 is not enabled by default in Cisco IOS.
Cisco has made free software available to address this vulnerability for affected customers.
There are workarounds available to mitigate the effects of the vulnerability. The workaround depends on if Mobile IPv6 is used and what version on Cisco IOS is being currently used.
This vulnerability was initially reported by a customer and further trigger vector was discovered during developing the fix for this vulnerability.
This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20070124-IOS-IPv6.shtml.
Affected Products
Devices running Cisco IOS and having IPv6 enabled on, at least, one of their interface may be affected by this vulnerability.
Vulnerable Products
To determine the software running on a Cisco product, log in to the device and issue the show version command to display the system banner. Cisco IOS software will identify itself as "Internetwork Operating System Software" or simply "IOS". On the next line of output, the image name will be displayed between parentheses, followed by "Version" and the IOS release name. Other Cisco devices will not have the show version command or will give different output.
The following example identifies a Cisco product running IOS release 12.4(9.10):
Cisco IOS Software, 7200 Software (C7200-JK9O3S-M), Version 12.4(9.10), INTERIM SOFTWARE
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2006 by Cisco Systems, Inc.
Compiled Mon 29-May-06 04:42 by prod_rel_teamAdditional information about Cisco IOS release naming can be found at http://www.cisco.com/warp/public/620/1.html.
Products Confirmed Not Vulnerable
No other Cisco products are known to be vulnerable to the issue described in this Advisory. In particular Cisco IOS XR, Cisco PIX Appliance and Cisco MDS 9000 Series devices are not affected by this vulnerability.
Details
This vulnerability can be triggered only when Cisco IOS processes specifically crafted IPv6 Type 0 Routing headers, which are used for source routing. Source routing is when an originator node explicitly specifies the exact path that a packet must take to reach the destination. Source routing is enabled by default on Cisco IOS if IPv6 is configured on the device. In order to trigger this vulnerability the packet must be destined to any of the IPv6 addresses defined on the device. The exact packet type is not relevant (e.g., TCP, ICMP, UDP) as the vulnerability is on the IP layer. For this reason care must be taken when implementing a workaround as this vulnerability can be triggered by a spoofed packet.
IPv6 multicast packets can not be used to trigger this vulnerability.
In addition to Type 0 Routing headers, IPv6 also supports Type 2 Routing that is used in Mobile IPv6 implementation. Type 2 Routing headers can not be used to trigger the vulnerability described in this Advisory.
A router running vulnerable Cisco IOS software will process Type 0 Routing headers only if the destination address in the IPv6 packet is one of the IPv6 addresses defined on any of the interfaces. The address may be either a global (i.e., routable), loopback or link local address. Link local addresses are not supposed to be routable and they are valid only among directly connected devices.
A device may also be susceptible in scenarios where IPv6 packets are tunneled over IPv4 networks provided that the IPv6 destination address (after de-encapsulation) is one of the IPv6 addresses defined on the device. This is independent of the exact encapsulation method used (e.g., MPLS, GRE or IPv6-in-IPv4).
This vulnerability is documented in Cisco Bug IDs CSCsd40334 ( registered customers only) and CSCsd58381 ( registered customers only) .
Vulnerability Scoring Details
Cisco is providing scores for the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS).
Cisco will provide a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks.
Cisco PSIRT will set the bias in all cases to normal. Customers are encouraged to apply the bias parameter when determining the environmental impact of a particular vulnerability.
CVSS is a standards based scoring method that conveys vulnerability severity and helps determine urgency and priority of response.
Cisco has provided an FAQ to answer additional questions regarding CVSS at http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html.
Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at http://intellishield.cisco.com/security/alertmanager/cvss.
CSCsd40334 - IPv6 packet can cause crash ( registered customers only)
CVSS Base Score - 10
Access Vector
Access Complexity
Authentication
Confidentiality Impact
Integrity Impact
Availability Impact
Impact Bias
Remote
Low
Not Required
Complete
Complete
Complete
Normal
CVSS Temporal Score - 8.3
Exploitability
Remediation Level
Report Confidence
Functional
Official Fix
Confirmed
CSCsd58381 - IPv6 routing header limitation ( registered customers only)
CVSS Base Score - 10
Access Vector
Access Complexity
Authentication
Confidentiality Impact
Integrity Impact
Availability Impact
Impact Bias
Remote
Low
Not Required
Complete
Complete
Complete
Normal
CVSS Temporal Score - 8.3
Exploitability
Remediation Level
Report Confidence
Functional
Official Fix
Confirmed
Impact
Successful exploitation of the vulnerability listed in this Advisory can corrupt some memory structures. In most cases this will cause the affected device to crash and repeated exploitation could result in a sustained DoS attack. However, due to memory corruption, there is a potential to execute an arbitrary code. In the event of a successful remote code execution, device integrity will have been completely compromised.
Software Version and Fixes
When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution.
In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center ("TAC") or your contracted maintenance provider for assistance.
Each row of the Cisco IOS software table (below) describes a release train and the platforms or products for which it is intended. If a given release train is vulnerable, then the earliest possible releases that contain the fix (the "First Fixed Release") and the anticipated date of availability for each are listed in the "Rebuild" and "Maintenance" columns. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. The release should be upgraded at least to the indicated release or a later version (greater than or equal to the First Fixed Release label).
For more information on the terms "Rebuild" and "Maintenance," consult the following URL: http://www.cisco.com/warp/public/620/1.html.
Note: There are three IOS security advisories and one field notice being published on January 24, 2007. Each advisory only lists the releases which fix the issue described in the advisory. A combined software table is available at http://www.cisco.com/warp/public/707/cisco-sa-20070124-bundle.shtml and can be used to choose a software release which fixes all security vulnerabilities published as of January 24, 2007. The advisories and field notice published on January 24 are listed here.
http://www.cisco.com/warp/public/707/cisco-air-20070124-IOS-ipv6.shtml
http://www.cisco.com/warp/public/707/cisco-sa-20070124-crafted-tcp.shtml
http://www.cisco.com/warp/public/707/cisco-sa-20070124-crafted-ip-option.shtml
http://www.cisco.com/warp/public/770/fn62613.shtml
Requests for software rebuilds to include the change for Daylight Savings Time (DST) that will be implemented in March 2007 should be directed through the Technical Assistance Center (TAC) and this advisory should be used as reference.
Major Release
Availability of Repaired Releases
Affected 12.0-Based Release
Rebuild
Maintenance
12.0
Not vulnerable
12.0DA
Not vulnerable
12.0DB
Not vulnerable
12.0DC
Not vulnerable
12.0S
12.0(32)S3
12.0SC
Not vulnerable
12.0SL
Not vulnerable
12.0SP
Not vulnerable
12.0ST
Vulnerable; migrate to 12.0(32)S3 or later
12.0SX
Vulnerable for only 12.0(30)SX; contact TAC
12.0SY
12.0(32)SY
12.0SZ
Vulnerable; migrate to 12.0(32)S3 or later
12.0T
Not vulnerable
12.0W
Not vulnerable
12.0WC
Not vulnerable
12.0WT
Not vulnerable
12.0XA
Not vulnerable
12.0XB
Not vulnerable
12.0XC
Not vulnerable
12.0XD
Not vulnerable
12.0XE
Not vulnerable
12.0XF
Not vulnerable
12.0XG
Not vulnerable
12.0XH
Not vulnerable
12.0XI
Not vulnerable
12.0XJ
Not vulnerable
12.0XK
Not vulnerable
12.0XL
Not vulnerable
12.0XM
Not vulnerable
12.0XN
Not vulnerable
12.0XQ
Not vulnerable
12.0XR
Not vulnerable
12.0XS
Not vulnerable
12.0XV
Not vulnerable
12.0XW
Not vulnerable
Affected 12.1-Based Release
Rebuild
Maintenance
12.1
Not vulnerable
12.1AA
Not vulnerable
12.1AX
Not vulnerable
12.1AY
Not vulnerable
12.1AZ
Not vulnerable
12.1CX
Not vulnerable
12.1DA
Not vulnerable
12.1DB
Not vulnerable
12.1DC
Not vulnerable
12.1E
Not vulnerable
12.1EA
Not vulnerable
12.1EB
Not vulnerable
12.1EC
Not vulnerable
12.1EO
Not vulnerable
12.1EU
Not vulnerable
12.1EV
Not vulnerable
12.1EW
Not vulnerable
12.1EX
Not vulnerable
12.1EY
Not vulnerable
12.1EZ
Not vulnerable
12.1T
Not vulnerable
12.1XA
Not vulnerable
12.1XB
Not vulnerable
12.1XC
Not vulnerable
12.1XD
Not vulnerable
12.1XE
Not vulnerable
12.1XF
Not vulnerable
12.1XG
Not vulnerable
12.1XH
Not vulnerable
12.1XI
Not vulnerable
12.1XJ
Not vulnerable
12.1XL
Not vulnerable
12.1XM
Not vulnerable
12.1XP
Not vulnerable
12.1XQ
Not vulnerable
12.1XR
Not vulnerable
12.1XS
Not vulnerable
12.1XT
Not vulnerable
12.1XU
Vulnerable; migrate to 12.3(18) or later
12.1XV
Vulnerable; migrate to 12.3(18) or later
12.1XW
Not vulnerable
12.1XX
Not vulnerable
12.1XY
Not vulnerable
12.1XZ
Not vulnerable
12.1YA
Not vulnerable
12.1YB
Vulnerable; migrate to 12.3(18) or later
12.1YC
Vulnerable; migrate to 12.3(18) or later
12.1YD
Vulnerable; migrate to 12.3(18) or later
12.1YE
Not vulnerable
12.1YF
Not vulnerable
12.1YH
Not vulnerable
12.1YI
Not vulnerable
12.1YJ
Not vulnerable
Affected 12.2-Based Release
Rebuild
Maintenance
12.2
Not vulnerable
12.2B
Vulnerable; migrate to 12.3(4)T13 or later
12.2BC
Vulnerable; migrate to 12.3(17b)BC3 or later
12.2BW
Vulnerable; migrate to 12.3(18) or later
12.2BY
Vulnerable; migrate to 12.3(4)T13 or later
12.2BZ
Not vulnerable
12.2CX
Vulnerable; migrate to 12.3(17b)BC3 or later
12.2CY
Not vulnerable
12.2CZ
Not vulnerable
12.2DA
Not vulnerable
12.2DD
Vulnerable; migrate to 12.3(4)T13 or later
12.2DX
Vulnerable; migrate to 12.3(4)T13 or later
12.2EU
Vulnerable; migrate to 12.2(25)EWA6 or later
12.2EW
Vulnerable; migrate to 12.2(25)EWA6 or later
12.2EWA
12.2(25)EWA6
12.2EX
Not vulnerable
12.2EY
Not vulnerable
12.2EZ
Vulnerable; migrate to 12.2(25)SEE1 or later
12.2FX
Not vulnerable
12.2FY
Not vulnerable
12.2FZ
Not vulnerable
12.2IXA
Vulnerable; migrate to 12.2(18)IXB or later
12.2IXB
All 12.2IXB releases are fixed
12.2IXC
All 12.2IXC releases are fixed
12.2JA
Not vulnerable
12.2JK
Not vulnerable
12.2MB
Not vulnerable
12.2MC
12.2(15)MC2h
12.2S
12.2(25)S11
12.2(30)S
12.2SB
12.2(28)SB2
12.2(31)SB
12.2SBC
12.2(27)SBC4
12.2SEA
Vulnerable; migrate to 12.2(25)SEE1 or later
12.2SEB
Vulnerable; migrate to 12.2(25)SEE1 or later
12.2SEC
Vulnerable; migrate to 12.2(25)SEE1 or later
12.2SED
Vulnerable; migrate to 12.2(25)SEE1 or later
12.2SEE
12.2(25)SEE1
12.2SEF
12.2(25)SEF1
12.2SEG
All 12.2SEG releases are fixed
12.2SG
12.2(25)SG1
12.2(31)SG
12.2SGA
All 12.2SGA releases are fixed
12.2SO
Not vulnerable
12.2SRA
All 12.2SRA releases are fixed
12.2SRB
All 12.2SRB releases are fixed
12.2SU
Vulnerable; migrate to 12.3(14)T7 or later
12.2SV
12.2(25)SV3
12.2(26)SV
12.2SW
12.2(25)SW7
12.2SX
Vulnerable; migrate to 12.2(18)SXD7a or later
12.2SXA
Vulnerable; migrate to 12.2(18)SXD7a or later
12.2SXB
Vulnerable; migrate to 12.2(18)SXD7a or later
12.2SXD
12.2(18)SXD7a
12.2SXE
12.2(18)SXE6
12.2SXF
12.2(18)SXF5
12.2SY
Vulnerable; migrate to 12.2(18)SXD7a or later
12.2SZ
Vulnerable; migrate to 12.2(25)S11 or later
12.2T
Vulnerable; migrate to 12.3(18) or later
12.2TPC
Vulnerable; contact TAC
12.2XA
Vulnerable; migrate to 12.3(18) or later
12.2XB
Vulnerable; migrate to 12.3(18) or later
12.2XC
Vulnerable; migrate to 12.3(4)T13 or later
12.2XD
Vulnerable; migrate to 12.3(18) or later
12.2XE
Not vulnerable
12.2XF
Vulnerable; migrate to 12.3(17b)BC3 or later
12.2XG
Vulnerable; migrate to 12.3(18) or later
12.2XH
Vulnerable; migrate to 12.3(18) or later
12.2XI
Vulnerable; migrate to 12.3(18) or later
12.2XJ
Vulnerable; migrate to 12.3(18) or later
12.2XK
Vulnerable; migrate to 12.3(18) or later
12.2XL
Vulnerable; migrate to 12.3(18) or later
12.2XM
Vulnerable; migrate to 12.3(18) or later
12.2XN
12.2(31)XN
12.2XQ
Vulnerable; migrate to 12.3(18) or later
12.2XR
Not vulnerable
12.2XS
Vulnerable; migrate to 12.3(18) or later
12.2XT
Vulnerable; migrate to 12.3(18) or later
12.2XU
Vulnerable; migrate to 12.3(18) or later
12.2XV
Vulnerable; migrate to 12.3(18) or later
12.2XW
Vulnerable; migrate to 12.3(18) or later
12.2YA
Vulnerable; migrate to 12.3(18) or later
12.2YB
Vulnerable; migrate to 12.3(18) or later
12.2YC
Not vulnerable
12.2YD
Vulnerable; migrate to 12.3(11)T10 or later
12.2YE
Vulnerable; migrate to 12.2(25)S11 or later
12.2YF
Vulnerable; migrate to 12.3(18) or later
12.2YG
Not vulnerable
12.2YH
Vulnerable; migrate to 12.3(18) or later
12.2YJ
Vulnerable; migrate to 12.3(18) or later
12.2YK
Not vulnerable
12.2YL
Vulnerable; migrate to 12.3(4)T13 or later
12.2YM
Vulnerable; migrate to 12.3(4)T13 or later
12.2YN
Vulnerable; migrate to 12.3(4)T13 or later
12.2YO
Not vulnerable
12.2YP
Not vulnerable
12.2YQ
Vulnerable; migrate to 12.3(4)T13 or later
12.2YR
Vulnerable; migrate to 12.3(4)T13 or later
12.2YT
Vulnerable; migrate to 12.3(18) or later
12.2YU
Vulnerable; migrate to 12.3(4)T13 or later
12.2YV
Vulnerable; migrate to 12.3(4)T13 or later
12.2YW
Vulnerable; migrate to 12.3(4)T13 or later
12.2YX
Vulnerable; migrate to 12.3(14)T7 or later
12.2YY
Vulnerable; migrate to 12.3(4)T13 or later
12.2YZ
Vulnerable; migrate to 12.2(25)S11 or later
12.2ZA
Vulnerable; migrate to 12.2(18)SXD7a or later
12.2ZB
Vulnerable; migrate to 12.3(4)T13 or later
12.2ZC
Not vulnerable
12.2ZD
Vulnerable; contact TAC
12.2ZE
Vulnerable; migrate to 12.3(18) or later
12.2ZF
Vulnerable; migrate to 12.3(4)T13 or later
12.2ZG
Not vulnerable
12.2ZH
Vulnerable; contact TAC
12.2ZJ
Vulnerable; migrate to 12.3(4)T13 or later
12.2ZL
Vulnerable; contact TAC
12.2ZN
Vulnerable; migrate to 12.3(4)T13 or later
12.2ZP
Not vulnerable
Affected 12.3-Based Release
Rebuild
Maintenance
12.3
12.3(17b)
12.3(18)
12.3B
Vulnerable; migrate to 12.3(11)T10 or later
12.3BC
12.3(17b)BC3
12.3BW
Vulnerable; migrate to 12.3(11)T10 or later
12.3JA
Not vulnerable
12.3JEA
All 12.3JEA releases are fixed
12.3JEB
All 12.3JEA releases are fixed
12.3JK
Not vulnerable
12.3JX
Not vulnerable
12.3T
12.3(4)T13
12.3(11)T10
12.3(14)T7
12.3TPC
Not vulnerable
12.3XA
Vulnerable; contact TAC
12.3XB
Vulnerable; migrate to 12.3(11)T10 or later
12.3XC
Vulnerable; contact TAC
12.3XD
Vulnerable; migrate to 12.3(11)T10 or later
12.3XE
Vulnerable; contact TAC
12.3XF
Vulnerable; migrate to 12.3(11)T10 or later
12.3XG
Vulnerable; contact TAC
12.3XH
Vulnerable; migrate to 12.3(11)T10 or later
12.3XI
12.3(7)XI8a
12.3(7)XI9
12.3XJ
Vulnerable; migrate to 12.3(14)YX2 or later
12.3XK
Vulnerable; migrate to 12.3(14)T7 or later
12.3XQ
Vulnerable; migrate to 12.4(8) or later
12.3XR
Vulnerable; contact TAC
12.3XS
Vulnerable; migrate to 12.4(8) or later
12.3XU
Vulnerable; migrate to 12.4(2)T4 or later
12.3XW
Vulnerable; migrate to 12.3(14)YX2 or later
12.3XX
Vulnerable; migrate to 12.4(8) or later
12.3XY
Not vulnerable
12.3YA
Vulnerable; contact TAC
12.3YD
Vulnerable; migrate to 12.4(2)T4 or later
12.3YF
Vulnerable; migrate to 12.3(14)YX2 or later
12.3YG
Vulnerable; migrate to 12.4(2)T4 or later
12.3YH
Vulnerable; migrate to 12.4(2)T4 or later
12.3YI
Vulnerable; migrate to 12.4(2)T4 or later
12.3YJ
Vulnerable; migrate to 12.4(6)T1 or later
12.3YK
Vulnerable; migrate to 12.4(4)T2 or later
12.3YM
12.3(14)YM8
12.3YQ
Vulnerable; migrate to 12.4(6)T1 or later
12.3YS
Vulnerable; migrate to 12.4(4)T2 or later
12.3YT
Vulnerable; migrate to 12.4(4)T2 or later
12.3YU
Vulnerable; migrate to 12.4(2)XB2 or later
12.3YX
12.3(14)YX2
12.3YZ
12.3(11)YZ1
Affected 12.4-Based Release
Rebuild
Maintenance
12.4
12.4(3d)
12.4(5b)
12.4(7a)
12.4(8)
12.4MR
Not vulnerable
12.4SW
All 12.4SW releases are fixed
12.4T
12.4(2)T4
12.4(4)T2
12.4(6)T1
12.4(9)T
12.4XA
Vulnerable; migrate to 12.4(6)T1 or later
12.4XB
12.4(2)XB2
12.4XC
12.4(4)XC5
12.4XD
12.4(4)XD2
12.4XE
All 12.4XE releases are fixed
12.4XG
All 12.4XG releases are fixed
12.4XJ
All 12.4XJ releases are fixed
12.4XP
All 12.4XP releases are fixed
12.4XT
All 12.4XT releases are fixed
Workarounds
The workaround consists of filtering packets that contain Type 0 Routing header(s). Special attention must be paid not to filter packets with Type 2 Routing headers as that would break Mobile IPv6 deployment. Depending on what Cisco IOS software release is used and if Mobile IPv6 is deployed or not we have the following workarounds. As any packet type can be used to trigger this vulnerability the care must be taken when implementing a workaround to account for a spoofed packet.
Additional mitigations that can be deployed on Cisco devices within the network are available in the Cisco Applied Intelligence companion document for this advisory: http://www.cisco.com/warp/public/707/cisco-air-20070124-IOS-IPv6.shtml
Mobile IPv6 is not deployed
For IOS releases before 12.3(4)T the workaround is to use ACLs to filter all packets that contain Routing headers. This method can not distinguish between Type 0 and Type 2 Routing headers so it is not suitable if Mobile IPv6 is deployed.
The following example shows how to configure such ACLs.
Router(config)#ipv6 access-list deny-sourcerouted
Router(config-ipv6-acl)#deny ipv6 any
Router(config-ipv6-acl)#deny ipv6 any
Router(config-ipv6-acl)#permit ipv6 any any
Router(config-ipv6-acl)#exit
Router(config)#interface Ethernet0
Router(config-if)#ipv6 traffic-filter deny-sourcerouted in
In this example
The alternative of enumerating all IPv6 addresses is to use statement deny ipv6 any any routing. While that simplifies the resulting ACL it will also filter all transit IPv6 traffic with Routing headers 0 and 2. The example where all configured IPv6 addresses are enumerated will not affect transit traffic. This comment is applicable to all other examples in this Advisory.
Starting from the IOS release 12.2(15)T a new command ipv6 source-route was introduced. If applied, it will block any IPv6 packet with any IPv6 routing headers (both types 0 and 2). The configuration is given in the following example.
Router(config)#no ipv6 source-route
This is a global command and it applies to all interfaces. The command is applicable on all defined IPv6 addresses, including the link local and loopback address, and on all interfaces.
Mobile IPv6 is deployed
There is no workaround if you are running a Cisco IOS release prior to 12.4(2)T. In IOS 12.4(2)T a new keyword routing-type is added to IPv6 ACLs. It can be used to selectively permit or deny specific routing types.
Router(config)#ipv6 access-list deny-sourcerouted
Router(config-ipv6-acl)#deny ipv6 any
Router(config-ipv6-acl)#permit ipv6 any any
Router(config)#interface Ethernet0
Router(config-if)#ipv6 source-route
Router(config-if)#ipv6 traffic-filter deny-sourcerouted in
The filter must be applied to all interfaces that have IPv6 configured.
Obtaining Fixed Software
Cisco will make free software available to address this vulnerability for affected customers. This advisory will be updated as fixed software becomes available. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment.
Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/public/sw-license-agreement.html, or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml.
Do not contact either "psirt@cisco.com" or "security-alert@cisco.com" for software upgrades.
Customers with Service Contracts
Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com.
Customers using Third Party Support Organizations
Customers whose Cisco products are provided or maintained through prior or existing agreement with third-party support organizations such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory.
The effectiveness of any workaround or fix is dependent on specific customer situations such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed.
Customers without Service Contracts
Customers who purchase direct from Cisco but who do not hold a Cisco service contract and customers who purchase through third-party vendors but are unsuccessful at obtaining fixed software through their point of sale should get their upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows.
+1 800 553 2447 (toll free from within North America)
+1 408 526 7209 (toll call from anywhere in the world)
e-mail: tac@cisco.com
Have your product serial number available and give the URL of this notice as evidence of your entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC.
Refer to http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml for additional TAC contact information, including special localized telephone numbers and instructions and e-mail addresses for use in various languages.
Exploitation and Public Announcements
The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory.
This vulnerability was initially reported to Cisco by Arnaud Ebalard from EADS Corporate Research Center. An additional vector to trigger it was discovered internally while fixing the vulnerability.
Status of this Notice:FINAL
THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME.
A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors.
Distribution
This advisory is posted on Cisco's worldwide website at: http://www.cisco.com/warp/public/707/cisco-sa-20070124-IOS-IPv6.shtml
In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients.
cust-security-announce@cisco.com
first-teams@first.org
bugtraq@securityfocus.com
vulnwatch@vulnwatch.org
cisco@spot.colorado.edu
cisco@spot.colorado.edu
cisco-nsp@puck.nether.net
full-disclosure@lists.grok.org.uk
comp.dcom.sys.cisco@newsgate.cisco.com
Cisco Security Advisory: Crafted IP Option Vulnerability
Document ID: 81734
Advisory ID: cisco-sa-20070124-crafted-ip-option
http://www.cisco.com/warp/public/707/cisco-sa-20070124-crafted-ip-option.shtml
Revision 1.1
Last Updated 2007 January 25 1600 UTC (GMT)
For Public Release 2007 January 24 1600 UTC (GMT)
--------------------------------------------------------------------------------
Please provide your feedback on this document.
--------------------------------------------------------------------------------
Contents
Summary
Affected Products
Details
Vulnerability Scoring Details
Impact
Software Version and Fixes
Workarounds
Obtaining Fixed Software
Exploitation and Public Announcements
Status of this Notice: FINAL
Distribution
Revision History
Cisco Security Procedures
--------------------------------------------------------------------------------
Summary
Cisco routers and switches running Cisco IOS® or Cisco IOS XR software may be vulnerable to a remotely exploitable crafted IP option Denial of Service (DoS) attack. Exploitation of the vulnerability may potentially allow for arbitrary code execution. The vulnerability may be exploited after processing an Internet Control Message Protocol (ICMP) packet, Protocol Independent Multicast version 2 (PIMv2) packet, Pragmatic General Multicast (PGM) packet, or URL Rendezvous Directory (URD) packet containing a specific crafted IP option in the packet's IP header. No other IP protocols are affected by this issue.
Cisco has made free software available to address this vulnerability for affected customers.
There are workarounds available to mitigate the effects of the vulnerability.
This vulnerability was discovered during internal testing.
This advisory is available at http://www.cisco.com/warp/public/707/cisco-sa-20070124-crafted-ip-option.shtml.
Affected Products
Vulnerable Products
This issue affects all Cisco devices running Cisco IOS or Cisco IOS XR software and configured to process Internet Protocol version 4 (IPv4) packets. Devices which run only Internet Protocol version 6 (IPv6) are not affected.
This vulnerability is present in all unfixed versions of Cisco IOS software, including versions 9.x, 10.x, 11.x and 12.x.
This vulnerability is present in all unfixed versions of Cisco IOS XR software, including versions 2.0.X, 3.0.X, and 3.2.X.
All versions of Cisco IOS or Cisco IOS XR prior to the versions listed in the Fixed Software table below may be susceptible to this vulnerability.
To determine the software running on a Cisco product, log in to the device and issue the show version command to display the system banner. Cisco IOS software will identify itself as "Internetwork Operating System Software" or simply "IOS". On the next line of output, the image name will be displayed between parentheses, followed by "Version" and the IOS release name. Cisco IOS XR software will identify itself as "Cisco IOS XR Software" followed by "Version" and the version number. Other Cisco devices will not have the show version command or will give different output.
The following example identifies a Cisco product running Cisco IOS release 12.2(14)S16 with an installed image name of C7200-IS-M:
Cisco Internetwork Operating System Software
IOS (tm) 7200 Software (C7200-IS-M), Version 12.2(14)S16, RELEASE SOFTWARE (fc1)The release train label is "12.2".
The next example shows a product running IOS release 12.3(7)T12 with an image name of C7200-IK9S-M:
Cisco IOS Software, 7200 Software (C7200-IK9S-M), Version 12.3(7)T12, RELEASE SOFTWARE (fc1)Additional information about Cisco IOS Banners is available at http://www.cisco.com/en/US/products/sw/iosswrel/ps1828/products_white_paper09186a008018305e.shtml#3.
Cisco IOS XR Software is a member of the Cisco IOS software family that uses a microkernel-based distributed operating system infrastructure. Cisco IOS XR runs only on Cisco Carrier Routing System 1 (CRS-1) and Cisco XR 12000 series routers.
Additional information about Cisco IOS XR is available at http://www.cisco.com/en/US/products/ps5845/index.html
The following example shows partial output from the show version command which identifies a Cisco product running Cisco IOS XR release 3.3.0:
RP/0/RP0/CPU0:router#show version
Cisco IOS XR Software, Version 3.3.0
Copyright (c) 2006 by cisco Systems, Inc.
ROM: System Bootstrap, Version 1.32(20050525:193559) [CRS-1 ROMMON]Products Confirmed Not Vulnerable
Cisco devices that do not run Cisco IOS or Cisco IOS XR software are not affected. CatOS software is not affected by this issue.
No other Cisco products are currently known to be affected by this vulnerability.
Details
This vulnerability may be exploited when an affected device processes a packet that meets all three of the following conditions:
1. The packet contains a specific crafted IP option.
AND
2. The packet is one of the following protocols:
ICMP - Echo (Type 8) - 'ping'
ICMP - Timestamp (Type 13)
ICMP - Information Request (Type 15)
ICMP - Address Mask Request (Type 17)
PIMv2 - IP protocol 103
PGM - IP protocol 113
URD - TCP Port 465
AND
3. The packet is sent to a physical or virtual IPv4 address configured on the affected device.
No other ICMP message types are affected by this issue.
No other IP protocols are affected by this issue.
No other TCP services are affected by this issue.
The packet can be sent from a local network or from a remote network.
The source IP address of the packet can be spoofed or non-spoofed.
Packets which transit the device (packets not sent to one of the device's IP addresses) do not trigger the vulnerability and the device is not affected.
This vulnerability is documented in these Bug IDs:
Cisco Bug ID CSCec71950 ( registered customers only) for Cisco IOS
Cisco Bug ID CSCeh52410 ( registered customers only) for Cisco IOS XR
Cisco IOS
A crafted packet addressed directly to a vulnerable device running Cisco IOS software may result in the device reloading or may allow execution of arbitrary code.
Cisco IOS XR
A crafted packet addressed directly to a vulnerable device running Cisco IOS XR software may result in the ipv4_io process restarting or may allow execution of arbitrary code. CRS-1 Nodes that run the ipv4_io process include Route Processors (RP), Distributed Route Processors (DRP), Modular Services Cards (MSC), and XR 12000 Line Cards. While the ipv4_io process is restarting, all ICMP traffic destined for the device itself and exception punts will be dropped. Examples of exception punts include packets having IP header information that requires further processing such as IP options, Time-to-Live equal to 0 or 1, and layer-2 keepalives. CLNS traffic to the Node or Line Card is not affected. If the ipv4_io process is restarted several times consecutively, the CRS-1 Node or XR 12000 Line Card may reload, causing a Denial of Service (DoS) condition for the transit traffic switched on that Node or Line card.
Devices Configured for ICMP Message Types
ICMP Type 8
By default, devices running all Cisco IOS and Cisco IOS XR versions will process ICMP echo-request (Type 8) packets. This behavior cannot be modified.
ICMP Type 13
By default, devices running all Cisco IOS versions will process ICMP timestamp (Type 13) packets. This behavior cannot be modified.
By default, devices running all Cisco IOS XR versions will NOT process ICMP timestamp (Type 13) packets. This behavior cannot be modified.
ICMP Type 15
With the introduction of CSCdz50424, by default routers will NOT process ICMP information request (Type 15) packets. Releases of Cisco IOS that contain CSCdz50424 include 12.3, 12.3T, 12.4, 12.4T, later 12.0S and later 12.2S. See CSCdz50424 ( registered customers only) for complete release information.
A router running a Cisco IOS release containing CSCdz50424 that has been modified to process ICMP information request packets will have the interface configuration statement ip information-reply, which can be seen by issuing the command show running-config as shown in the following examples:
router#show running-config | include information-reply
ip information-replyor
router#show running-config
interface FastEthernet0/0
ip address 192.0.2.1 255.255.255.0
ip information-replyBy default, devices running all other Cisco IOS versions will process ICMP information request (Type 15) packets. This behavior cannot be modified. Since this is the default behavior, ip information-reply will not be visible in the device's configuration.
By default, devices running all Cisco IOS XR versions will NOT process ICMP information request (Type 15) packets. This behavior cannot be modified.
ICMP Type 17
Beginning in Cisco IOS version 10.0, by default devices will NOT process ICMP address mask request (Type 17) packets. A router that has been modified to process ICMP address mask request packets will have the interface configuration statement ip mask-reply, which can be seen by issuing the command show running-config as shown in the following examples:
router#show running-config | include mask-reply
ip mask-replyor
router#show running-config
interface FastEthernet0/0
ip address 192.0.2.1 255.255.255.0
ip mask-replyBy default, devices running all Cisco IOS XR versions will NOT process ICMP address mask request (Type 17) packets. A router that has been modified to process ICMP address mask request packets will have the interface configuration statement ipv4 mask-reply, which can be seen by issuing the command show running-config as shown in the following examples:
RP/0/RP0/CPU0:router#show running-config | include mask-reply
Building configuration...
ipv4 mask-replyor
RP/0/RP0/CPU0:router#show running-config
interface POS0/1/3/0
ipv4 address 192.0.2.1 255.255.255.252
ipv4 mask-replyDevices Configured for Protocol Independent Multicast Version 2 (PIMv2)
Cisco IOS
A router running Cisco IOS that is configured to process PIMv2 packets will have an interface configuration statement that begins with ip pim, which can be seen by issuing the command show running-config as shown in the following examples:
router#show running-config | include ip pim
ip pim sparse-modeor
router#show running-config
interface FastEthernet0/0
ip address 192.0.2.1 255.255.255.0
ip pim sparse-dense-modeThe command show ip pim interface can also be used to determine if a router is configured to process PIMv2 packets, as shown in the following example:
router#show ip pim interface
Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
192.0.2.1 FastEthernet0/0 v1/S 0 30 1 0.0.0.0
192.168.1.1 FastEthernet1/0 v2/SD 0 30 1 0.0.0.0Interfaces running PIMv2 will show "v2/" under the Ver/Mode column. Interfaces without PIM configured will not be shown in the command output.
PIMv2 is the default PIM version. Routers configured to process only PIMv1 messages are not vulnerable to the PIMv2 exploit. Routers that do not have PIM configured are not vulnerable to the PIMv2 exploit. PIM is not enabled by default.
Additional information about PIM is available at http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800ca794.html.
Cisco IOS XR
The command show pim interface can be used to determine if a router running Cisco IOS XR is configured to process PIMv2 packets, as shown in the following example:
RP/0/0/CPU0:router#show pim interface
Address Interface PIM Nbr Hello DR DR
Count Intvl Prior
192.168.1.1 Loopback0 on 1 30 1 this system
192.168.2.1 MgmtEth0/0/CPU0/0 off 0 30 1 not elected
192.168.3.1 Loopback1 on 1 30 1 this system
192.168.4.1 Loopback3 on 1 30 1 this system
192.168.5.1 POS0/4/0/0 on 1 30 1 this system
192.0.2.1 POS0/4/0/1 on 1 30 1 this systemInterfaces running PIMv2 will show on under the PIM column. Interfaces without PIM configured will show "off" under the PIM column.
Cisco IOS XR does not support PIMv1. PIM is not enabled by default on Cisco IOS XR.
Additional information about PIM on Cisco IOS XR is available at http://www.cisco.com/en/US/products/ps5845/products_configuration_guide_chapter09186a008069a8a2.html.
Devices Configured for Pragmatic General Multicast (PGM)
A router that is configured to process PGM packets will have the interface configuration statement ip pgm router, which can be seen by issuing the command show running-config as shown in the following examples:
router#show running-config | include ip pgm
ip pgm routeror
router#show running-config
interface FastEthernet1/0
ip address 192.0.2.1 255.255.255.0
ip pim sparse-dense-mode
ip pgm routeror
router#show running-config
interface FastEthernet1/0
ip address 192.0.2.1 255.255.255.0
ip pgm routerRouters that do not have PGM configured are not vulnerable to the PGM exploit. PGM is not enabled by default.
Additional information about PGM is available at http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800ca798.html.
Cisco IOS XR does not support PGM and is not affected by PGM packets that exploit this vulnerability.
Devices Configured for URL Rendezvous Directory (URD)
A router that is configured to process URD packets will have the interface configuration statement ip urd or ip urd proxy, which can be seen by issuing the command show running-config as shown in the following examples:
router#show running-config | include ip urd
ip urdor
router#show running-config | include ip urd
ip urd proxyor
router#show running-config
interface FastEthernet1/0
ip address 192.0.2.1 255.255.255.0
ip pim sparse-mode
ip urdor
router#show running-config
interface FastEthernet1/0
ip address 192.0.2.1 255.255.255.0
ip pim sparse-dense-mode
ip urd proxyor
router#show running-config
interface FastEthernet1/0
ip address 192.0.2.1 255.255.255.0
ip urdRouters that do not have URD configured are not vulnerable to the URD exploit. URD is not enabled by default.
Additional information about URD is available at http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800ca795.html.
Cisco IOS XR does not support URD and is not affected by URD packets that exploit this vulnerability.
Vulnerability Scoring Details
Cisco is providing scores for the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). Cisco will provide a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks.
Cisco PSIRT will set the bias in all cases to normal. Customers are encouraged to apply the bias parameter when determining the environmental impact of a particular vulnerability.
CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response.
Cisco has provided an FAQ to answer additional questions regarding CVSS at http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html.
Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at http://intellishield.cisco.com/security/alertmanager/cvss.
CSCec71950 ( registered customers only) - Crafted IP Option may cause DoS or code execution
Calculate the environmental score of CSCec71950
CVSS Base Score - 10
Access Vector
Access Complexity
Authentication
Confidentiality Impact
Integrity Impact
Availability Impact
Impact Bias
Remote
Low
Not Required
Complete
Complete
Complete
Normal
CVSS Temporal Score - 8.3
Exploitability
Remediation Level
Report Confidence
Functional
Official Fix
Confirmed
CSCeh52410 ( registered customers only) - Crafted IP Option may cause ipv4-io DoS or code execution
Calculate the environmental score of CSCeh52410
CVSS Base Score - 10
Access Vector
Access Complexity
Authentication
Confidentiality Impact
Integrity Impact
Availability Impact
Impact Bias
Remote
Low
Not Required
Complete
Complete
Complete
Normal
CVSS Temporal Score - 8.3
Exploitability
Remediation Level
Report Confidence
Functional
Official Fix
Confirmed
Impact
Cisco IOS
Successful exploitation of the vulnerability on Cisco IOS may result in a reload of the device or execution of arbitrary code. Repeated exploitation could result in a sustained DoS attack.
Cisco IOS XR
Successful exploitation of the vulnerability on Cisco IOS XR may result in the ipv4_io process restarting or execution of arbitrary code. Repeated exploitation could result in a CRS-1 Node or XR 12000 Line Card reload and sustained DoS attack.
Software Version and Fixes
When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution.
In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center ("TAC") or your contracted maintenance provider for assistance.
Each row of the Cisco IOS software table (below) describes a release train and the platforms or products for which it is intended. If a given release train is vulnerable, then the earliest possible releases that contain the fix (the "First Fixed Release") and the anticipated date of availability for each are listed in the "Rebuild" and "Maintenance" columns. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. The release should be upgraded at least to the indicated release or a later version (greater than or equal to the First Fixed Release label).
For more information on the terms "Rebuild" and "Maintenance," consult the following URL: http://www.cisco.com/en/US/products/sw/iosswrel/ps1828/products_white_paper09186a008018305e.shtml.
Note: There are three IOS security advisories and one field notice being published on January 24, 2007. Each advisory lists only the releases which fix the issue described in the advisory. A combined software table is available at http://www.cisco.com/warp/public/707/cisco-sa-20070124-bundle.shtml and can be used to choose a software release which fixes all security vulnerabilities published as of January 24, 2007. Links for the advisories and field notice are listed here.
http://www.cisco.com/warp/public/707/cisco-sa-20070124-IOS-IPv6.shtml
http://www.cisco.com/warp/public/707/cisco-sa-20070124-crafted-tcp.shtml
http://www.cisco.com/warp/public/707/cisco-sa-20070124-crafted-ip-option.shtml
http://www.cisco.com/warp/public/770/fn62613.shtml
Requests for software rebuilds to include the change for Daylight Savings Time (DST) that will be implemented in March 2007 should be directed through the Technical Assistance Center (TAC), and this advisory should be used as reference.
Major Release
Availability of Repaired Releases
Affected 12.0-Based Release
Rebuild
Maintenance
12.0
Vulnerable; migrate to 12.2(37)or later
12.0DA
Vulnerable; migrate to 12.2(10)DA5 or later
12.0DB
Vulnerable; migrate to 12.3(4)T13 or later
12.0DC
Vulnerable; migrate to 12.3(4)T13 or later
12.0S
12.0(27)S3
12.0(28)S
12.0SC
Vulnerable; migrate to 12.3(9a)BC or later
12.0SL
Vulnerable; migrate to 12.0(28)S or later
12.0SP
Vulnerable; migrate to 12.0(28)S or later
12.0ST
Vulnerable; migrate to 12.0(28)S or later
12.0SX
12.0(25)SX11
12.0(30)SX
12.0SY
12.0(27)SY
12.0SZ
12.0(30)SZ
12.0T
Vulnerable; migrate to 12.2(37)or later
12.0W
12.0(28)W5(32c); available 31-Jan-07
12.0WC
12.0(5)WC15
12.0WT
Vulnerable; contact TAC
12.0XA
Vulnerable; migrate to 12.2(37)or later
12.0XB
Vulnerable; migrate to 12.2(37)or later
12.0XC
Vulnerable; migrate to 12.2(37)or later
12.0XD
Vulnerable; migrate to 12.2(37)or later
12.0XE
Vulnerable; migrate to 12.1(23)E or later
12.0XF
Not vulnerable
12.0XG
Vulnerable; migrate to 12.2(37)or later
12.0XH
Vulnerable; migrate to 12.2(37)or later
12.0XI
Vulnerable; migrate to 12.2(37)or later
12.0XJ
Vulnerable; migrate to 12.2(37)or later
12.0XK
Vulnerable; migrate to 12.2(37)or later
12.0XL
Vulnerable; migrate to 12.2(37)or later
12.0XM
Vulnerable; migrate to 12.2(37)or later
12.0XN
Vulnerable; migrate to 12.2(37)or later
12.0XQ
Vulnerable; migrate to 12.2(37)or later
12.0XR
Vulnerable; migrate to 12.2(37)or later
12.0XS
Vulnerable; migrate to 12.1(23)E or later
12.0XV
Vulnerable; migrate to 12.2(37)or later
12.0XW
Vulnerable; migrate to 12.0(5)WC15 or later
Affected 12.1-Based Release
Rebuild
Maintenance
12.1
Vulnerable; migrate to 12.2(37)or later
12.1AA
Vulnerable; migrate to 12.2(37)or later
12.1AX
Vulnerable; for c3750-ME, migrate to 12.2(25)EY or later. For c2970 and 3750, migrate to 12.2(25)SE or later.
12.1AY
Vulnerable; migrate to 12.1(22)EA8
12.1AZ
Vulnerable; migrate to 12.1(22)EA8
12.1CX
Vulnerable; migrate to 12.2(37)or later
12.1DA
Vulnerable; migrate to 12.2(10)DA5 or later
12.1DB
Vulnerable; migrate to 12.3(4)T13 or later
12.1DC
Vulnerable; migrate to 12.3(4)T13 or later
12.1E
12.1(23)E
12.1EA
12.1(22)EA8
12.1EB
12.1(23)EB
12.1EC
Vulnerable; migrate to 12.3(9a)BC or later
12.1EO
12.1(19)EO6, available 31-Jan-07
12.1(20)EO3
12.1EU
Vulnerable; migrate to 12.2(25)EWA or later
12.1EV
Vulnerable; migrate to 12.2(26)SV1 or later
12.1EW
Vulnerable; migrate to 12.2(18)EW3 or later
12.1EX
Vulnerable; migrate to 12.1(23)E or later
12.1EY
Vulnerable; migrate to 12.1(23)E or later
12.1EZ
Vulnerable; migrate to 12.1(23)E or later
12.1T
Vulnerable; migrate to 12.2(37)or later
12.1XA
Vulnerable; migrate to 12.2(37)or later
12.1XB
Vulnerable; migrate to 12.2(37)or later
12.1XC
Vulnerable; migrate to 12.2(37)or later
12.1XD
Vulnerable; migrate to 12.2(37)or later
12.1XE
Vulnerable; migrate to 12.1(23)E or later
12.1XF
Vulnerable; migrate to 12.3(8) or later
12.1XG
Vulnerable; migrate to 12.3(8) or later
12.1XH
Vulnerable; migrate to 12.2(37)or later
12.1XI
Vulnerable; migrate to 12.2(37)or later
12.1XJ
Vulnerable; migrate to 12.3(8) or later
12.1XL
Vulnerable; migrate to 12.3(8) or later
12.1XM
Vulnerable; migrate to 12.3(8) or later
12.1XP
Vulnerable; migrate to 12.3(8) or later
12.1XQ
Vulnerable; migrate to 12.3(8) or later
12.1XR
Vulnerable; migrate to 12.3(8) or later
12.1XS
Vulnerable; migrate to 12.2(37)or later
12.1XT
Vulnerable; migrate to 12.3(8) or later
12.1XU
Vulnerable; migrate to 12.3(8) or later
12.1XV
Vulnerable; migrate to 12.3(8) or later
12.1XW
Vulnerable; migrate to 12.2(37)or later
12.1XX
Vulnerable; migrate to 12.2(37)or later
12.1XY
Vulnerable; migrate to 12.2(37)or later
12.1XZ
Vulnerable; migrate to 12.2(37)or later
12.1YA
Vulnerable; migrate to 12.3(8) or later
12.1YB
Vulnerable; migrate to 12.3(8) or later
12.1YC
Vulnerable; migrate to 12.3(8) or later
12.1YD
Vulnerable; migrate to 12.3(8) or later
12.1YE
Vulnerable; migrate to 12.3(8) or later
12.1YF
Vulnerable; migrate to 12.3(8) or later
12.1YH
Vulnerable; migrate to 12.3(8) or later
12.1YI
Vulnerable; migrate to 12.3(8) or later
12.1YJ
Vulnerable; migrate to 12.1(22)EA8
Affected 12.2-Based Release
Rebuild
Maintenance
12.2
12.2(34a)
12.2(37)
12.2B
Vulnerable; migrate to 12.3(4)T13 or later
12.BC
Vulnerable; migrate to 12.3(9a)BC or later
12.2BW
Vulnerable; migrate to 12.3(8) or later
12.2BY
Vulnerable; migrate to 12.3(4)T13 or later
12.2BZ
Vulnerable; migrate to 12.3(7)XI8 or later
12.2CX
Vulnerable; migrate to 12.3(9a)BC or later
12.2CY
Vulnerable; migrate to 12.3(9a)BC or later
12.2CZ
Vulnerable; contact TAC
12.2DA
12.2(10)DA5
12.2(12)DA10
12.2DD
Vulnerable; migrate to 12.3(4)T13 or later
12.2DX
Vulnerable; migrate to 12.3(4)T13 or later
12.2EU
Vulnerable; migrate to 12.2(25)EWA5 or later
12.2EW
12.2(18)EW3
12.2(20)EW4
12.2(25)EW
12.2EWA
12.2(20)EWA4
12.2(25)EWA
12.2EX
12.2(25)EX
12.2EY
All 12.2EY releases are fixed
12.2EZ
All 12.2EZ releases are fixed
12.2FX
All 12.2FX releases are fixed
12.2FY
All 12.2FY releases are fixed
12.2FZ
All 12.2FZ releases are fixed
12.2IXA
All 12.2IXA releases are fixed
12.2IXB
All 12.2IXB releases are fixed
12.2IXC
All 12.2IXC releases are fixed
12.2JA
Vulnerable; migrate to 12.3(8)JA or later
12.2JK
Vulnerable; migrate to 12.4(4)T or later
12.2MB
Vulnerable; migrate to 12.2(25)SW1 or later
12.2MC
12.2(15)MC2h
12.2S
12.2(25)S
12.2SB
12.2(28)SB
12.2SBC
All 12.2SBC releases are fixed
12.2SE
12.2(25)SE
12.2SEA
All 12.2SEA releases are fixed
12.2SEB
All 12.2SEB releases are fixed
12.2SEC
All 12.2SEC releases are fixed
12.2SED
All 12.2SED releases are fixed
12.2SEE
All 12.2SEE releases are fixed
12.2SEF
All 12.2SEF releases are fixed
12.2SEG
All 12.2SEG releases are fixed
12.2SG
All 12.2SG releases are fixed
12.2SGA
All 12.2SGA releases are fixed
12.2SO
12.2(18)SO7
12.2SRA
All 12.2SRA releases are fixed
12.2SRB
All 12.2SRB releases are fixed
12.2SU
Vulnerable; migrate to 12.3(14)T or later
12.2SV
12.2(23)SV
12.2SW
12.2(25)SW1
12.2SX
Vulnerable; migrate to 12.2(17d)SXB11a or later
12.2SXA
Vulnerable; migrate to 12.2(17d)SXB11a or later
12.2SXB
12.2(17d)SXB11a
12.2SXD
12.2(18)SXD7a
12.2SXE
All 12.2SXE releases are fixed
12.2SXF
All 12.2SXF releases are fixed
12.2SY
Vulnerable; migrate to 12.2(17d)SXB11a or later
12.2SZ
Vulnerable; migrate to 12.2(25)S or later
12.2T
Vulnerable; migrate to 12.3(8) or later
12.2TPC
Vulnerable; contact TAC
12.2XA
Vulnerable; migrate to 12.3(8) or later
12.2XB
Vulnerable; migrate to 12.3(8) or later
12.2XC
Vulnerable; migrate to 12.3(8)T or later
12.2XD
Vulnerable; migrate to 12.3(8) or later
12.2XE
Vulnerable; migrate to 12.3(8) or later
12.2XF
Vulnerable; migrate to 12.3(9a)BC or later
12.2XG
Vulnerable; migrate to 12.3(8) or later
12.2XH
Vulnerable; migrate to 12.3(8) or later
12.2XI
Vulnerable; migrate to 12.3(8) or later
12.2XJ
Vulnerable; migrate to 12.3(8) or later
12.2XK
Vulnerable; migrate to 12.3(8) or later
12.2XL
Vulnerable; migrate to 12.3(8) or later
12.2XM
Vulnerable; migrate to 12.3(8) or later
12.2XN
Vulnerable; migrate to 12.3(8) or later
12.2XQ
Vulnerable; migrate to 12.3(8) or later
12.2XR
Vulnerable; migrate to 12.3(8) or later
12.2XS
Vulnerable; migrate to 12.3(8) or later
12.2XT
Vulnerable; migrate to 12.3(8) or later
12.2XU
Vulnerable; migrate to 12.3(12) or later
12.2XV
Vulnerable; migrate to 12.3(8) or later
12.2XW
Vulnerable; migrate to 12.3(8) or later
12.2YA
Vulnerable; migrate to 12.3(8) or later
12.2YB
Vulnerable; migrate to 12.3(8) or later
12.2YC
Vulnerable; migrate to 12.3(8) or later
12.2YD
Vulnerable; migrate to 12.3(8)T or later
12.2YE
Vulnerable; migrate to 12.2(25)S or later
12.2YF
Vulnerable; migrate to 12.3(8) or later
12.2YG
Vulnerable; migrate to 12.3(8) or later
12.2YH
Vulnerable; migrate to 12.3(8) or later
12.2YJ
Vulnerable; migrate to 12.3(8) or later
12.2YK
Vulnerable; migrate to 12.3(8)T or later
12.2YL
Vulnerable; migrate to 12.3(8)T or later
12.2YM
Vulnerable; migrate to 12.3(8)T or later
12.2YN
Vulnerable; migrate to 12.3(8)T or later
12.2YO
Not vulnerable
12.2YP
Vulnerable; migrate to 12.3(8) or later
12.2YQ
Vulnerable; migrate to 12.3(4)T13 or later
12.2YR
Vulnerable; migrate to 12.3(4)T13 or later
12.2YS
Vulnerable; migrate to 12.3(8)T or later
12.2YT
Vulnerable; migrate to 12.3(8) or later
12.2YU
Vulnerable; migrate to 12.3(8)T or later
12.2YV
Vulnerable; migrate to 12.3(4)T13 or later
12.2YW
Vulnerable; migrate to 12.3(8)T or later
12.2YX
Vulnerable; migrate to 12.3(14)T or later
12.2YY
Vulnerable; migrate to 12.3(4)T13 or later
12.2YZ
Vulnerable; migrate to 12.2(25)S or later
12.2ZA
Vulnerable; migrate to 12.2(17d)SXBa or later
12.2ZB
Vulnerable; migrate to 12.3(8)T or later
12.2ZC
Vulnerable; migrate to 12.3(8)T or later
12.2ZD
Vulnerable; contact TAC
12.2ZE
Vulnerable; migrate to 12.3(8) or laer
12.2ZF
Vulnerable; migrate to 12.3(4)T13 or later
12.2ZG
Vulnerable; for SOHO9x, migrate to 12.3(8)YG2 or later. For c83x, migrate to 12.3(2)XA3 or later
12.2ZH
Vulnerable; contact TAC
12.2ZJ
Vulnerable; migrate to 12.3(8)T or later
12.2ZL
Vulnerable; contact TAC
12.2ZN
Vulnerable; migrate to 12.3(4)T13 or later
12.2ZP
Vulnerable; migrate to 12.3(8)XY or later
Affected 12.3-Based Release
Rebuild
Maintenance
12.3
12.3(8)
12.3B
Vulnerable; migrate to 12.3(8)T7 or later
12.3BC
12.3(9a)BC
12.3BW
Vulnerable; migrate to 12.3(8)T or later
12.3JA
12.3(8)JA
12.3JEA
All 12.3JEA releases are fixed
12.3JEB
All 12.3JEA releases are fixed
12.3JK
12.3(2)JK2
12.3(8)JK
12.3JX
12.3(7)JX6
12.3(11)JX
12.3T
12.3(4)T13
12.3(8)T
12.3TPC
12.3(4)TPC11b
12.3XA
12.3(2)XA6
12.3XB
Vulnerable; migrate to 12.3(8)T or later
12.3XC
Vulnerable; contact TAC
12.3XD
Vulnerable; migrate to 12.3(8)T7 or later
12.3XE
Vulnerable; contact TAC
12.3XF
Vulnerable; migrate to 12.3(11)T or later
12.3XG
Vulnerable; contact TAC
12.3XH
Vulnerable; migrate to 12.3(11)T or later
12.3XI
12.3(7)XI8
12.3XJ
Vulnerable; migrate to 12.3(8)XW or later
12.3XK
Vulnerable; migrate to 12.3(14)T or later
12.3XQ
Vulnerable; migrate to 12.4(1) or later
12.3XR
All 12.3XR releases are fixed
12.3XS
All 12.3XS releases are fixed
12.3XU
All 12.3XU releases are fixed
12.3XW
All 12.3XW releases are fixed
12.3XX
All 12.3XX releases are fixed
12.3XY
All 12.3XR releases are fixed
12.3YA
All 12.3YA releases are fixed
12.3YD
All 12.3YD releases are fixed
12.3YF
All 12.3YF releases are fixed
12.3YG
All 12.3YG releases are fixed
12.3YH
All 12.3YH releases are fixed
12.3YI
All 12.3YI releases are fixed
12.3YJ
All 12.3YJ releases are fixed
12.3YK
All 12.3YK releases are fixed
12.3YM
All 12.3YM releases are fixed
12.3YQ
All 12.3YQ releases are fixed
12.3YS
All 12.3YS releases are fixed
12.3YT
All 12.3YT releases are fixed
12.3YU
All 12.3YU releases are fixed
12.3YX
All 12.3YX releases are fixed
12.3YZ
All 12.3YZ releases are fixed
Affected 12.4-Based Release
Rebuild
Maintenance
All 12.4 releases are fixed
Cisco IOS XR Version
SMU ID
Package Installation Envelopes
3.2.2 for CRS-1
AA01482
hfr-base-3.2.2.CSCeh52410.pie
3.2.3 for CRS-1
AA01483
hfr-base-3.2.3.CSCeh52410.pie
3.2.4 for CRS-1
AA01484
hfr-base-3.2.4.CSCeh52410.pie
3.2.6 for CRS-1
AA01727
hfr-base-3.2.6.CSCeh52410.pie
3.3.x for CRS-1 and XR12000
Fixed
3.4.x for CRS-1 and XR12000
Fixed
IOS XR Package Installation Envelopes (PIE) can be downloaded from: http://www.cisco.com/pcgi-bin/tablebuild.pl/iosxr-smu?sort=release ( registered customers only) . Installation instructions are included in the accompanying .txt files.
Workarounds
Additional mitigations that can be deployed on Cisco devices within the network are available in the Cisco Applied Intelligence companion document for this advisory:
http://www.cisco.com/warp/public/707/cisco-air-20070124-crafted-ip-option.shtml
IP Options Selective Drop
The IP Options Selective Drop feature allows Cisco routers to mitigate the effects of IP options by dropping packets containing them or by not processing (ignoring) IP options in a packet.
The most effective workaround is using the "drop" option of this global configuration command: ip options drop. This command will drop all IP packets containing IP options that are both destined to the router itself or transiting through the router before they are processed, preventing exploitation locally and downstream.
The IP Options Selective Drop feature is available beginning in Cisco IOS software version 12.0(23)S for 12000, 12.0(32)S for 10720, and 12.3(4)T, 12.2(25)S, and 12.2(27)SBC for other hardware platforms.
Please note that deploying this command will drop legitimate packets containing IP options as well. Protocols this may impact include RSVP (used by Microsoft NetMeeting), MPLS TE, MPLS OAM, DVMRP, IGMPv3, IGMPv2, and legitimate PGM.
Note: The ignore option of the global command ip options ignore, available only on the Cisco 12000 router beginning in 12.0(23)S, is NOT a workaround for this issue.
Additional information about IP Options Selective Drop feature is available at http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_feature_guide09186a00801d4a94.html.
Transit Access Control Lists (ACLs)
Configure an interface ACL that blocks traffic of these types:
Echo (Ping) ICMP type 8
Timestamp ICMP type 13
Information Request ICMP type 15
Address Mask Request ICMP Type 17
Protocol Independent Multicast (PIM) IP protocol 103
Pragmatic General Multicast (PGM) IP protocol 113
URL Rendezvous Directory (URD) TCP port 465
The Internet Control Message Protocol is an integral part of the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite that is used to report error conditions and provide diagnostic information. Filtering ICMP messages may impact this error condition and diagnostic reporting including "ping" and Windows traceroute which uses ICMP ping.
If the device is configured to process PIM, PGM, or URD, blocking those packets will prevent legitimate operation of the protocols.
Since the source IP address of these packets can be easily spoofed, the affected traffic should be blocked on all of the device's IPv4 interfaces.
The following ACL is specifically designed to block attack traffic and should be applied to all IPv4 interfaces of the device and should include topology-specific filters:
access-list 150 deny icmp any any echo
access-list 150 deny icmp any any information-request
access-list 150 deny icmp any any timestamp-request
access-list 150 deny icmp any any mask-request
access-list 150 deny tcp any any eq 465
access-list 150 deny 103 any any
access-list 150 deny 113 any any
access-list 150 permit ip any any
interface serial 2/0
ip access-group 150 inThese ACL statements should be deployed at the network edge as part of a transit access list which will protect the router where the ACL is configured as well as other devices behind it. Further information about transit ACLs is available in the white paper "Transit Access Control Lists: Filtering at Your Edge", available at http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801afc76.shtml.
The following Cisco IOS XR ACL is specifically designed to block attack traffic and should be applied to all IPv4 interfaces of the device and should include topology-specific filters:
ipv4 access-list ios-xr-transit-acl
10 deny icmp any any echo
20 deny icmp any any information-request
30 deny icmp any any timestamp-request
40 deny icmp any any mask-request
50 deny tcp any any eq 465
60 deny 103 any any
70 deny 113 any any
80 permit ip any any
interface POS 0/2/0/
ipv4 access-group ios-xr-transit-acl ingressInformation about configuring access lists on Cisco IOS XR is available at http://www.cisco.com/en/US/products/ps5763/products_command_reference_chapter09186a00803e01ae.html.
Infrastructure ACLs
Although it is often difficult to block traffic transiting your network, it is possible to identify traffic which should never be allowed to target your infrastructure devices and block that traffic at the border of your network. Infrastructure ACLs are considered a network security best practice and should be considered as a long-term addition to good network security as well as a workaround for this specific vulnerability. The ACL example shown below should be included as part of the deployed infrastructure access list which will protect all devices with IP addresses in the infrastructure IP address range.
Cisco IOS
access-list 150 deny icmp any INFRASTRUCTURE_ADDRESSES echo
access-list 150 deny icmp any INFRASTRUCTURE_ADDRESSES information-request
access-list 150 deny icmp any INFRASTRUCTURE_ADDRESSES timestamp-request
access-list 150 deny icmp any INFRASTRUCTURE_ADDRESSES mask-request
access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES eq 465
access-list 150 deny 103 any INFRASTRUCTURE_ADDRESSES
access-list 150 deny 113 any INFRASTRUCTURE_ADDRESSES
access-list 150 permit ip any any
interface serial 2/0
ip access-group 150 inCisco IOS XR
ipv4 access-list ios-xr-infrastructure-acl
10 deny icmp any INFRASTRUCTURE_ADDRESSES echo
20 deny icmp any INFRASTRUCTURE_ADDRESSES information-request
30 deny icmp any INFRASTRUCTURE_ADDRESSES timestamp-request
40 deny icmp any INFRASTRUCTURE_ADDRESSES mask-request
50 deny tcp any INFRASTRUCTURE_ADDRESSES eq 465
60 deny 103 any INFRASTRUCTURE_ADDRESSES
70 deny 113 any INFRASTRUCTURE_ADDRESSES
80 permit ip any any
interface POS 0/2/0/2
ipv4 access-group ios-xr-infrastructure-acl ingressThe white paper entitled "Protecting Your Core: Infrastructure Protection Access Control Lists" presents guidelines and recommended deployment techniques for infrastructure protection access lists and is available at http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml.
Information about configuring access lists on Cisco IOS XR is available at http://www.cisco.com/en/US/products/ps5763/products_command_reference_chapter09186a00803e01ae.html.
Receive ACLs
For distributed platforms, receive ACLs may be an option starting in Cisco IOS Software Versions 12.0(21)S2 for the 12000 (GSR), 12.0(24)S for the 7500, and 12.0(31)S for the 10720. The receive ACL protects the device from harmful traffic before the traffic can impact the route processor. A receive ACL is designed to protect only the device on which it is configured. On the 12000, transit traffic is never affected by a receive ACL. Because of this, the destination IP address "any" used in the example ACL entries below only refer to the router's own physical or virtual IP addresses. On the 7500 and 10720, transit traffic with IP options set will be subject to the receive ACL and permitted or denied accordingly. Receive ACLs are considered a network security best practice and should be considered as a long-term addition to good network security as well as a workaround for this specific vulnerability.
The white paper entitled "GSR: Receive Access Control Lists" will help you identify and allow legitimate traffic to your device and deny all unwanted packets and is available at http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a0a5e.shtml
The following receive path ACL is designed specifically to block this attack traffic:
access-list 101 deny icmp any any echo
access-list 101 deny icmp any any information-request
access-list 101 deny icmp any any timestamp-request
access-list 101 deny icmp any any mask-request
access-list 101 deny tcp any any eq 465
access-list 101 deny 103 any any
access-list 101 deny 113 any any
access-list 101 permit ip any any
!
ip receive access-list 101Control Plane Policing
The Control Plane Policing (CoPP) feature may be used to mitigate this vulnerability. In the following example, any packets that can exploit the vulnerability are denied while all other IP traffic is permitted. Because of the way routers process packets with IP options, CoPP will be applied to attack packets destined for the router itself and packets transiting through the router to other destination IP addresses. This applies to all platforms except the 12000 where only attack packets destined for the router itself will be dropped.
access-list 100 permit icmp any any echo
access-list 100 permit icmp any any information-request
access-list 100 permit icmp any any timestamp-request
access-list 100 permit icmp any any mask-request
access-list 100 permit tcp any any eq 465
access-list 100 permit 103 any any
access-list 100 permit 113 any any
access-list 100 deny ip any any
!
class-map match-all drop-options-class
match access-group 100
!
!
policy-map drop-options-policy
class drop-options-class
drop
!
control-plane
service-policy input drop-options-policyPlease note that in the 12.0S, 12.2S, and 12.2SX Cisco IOS trains, the policy-map syntax is different:
policy-map drop-options-policy
class drop-options-class
police 32000 1500 1500 conform-action drop exceed-action dropBecause of the way routers process packets with IP options, CoPP will be applied to attack packets destined for the router itself and packets transiting through the router to other destination IP addresses. In the following example, only packets with IP options that can exploit the vulnerability and that are destined for the router or that transit through the router are denied while all other IP traffic is permitted.
ip access-list extended drop-affected-options
permit icmp any any echo option any-options
permit icmp any any information-request option any-options
permit icmp any any timestamp-request option any-options
permit icmp any any mask-request option any-options
permit pim any any option any-options
permit 113 any any option any-options
permit tcp any any eq 465 option any-options
deny ip any any
!
class-map match-all drop-options-class
match access-group name drop-affected-options
!
!
policy-map drop-opt-policy
class drop-options-class
drop
!
control-plane
service-policy input drop-opt-policyPlease note that in the 12.2S Cisco IOS train, the policy-map syntax is different:
policy-map drop-opt-policy
class drop-options-class
police 32000 1500 1500 conform-action drop exceed-action dropCoPP is available in Cisco IOS release trains 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T.
ACL support for filtering IP options requires named ACLs. ACL support for filtering IP options is not available in 12.0S or 12.2SX.
Please note that PGM packets typically use the "Router Alert" Option, and dropping PGM packets with IP options will affect legitimate PGM packets.
In the above CoPP examples, the ACL entries that match the exploit packets with the "permit" action result in these packets being discarded by the policy-map drop function, while packets that match the "deny" action are not affected by the policy-map drop function.
Additional information on the configuration and use of the CoPP feature can be found at http://www.cisco.com/en/US/products/ps6642/products_white_paper0900aecd804fa16a.shtml and http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_feature_guide09186a008052446b.html.
Additional information for filtering IP Options with access lists can be found at http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00801d4a7d.html.
Obtaining Fixed Software
Cisco will make free software available to address this vulnerability for affected customers. This advisory will be updated as fixed software becomes available. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment.
Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/public/sw-license-agreement.html, or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml.
Do not contact either "psirt@cisco.com" or "security-alert@cisco.com" for software upgrades.
Customers with Service Contracts
Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com.
Customers using Third Party Support Organizations
Customers whose Cisco products are provided or maintained through prior or existing agreement with third-party support organizations such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory.
The effectiveness of any workaround or fix is dependent on specific customer situations such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed.
Customers without Service Contracts
Customers who purchase direct from Cisco but who do not hold a Cisco service contract and customers who purchase through third-party vendors but are unsuccessful at obtaining fixed software through their point of sale should get their upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows.
+1 800 553 2447 (toll free from within North America)
+1 408 526 7209 (toll call from anywhere in the world)
e-mail: tac@cisco.com
Have your product serial number available and give the URL of this notice as evidence of your entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC.
Refer to http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml for additional TAC contact information, including special localized telephone numbers and instructions and e-mail addresses for use in various languages.
Exploitation and Public Announcements
The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory. This vulnerability was discovered during internal testing.
Status of this Notice: FINAL
THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME.
A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors.
Distribution
This advisory is posted on Cisco's worldwide website at :
http://www.cisco.com/warp/public/707/cisco-sa-20070124-crafted-ip-option.shtml
In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients.
cust-security-announce@cisco.com
first-teams@first.org
bugtraq@securityfocus.com
vulnwatch@vulnwatch.org
cisco@spot.colorado.edu
cisco-nsp@puck.nether.net
full-disclosure@lists.grok.org.uk
comp.dcom.sys.cisco@newsgate.cisco.com
Cisco Security Advisory: Crafted TCP Packet Can Cause Denial of Service
Document ID: 72318
Advisory ID: cisco-sa-20070124-crafted-tcp
http://www.cisco.com/warp/public/707/cisco-sa-20070124-crafted-tcp.shtml
1.0
For Public Release 2007 January 24 1600 UTC (GMT)
--------------------------------------------------------------------------------
Please provide your feedback on this document.
--------------------------------------------------------------------------------
Contents
Summary
Affected Products
Details
Vulnerability Scoring Details
Impact
Software Version and Fixes
Workarounds
Obtaining Fixed Software
Exploitation and Public Announcements
Status of this Notice:FINAL
Distribution
Revision History
Cisco Security Procedures
--------------------------------------------------------------------------------
Summary
The Cisco IOS Transmission Control Protocol (TCP) listener in certain versions of Cisco IOS software is vulnerable to a remotely-exploitable memory leak that may lead to a denial of service condition.
This vulnerability only applies to traffic destined to the Cisco IOS device. Traffic transiting the Cisco IOS device will not trigger this vulnerability.
Cisco has made free software available to address this vulnerability for affected customers.
This issue is documented as Cisco bug ID CSCek37177 ( registered customers only) .
There are workarounds available to mitigate the effects of the vulnerability.
This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20070124-crafted-tcp.shtml.
Affected Products
Vulnerable Products
This issue affects all Cisco devices running Cisco IOS software. To be affected, devices must be configured to process Internet Protocol version 4 (IPv4) packets and receive TCP packets. Devices which run only Internet Protocol version 6 (IPv6) are not affected.
This vulnerability is present in all unfixed versions of Cisco IOS software, including versions 9.x, 10.x, 11.x and 12.x.
To determine the software running on a Cisco product, log in to the device and issue the "show version" command to display the system banner. Cisco IOS software will identify itself as "Internetwork Operating System Software" or simply "IOS". On the next line of output, the image name will be displayed between parentheses, followed by "Version" and the IOS release name. Other Cisco devices will not have the "show version" command or will give different output.
The following example identifies a Cisco product running Cisco IOS release 12.2(14)S16 with an installed image name of C7200-IS-M:
Cisco Internetwork Operating System Software
IOS (tm) 7200 Software (C7200-IS-M), Version 12.2(14)S16, RELEASE SOFTWARE (fc1)The release train label is "12.2".
The next example shows a product running IOS release 12.3(7)T12 with an image name of C7200-IK9S-M:
Cisco IOS Software, 7200 Software (C7200-IK9S-M), Version 12.3(7)T12, RELEASE SOFTWARE (fc1)
Additional information about Cisco IOS Banners is available at:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1828/products_white_paper09186a008018305e.shtml#3
Products Confirmed Not Vulnerable
Cisco products that do not run IOS are unaffected by this vulnerability.
Cisco IOS-XR is not affected.
No other Cisco products are currently known to be affected by this vulnerability.
Details
TCP is the transport layer protocol designed to provide connection-oriented, reliable delivery of a data stream. To accomplish this, TCP uses a mixture of flags to indicate state and sequence numbers to identify the order in which the packets are to be reassembled. TCP also provides a number, called an acknowledgement number, that is used to indicate the sequence number of the next packet expected. The full specification of the TCP protocol can be found at http://www.ietf.org/rfc/rfc0793.txt .
Cisco IOS devices that are configured to receive TCP packets are exposed to this issue. This Advisory does not apply to traffic that is transiting the device.
Certain crafted packets destined to an IPv4 address assigned to a physical or virtual interface on a Cisco IOS device may cause the device to leak a small amount of memory. Over time, such a memory leak may lead to memory exhaustion and potentially degraded service.
Although this is an issue with TCP, it is not required to complete the TCP 3-way handshake in order for the memory leak to be triggered. Therefore, TCP packets with a spoofed source address may trigger the leak.
The following document contains additional information on how to identify if your router is suffering from a memory leak in Processor memory:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_tech_note09186a00800a6f3a.shtml#tshoot2
Vulnerability Scoring Details
Cisco is providing scores for the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). Cisco will provide a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks.
Cisco PSIRT will set the bias in all cases to normal. Customers are encouraged to apply the bias parameter when determining the environmental impact of a particular vulnerability.
CVSS is a standards based scoring method that conveys vulnerability severity and helps determine urgency and priority of response.
Cisco has provided an FAQ to answer additional questions regarding CVSS at:
http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html
Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks: http://intellishield.cisco.com/security/alertmanager/cvss
CSCek37177 - malformed tcp packets deplete processor memory ( registered customers only)
Calculate the environmental score of CSCek37177
CVSS Base Score - 3.3
Access Vector
Access Complexity
Authentication
Confidentiality Impact
Integrity Impact
Availability Impact
Impact Bias
Remote
Low
Not Required
None
None
Complete
Normal
CVSS Temporal Score - 2.7
Exploitability
Remediation Level
Report Confidence
Functional
Official Fix
Confirmed
Impact
Successful exploitation of the vulnerability may result in a small amount of processor memory to leak, which may lead to degraded service. This issue will not resolve over time, and will require a device reset to recover the leaked memory.
This vulnerability only applies to traffic destined to the Cisco IOS device. Traffic transiting the device will not trigger this issue.
Software Version and Fixes
When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution.
In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center ("TAC") or your contracted maintenance provider for assistance.
Each row of the Cisco IOS software table (below) describes a release train and the platforms or products for which it is intended. If a given release train is vulnerable, then the earliest possible releases that contain the fix (the "First Fixed Release") and the anticipated date of availability for each are listed in the "Rebuild" and "Maintenance" columns. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. The release should be upgraded at least to the indicated release or a later version (greater than or equal to the First Fixed Release label).
For more information on the terms "Rebuild" and "Maintenance," consult the following URL:
http://www.cisco.com/warp/public/620/1.html.
Note: There are three IOS security advisories and one field notice being published on January 24, 2007. Each advisory lists only the releases which fix the issue described in the advisory. A combined software table is available at http://www.cisco.com/warp/public/707/cisco-sa-20070124-bundle.shtml and can be used to choose a software release which fixes all security vulnerabilities published as of January 24, 2007. Links for the advisories and field notice are listed here.
http://www.cisco.com/warp/public/707/cisco-sa-20070124-IOS-IPv6.shtml
http://www.cisco.com/warp/public/707/cisco-sa-20070124-crafted-tcp.shtml
http://www.cisco.com/warp/public/707/cisco-sa-20070124-crafted-ip-option.shtml
http://www.cisco.com/warp/public/770/fn62613.shtml
Requests for software rebuilds to include the change for Daylight Savings Time (DST) that will be implemented in March 2007 should be directed through the Technical Assistance Center (TAC), and this advisory should be used as reference.
Major Release
Availability of Repaired Releases
Affected 12.0-Based Release
Rebuild
Maintenance
12.0
Vulnerable; migrate to 12.2(37) or later
12.0DA
Vulnerable; migrate to 12.2(10)DA5 or later
12.0DB
Vulnerable; migrate to 12.3(4)T13 or later
12.0DC
Vulnerable; migrate to 12.3(4)T13 or later
12.0S
12.0(31)S6
12.0(32)S4
12.0SC
Vulnerable; migrate to 12.3(13a)BC6 or later
12.0SL
Vulnerable; migrate to 12.0(31)S6 or later
12.0SP
Vulnerable; migrate to 12.0(31)S6 or later
12.0ST
Vulnerable; migrate to 12.0(31)S6 or later
12.0SX
12.0(25)SX11
12.0SY
12.0(32)SY
12.0SZ
Vulnerable; migrate to 12.0(31)S6 or later
12.0T
Vulnerable; migrate to 12.2(37) or later
12.0W
Not vulnerable
12.0WC
12.0(5)WC15
12.0WT
Not vulnerable
12.0XA
Vulnerable; migrate to 12.2(37) or later
12.0XB
Vulnerable; migrate to 12.2(37) or later
12.0XC
Vulnerable; migrate to 12.2(37) or later
12.0XD
Vulnerable; migrate to 12.2(37) or later
12.0XE
Vulnerable; migrate to 12.1(26)E7 or later
12.0XF
Not vulnerable
12.0XG
Vulnerable; migrate to 12.2(37) or later
12.0XH
Vulnerable; migrate to 12.2(37) or later
12.0XI
Vulnerable; migrate to 12.2(37) or later
12.0XJ
Vulnerable; migrate to 12.2(37) or later
12.0XK
Vulnerable; migrate to 12.2(37) or later
12.0XL
Vulnerable; migrate to 12.2(37) or later
12.0XM
Vulnerable; migrate to 12.2(37) or later
12.0XN
Vulnerable; migrate to 12.2(37) or later
12.0XQ
Vulnerable; migrate to 12.2(37) or later
12.0XR
Vulnerable; migrate to 12.2(37) or later
12.0XS
Vulnerable; migrate to 12.1(26)E7 or later
12.0XV
Vulnerable; migrate to 12.2(37) or later
12.0XW
Not vulnerable
Affected 12.1-Based Release
Rebuild
Maintenance
12.1
Vulnerable; migrate to 12.2(37) or later
12.1 AA
Vulnerable; migrate to 12.2(37) or later
12.1 AX
Vulnerable; migrate to 12.2(25)EY4 or later
12.1 AY
Vulnerable; migrate to 12.1(22)EA8 or later
12.1 AZ
Vulnerable; migrate to 12.1(22)EA8 or later
12.1 CX
Vulnerable; migrate to 12.2(37) or later
12.1 DA
Vulnerable; migrate to 12.2(10)DA5 or later
12.1 DB
Vulnerable; migrate to 12.3(4)T13 or later
12.1 DC
Vulnerable; migrate to 12.3(4)T13 or later
12.1E
12.1(26)E7
12.1(27b)E1
12.1EA
12.1(22)EA8
12.1EB
Vulnerable; contact TAC
12.1EC
Vulnerable; migrate to 12.3(13a)BC6 or later
12.1EO
12.1(19)EO6; available on 31-Jan-07
12.1(20)EO3
12.1EU
Vulnerable; migrate to 12.2(25)EWA6 or later
12.1EV
Vulnerable; migrate to 12.2(27)SV4 or later
12.1EW
Vulnerable; migrate to 12.2(25)EWA6 or later
12.1EX
Vulnerable; migrate to 12.1(26)E7 or later
12.1EY
Vulnerable; migrate to 12.1(26)E7 or later
12.1EZ
Vulnerable; migrate to 12.1(26)E7 or later
12.1T
Vulnerable; migrate to 12.2(37) or later
12.1XA
Vulnerable; migrate to 12.2(37) or later
12.1XB
Vulnerable; migrate to 12.2(37) or later
12.1XC
Vulnerable; migrate to 12.2(37) or later
12.1XD
Vulnerable; migrate to 12.2(37) or later
12.1XE
Vulnerable; migrate to 12.1(26)E7 or later
12.1XF
Vulnerable; migrate to 12.3(19) or later
12.1XG
Vulnerable; migrate to 12.3(19) or later
12.1XH
Vulnerable; migrate to 12.2(37) or later
12.1XI
Vulnerable; migrate to 12.2(37) or later
12.1XJ
Vulnerable; migrate to 12.3(19) or later
12.1XL
Vulnerable; migrate to 12.3(19) or later
12.1XM
Vulnerable; migrate to 12.3(19) or later
12.1XP
Vulnerable; migrate to 12.3(19) or later
12.1XQ
Vulnerable; migrate to 12.3(19) or later
12.1XR
Vulnerable; migrate to 12.3(19) or later
12.1XS
Vulnerable; migrate to 12.2(37) or later
12.1XT
Vulnerable; migrate to 12.3(19) or later
12.1XU
Vulnerable; migrate to 12.3(19) or later
12.1XV
Vulnerable; migrate to 12.3(19) or later
12.1XW
Vulnerable; migrate to 12.2(37) or later
12.1XX
Vulnerable; migrate to 12.2(37) or later
12.1XY
Vulnerable; migrate to 12.2(37) or later
12.1XZ
Vulnerable; migrate to 12.2(37) or later
12.1YA
Vulnerable; migrate to 12.3(19) or later
12.1YB
Vulnerable; migrate to 12.3(19) or later
12.1YC
Vulnerable; migrate to 12.3(19) or later
12.1YD
Vulnerable; migrate to 12.3(19) or later
12.1YE
Vulnerable; migrate to 12.3(19) or later
12.1YF
Vulnerable; migrate to 12.3(19) or later
12.1YH
Vulnerable; migrate to 12.3(19) or later
12.1YI
Vulnerable; migrate to 12.3(19) or later
12.1YJ
Vulnerable; migrate to 12.1(22)EA8 or later
Affected 12.2-Based Release
Rebuild
Maintenance
12.2
12.2(37)
12.2B
Vulnerable; migrate to 12.3(4)T13 or later
12.2BC
Vulnerable; migrate to 12.3(13a)BC6 or later
12.2BW
Vulnerable; migrate to 12.3(19) or later
12.2BY
Vulnerable; migrate to 12.3(4)T13 or later
12.2BZ
Vulnerable; migrate to 12.3(7)XI8 or later
12.2CX
Vulnerable; migrate to 12.3(13a)BC6 or later
12.2CY
Vulnerable; migrate to 12.3(13a)BC6 or later
12.2CZ
Vulnerable; contact TAC
12.2DA
12.2(10)DA5
12.2(12)DA10
12.2DD
Vulnerable; migrate to 12.3(4)T13 or later
12.2DX
Vulnerable; migrate to 12.3(4)T13 or later
12.2EU
Vulnerable; migrate to 12.2(25)EWA6 or later
12.2EW
Vulnerable; migrate to 12.2(25)EWA6 or later
12.2EWA
12.2(25)EWA6
12.2EX
12.2(25)EX1
12.2EY
12.2(25)EY4
12.2EZ
Vulnerable; migrate to 12.2(25)SEE1 or later
12.2FX
Vulnerable; migrate to 12.2(25)SEE1 or later
12.2FY
Vulnerable; migrate to 12.2(25)SEE1 or later
12.2FZ
All 12.2FZ releases are fixed
12.2IXA
Vulnerable; contact TAC
12.2IXB
Vulnerable; contact TAC
12.2IXC
Vulnerable; contact TAC
12.2JA
Vulnerable; migrate to 12.3(8)JA2 or later
12.2JK
Vulnerable; migrate to 12.4(4)T4 or later
12.2MB
Vulnerable; migrate to 12.2(25)SW8 or later
12.2MC
Vulnerable; migrate to 12.3(11)T11 or later
12.2S
12.2(25)S12; Available 12-Feb-07
12.2SB
12.2(28)SB2
12.2(31)SB
12.2SBC
12.2(27)SBC5
12.2SE
12.2(35)SE
12.2SEA
Vulnerable; migrate to 12.2(25)SEE1 or later
12.2SEB
Vulnerable; migrate to 12.2(25)SEE1 or later
12.2SEC
Vulnerable; migrate to 12.2(25)SEE1 or later
12.2SED
Vulnerable; migrate to 12.2(25)SEE1 or later
12.2SEE
12.2(25)SEE1
12.2SEF
12.2(25)SEF1
12.2SEG
All 12.2SEG releases are fixed
12.2SG
12.2(37)SG; Available 25-Apr-07
12.2SGA
All 12.2SGA releases are fixed
12.2SO
12.2(18)SO7
12.2SRA
All 12.2SRA releases are fixed
12.2SRB
All 12.2SRB releases are fixed
12.2SU
Vulnerable; migrate to 12.4(8) or later
12.2SV
12.2(27)SV4
12.2(28)SV1
12.2(29)SV1
12.2SW
12.2(25)SW8
12.2SX
Vulnerable; migrate to 12.2(18)SXD7a or later
12.2SXA
Vulnerable; migrate to 12.2(18)SXD7a or later
12.2SXB
Vulnerable; migrate to 12.2(18)SXD7a or later
12.2SXD
12.2(18)SXD7a
12.2SXE
12.2(18)SXE6
12.2SXF
12.2(18)SXF5
12.2SY
Vulnerable; migrate to 12.2(18)SXD7a or later
12.2SZ
Vulnerable; migrate to 12.2(25)S12 or later; Available 12-Feb-07
12.2T
Vulnerable; migrate to 12.3(19) or later
12.2TPC
Vulnerable; contact TAC
12.2XA
Vulnerable; migrate to 12.3(19) or later
12.2XB
Vulnerable; migrate to 12.3(19) or later
12.2XC
Vulnerable; migrate to 12.3(4)T13 or later
12.2XD
Vulnerable; migrate to 12.3(19) or later
12.2XE
Vulnerable; migrate to 12.3(19) or later
12.2XF
Vulnerable; migrate to 12.3(13a)BC6 or later
12.2XG
Vulnerable; migrate to 12.3(19) or later
12.2XH
Vulnerable; migrate to 12.3(19) or later
12.2XI
Vulnerable; migrate to 12.3(19) or later
12.2XJ
Vulnerable; migrate to 12.3(19) or later
12.2XK
Vulnerable; migrate to 12.3(19) or later
12.2XL
Vulnerable; migrate to 12.3(19) or later
12.2XM
Vulnerable; migrate to 12.3(19) or later
12.2XN
Vulnerable; migrate to 12.3(19) or later
12.2XQ
Vulnerable; migrate to 12.3(19) or later
12.2XR
Vulnerable; migrate to 12.3(19) or later
12.2XS
Vulnerable; migrate to 12.3(19) or later
12.2XT
Vulnerable; migrate to 12.3(19) or later
12.2XU
Vulnerable; migrate to 12.3(19) or later
12.2XV
Vulnerable; migrate to 12.3(19) or later
12.2XW
Vulnerable; migrate to 12.3(19) or later
12.2YA
Vulnerable; migrate to 12.3(19) or later
12.2YB
Vulnerable; migrate to 12.3(19) or later
12.2YC
Vulnerable; migrate to 12.3(19) or later
12.2YD
Vulnerable; migrate to 12.3(11)T11 or later
12.2YE
Vulnerable; migrate to 12.2(25)S12 or later; Available 12-Feb-07
12.2YF
Vulnerable; migrate to 12.3(19) or later
12.2YG
Vulnerable; migrate to 12.3(19) or later
12.2YH
Vulnerable; migrate to 12.3(19) or later
12.2YJ
Vulnerable; migrate to 12.3(19) or later
12.2YK
Vulnerable; migrate to 12.3(4)T13 or later
12.2YL
Vulnerable; migrate to 12.3(4)T13 or later
12.2YM
Vulnerable; migrate to 12.3(4)T13 or later
12.2YN
Vulnerable; migrate to 12.3(4)T13 or later
12.2YO
Not vulnerable
12.2YP
Vulnerable; migrate to 12.3(19) or later
12.2YQ
Vulnerable; migrate to 12.3(4)T13 or later
12.2YR
Vulnerable; migrate to 12.3(4)T13 or later
12.2YS
Not vulnerable
12.2YT
Vulnerable; migrate to 12.3(19) or later
12.2YU
Vulnerable; migrate to 12.3(4)T13 or later
12.2YV
Vulnerable; migrate to 12.3(4)T13 or later
12.2YW
Vulnerable; migrate to 12.3(4)T13 or later
12.2YX
Vulnerable; migrate to 12.4(8) or later
12.2YY
Vulnerable; migrate to 12.3(4)T13 or later
12.2YZ
Vulnerable; migrate to 12.2(25)S12 or later; Available 12-Feb-07
12.2ZA
Vulnerable; migrate to 12.2(18)SXD7a or later
12.2ZB
Vulnerable; migrate to 12.3(4)T13 or later
12.2ZC
Vulnerable; migrate to 12.3(4)T13 or later
12.2ZD
Vulnerable; contact TAC
12.2ZE
Vulnerable; migrate to 12.3(19) or later
12.2ZF
Vulnerable; migrate to 12.3(4)T13 or later
12.2ZG
Vulnerable; contact TAC
12.2ZH
Vulnerable; contact TAC
12.2ZJ
Vulnerable; migrate to 12.3(4)T13 or later
12.2ZL
Vulnerable; contact TAC
12.2ZN
Vulnerable; migrate to 12.3(4)T13 or later
12.2ZP
Vulnerable; migrate to 12.4(8) or later
Affected 12.3-Based Release
Rebuild
Maintenance
12.3
12.3(10f)
12.3(19)
12.3B
Vulnerable; migrate to 12.3(11)T11 or later
12.3BC
12.3(13a)BC6
12.3(17a)BC2
12.3BW
Vulnerable; migrate to 13.3(11)T11 or later
12.3JA
12.3(8)JA2
12.3JEA
All 12.3JEA releases are fixed
12.3JEB
All 12.3JEB releases are fixed
12.3JK
12.3(2)JK2
12.3JX
12.3(7)JX4
12.3(11)JX
12.3T
12.3(4)T13
12.3(11)T11
12.3TPC
Vulnerable; contact TAC
12.3XA
Vulnerable; contact TAC
12.3XB
Vulnerable; migrate to 12.3(11)T11 or later
12.3XC
Vulnerable; contact TAC
12.3XD
Vulnerable; migrate to 12.3(11)T11 or later
12.3XE
Vulnerable; contact TAC
12.3XF
Vulnerable; migrate to 12.3(11)T11 or later
12.3XG
Vulnerable; contact TAC
12.3XH
Vulnerable; migrate to 12.3(11)T11 or later
12.3XI
12.3(7)XI8
12.3XJ
Vulnerable; migrate to 12.3(14)YX2 or later
12.3XK
Vulnerable; migrate to 12.4(8) or later
12.3XQ
Vulnerable; migrate to 12.4(8) or later
12.3XR
Vulnerable; contact TAC
12.3XS
Vulnerable; migrate to 12.4(8) or later
12.3XU
Vulnerable; migrate to 12.4(2)T5 or later
12.3XW
Vulnerable; migrate to 12.3(14)YX2 or later
12.3XX
Vulnerable; migrate to 12.4(8) or later
12.3XY
Vulnerable; migrate to 12.4(8) or later
12.3YA
Vulnerable; contact TAC
12.3YD
Vulnerable; migrate to 12.4(2)T5 or later
12.3YF
Vulnerable; migrate to 12.3(14)YX2 or later
12.3YG
Vulnerable; migrate to 12.4(2)T5 or later
12.3YH
Vulnerable; migrate to 12.4(2)T5 or later
12.3YI
Vulnerable; migrate to 12.4(2)T5 or later
12.3YJ
Vulnerable; migrate to 12.3(14)YQ8 or later
12.3YK
Vulnerable; migrate to 12.4(4)T4 or later
12.3YM
12.3(14)YM8
12.3YQ
12.3(14)YQ8
12.3YS
Vulnerable; migrate to 12.4(4)T4 or later
12.3YT
Vulnerable; migrate to 12.4(4)T4 or later
12.3YU
Vulnerable; contact TAC
12.3YX
12.3(14)YX2
12.3YZ
12.3(11)YZ1
Affected 12.4-Based Release
Rebuild
Maintenance
12.4
12.4(3e)
12.4(7b)
12.4(8)
12.4MR
12.4(6)MR1
12.4SW
All 12.4SW releases are fixed
12.4T
12.4(2)T5
12.4(4)T4
12.4(6)T3
12.4(9)T
12.4XA
Vulnerable; migrate to 12.4(6)T3
12.4XB
Vulnerable; contact TAC
12.4XC
12.4(4)XC3
12.4XD
12.4(4)XD4
12.4XE
All 12.4XE releases are fixed
12.4XG
All 12.4XG releases are fixed
12.4XJ
All 12.4XJ releases are fixed
12.4XP
All 12.4XP releases are fixed
12.4XT
All 12.4XT releases are fixed
Workarounds
Additional mitigations that can be deployed on Cisco devices within the network are available in the Cisco Applied Intelligence companion document for this advisory:
http://www.cisco.com/warp/public/707/cisco-air-20070124-crafted-tcp.shtml
Note: Configuring VTY access-class filters is not an effective mitigation strategy for this vulnerability.
Infrastructure ACLs (iACL)
Although it is often difficult to block traffic transiting your network, it is possible to identify traffic which should never be allowed to target your infrastructure devices and block that traffic at the border of your network. Infrastructure ACLs are considered a network security best practice and should be considered as a long-term addition to good network security as well as a workaround for this specific vulnerability. The ACL example shown below should be included as part of the deployed infrastructure access-list which will protect all devices with IP addresses in the infrastructure IP address range.
A sample access list for devices running Cisco IOS is below:
!--- Permit TCP services from trust hosts destined
!--- to infrastructure addresses.
access-list 150 permit tcp TRUSTED_HOSTS MASK INFRASTRUCTURE_ADDRESSES MASK
!--- Deny TCP packets from all other sources destined to infrastructure addresses.
access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES MASK
!--- Permit all other traffic to transit the device.
access-list 150 permit IP any any
interface serial 2/0
ip access-group 150 inThe white paper entitled "Protecting Your Core: Infrastructure Protection Access Control Lists" presents guidelines and recommended deployment techniques for infrastructure protection access lists. This white paper can be obtained here: http://www.cisco.com/warp/public/707/iacl.html
Receive ACLs (rACL)
For distributed platforms, Receive ACLs may be an option starting in Cisco IOS Software Versions 12.0(21)S2 for the 12000 (GSR), 12.0(24)S for the 7500, and 12.0(31)S for the 10720. The Receive ACL protects the device from harmful traffic before the traffic can impact the route processor. Receive ACLs are designed to only protect the device on which it is configured. On the 12000, transit traffic is never affected by a receive ACL. Because of this, the destination IP address "any" used in the example ACL entries below only refer to the router's own physical or virtual IP addresses. On the 7500 and 10720, transit traffic with IP options set will be subject to the Receive ACL and permitted or denied accordingly. Receive ACLs are considered a network security best practice, and should be considered as a long-term addition to good network security, as well as a workaround for this specific vulnerability. The white paper entitled "GSR: Receive Access Control Lists" will help you identify and allow legitimate traffic to your device and deny all unwanted packets: http://www.cisco.com/warp/public/707/racl.html
The following is the receive path ACL written to permit this type of traffic from trusted hosts:
!--- Permit tcp services from trusted hosts allowed to the RP.
access-list 151 permit tcp TRUSTED_ADDRESSES MASK any
!--- Deny tcp services from all other sources to the RP.
access-list 151 deny tcp any any
!--- Permit all other traffic to the RP.
access-list 151 permit ip any any
!--- Apply this access list to the 'receive' path.
ip receive access-list 151Control Plane Policing (CoPP)
The Control Plane Policing (CoPP) feature may be used to mitigate this vulnerability. In the following example, only TCP traffic from trusted hosts and with 'receive' destination IP addresses is permitted to reach the route processor (RP). All other 'transit' IP traffic is unaffected.
It should be noted that dropping traffic from unknown or untrusted IP addresses may affect hosts with dynamically assigned IP addresses from connecting to the Cisco IOS device.
access-list 152 deny tcp TRUSTED_ADDRESSES MASK any
access-list 152 permit tcp any any
access-list 152 deny ip any any
!
class-map match-all permit-tcp-class
match access-group 152
!
!
policy-map permit-tcp-policy
class permit-tcp-class
drop
!
control-plane
service-policy input permit-tcp-policyIn the above CoPP example, the ACL entries that match the exploit packets with the "permit" action result in these packets being discarded by the policy-map "drop" function, while packets that match the "deny" action are not affected by the policy-map drop function.
Please note that in the 12.2S and 12.0S Cisco IOS trains the policy-map syntax is different:
policy-map permit-tcp-policy
class class permit-tcp-class
police 32000 1500 1500 conform-action drop exceed-action dropCoPP is available in Cisco IOS release trains 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T.
Additional information on the configuration and use of the CoPP feature can be found at the following URL:
http://www.cisco.com/en/US/products/ps6642/products_white_paper0900aecd804fa16a.shtml
Anti-spoofing
The Unicast Reverse Path Forwarding (Unicast RPF or uRPF) feature helps to mitigate problems that are caused by spoofed IP source addresses. It is available on Cisco routers and firewalls. For further details, please refer to:
http://www.cisco.com/en/US/partner/products/ps6441/products_command_reference_chapter09186a00804ae49f.html#wp1229984
By enabling Unicast Reverse Path Forwarding (uRPF), all spoofed packets will be dropped at the first device. To enable uRPF, use the following commands.
router(config)# ip cef
router(config)# interface interface #
router(config-if)# ip verify unicast source reachable-via rx
BGP and BTSH/GTSM
Depending on your release of software, it may be possible to protect your BGP sessions from this memory leak. With the introduction of CSCee73956 ( registered customers only) , Cisco IOS has improved support for BTSH (BGP TTL Security Hack) to reduce, if not eliminate a risk of a memory leak due to this vulnerability. This functionality is also known as GTSM (Generalized TTL Security Mechanism) and documented in RFC 3682. This section refers to GTSM as applied to eBGP sessions only.
Releases of Cisco IOS that contain CSCee73956 are protected from this attack against the BGP port (TCP port 179) only. Other ports should be protected accordingly.
BTSH is not supported for iBGP sessions. BTSH was first introduced in Cisco IOS in 12.0(27)S, 12.3(7)T and 12.2(25)S. Note that the BTSH feature prior to CSCee73956 will not protect against this vulnerability.
For more information on BTSH, please see: http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123newft/123t/123t_7/gt_btsh.htm
Obtaining Fixed Software
Cisco will make free software available to address this vulnerability for affected customers. This advisory will be updated as fixed software becomes available. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment.
Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/public/sw-license-agreement.html , or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml.
Do not contact either "psirt@cisco.com" or "security-alert@cisco.com" for software upgrades.
Customers with Service Contracts
Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com.
Customers using Third Party Support Organizations
Customers whose Cisco products are provided or maintained through prior or existing agreement with third-party support organizations such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory.
The effectiveness of any workaround or fix is dependent on specific customer situations such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed.
Customers without Service Contracts
Customers who purchase direct from Cisco but who do not hold a Cisco service contract and customers who purchase through third-party vendors but are unsuccessful at obtaining fixed software through their point of sale should get their upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows.
+1 800 553 2447 (toll free from within North America)
+1 408 526 7209 (toll call from anywhere in the world)
e-mail: tac@cisco.com
Have your product serial number available and give the URL of this notice as evidence of your entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC.
Refer to http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml for additional TAC contact information, including special localized telephone numbers and instructions and e-mail addresses for use in various languages.
Exploitation and Public Announcements
The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory.
This vulnerability was discovered by Cisco during our internal testing process.
Status of this Notice:FINAL
THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME.
A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors.
Distribution
This advisory is posted on Cisco's worldwide website at: http://www.cisco.com/warp/public/707/cisco-sa-20070124-crafted-tcp.shtml
In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients.
cust-security-announce@cisco.com
first-teams@first.org
bugtraq@securityfocus.com
vulnwatch@vulnwatch.org
cisco@spot.colorado.edu
cisco-nsp@puck.nether.net
full-disclosure@lists.grok.org.uk
comp.dcom.sys.cisco@newsgate.cisco.com
Cisco IOS is Affected by Multiple Vulnerabilities
Original release date: January 24, 2007
Last revised: --
Source: US-CERT
Systems Affected
Cisco network devices running IOS in various configurations
Overview
Several vulnerabilities have been discovered in Cisco's Internet Operating System (IOS). A remote attacker may be able to execute arbitrary code on an affected device, cause an affected device to reload the operating system, or cause other types of denial of service.
I. Description
Cisco has published three advisories describing flaws in IOS with various security impacts, the most serious of which could allow a remote attacker to execute arbitrary code on an affected system. Further details are available in the following vulnerability notes:
VU#217912 - Cisco IOS fails to properly process TCP packets
The Cisco IOS Transmission Control Protocol listener in certain versions of Cisco IOS software contains a memory leak. This memory leak may allow an attacker to create a denial-of-service condition.
VU#341288 - Cisco IOS fails to properly prcoess certain packets containing a crafted IP option
A vulnerability exists in the way Cisco IOS processes a number of different types of IPv4 packets containing a specially crafted IP option. Successful exploitation of this vulnerability may allow an attacker to execute arbitrary code on an affected device or create a denial-of-service condition
VU#274760 - Cisco IOS fails to properly process specially crafted IPv6 packets
Cisco IOS fails to properly process IPv6 packets with specially crafted routing headers. Successful exploitation of this vulnerability may allow an attacker to execute arbitrary code on an affected device or create a denial-of-service condition.
II. Impact
Although the resulting impacts of these three vulnerabilities is slightly different, in the case of VU#341288 and VU#274760, a remote attacker could cause an affected device to reload the operating system. In some cases, this creates a secondary denial-of-service condition because packets are not forwarded through the affected device while it is reloading. Repeated exploitation of these vulnerabilites may result in a sustained denial-of-service condition.
Because devices running IOS may transmit traffic for a number of other networks, the secondary impacts of a denial of service may be severe.
Also in the case of VU#341288 and VU#274760, successful exploitation may allow a remote attacker to execute arbitrary code on an affected device.
III. Solution
Upgrade to a fixed version of IOS
Cisco has updated versions of its IOS software to address these vulnerabilities. Please refer to the "Software Versions and Fixes" sections of the Cisco Security Advisories listed in the References section of this document for more information on upgrading.
Workaround
Cisco has also published practical workarounds for these vulnerabilities. Please refer to the "Workarounds" section of each Cisco Security Advisory listed in the References section of this document for more information.
Sites that are unable to install an upgraded version of IOS are encouraged to implement these workarounds.
IV. References
US-CERT Vulnerability Note VU#217912 -
US-CERT Vulnerability Note VU#341288 -
US-CERT Vulnerability Note VU#274760 -
Cisco Security Advisory: Crafted TCP Packet Can Cause Denial of Service -
Cisco Security Advisory: Crafted IP Option Vulnerability -
Cisco Security Advisory: Cisco Security Advisory: IPv6 Routing Header Vulnerability -
--------------------------------------------------------------------------------
Feedback can be directed to US-CERT.
--------------------------------------------------------------------------------
Produced 2007 by US-CERT, a government organization. Terms of use
Revision History
January 24, 2007: Initial release
Bueno lo que no podia faltar un Poco de Historia
Una breve historia de Internet
Barry M. Leiner, Vinton G. Cerf, David D. Clark, Robert E. Kahn, Leonard Kleinrock,
Daniel C. Lynch, Jon Postel, Lawrence G. Roberts, Stephen Wolff
Ilustraciones de Kevin Griffin
Traducción: Alonso Alvarez, Llorenç Pagés
Internet ha supuesto una revolución sin precedentes en el mundo de la informática y de las comunicaciones. Los inventos del telégrafo, teléfono, radio y ordenador sentaron las bases para esta integración de capacidades nunca antes vivida. Internet es a la vez una oportunidad de difusión mundial, un mecanismo de propagación de la información y un medio de colaboración e interacción entre los individuos y sus ordenadores independientemente de su localización geográfica.
Internet representa uno de los ejemplos más exitosos de los beneficios de la inversión sostenida y del compromiso de investigación y desarrollo en infraestructuras informáticas. A raíz de la primitiva investigación en conmutación de paquetes, el gobierno, la industria y el mundo académico han sido copartícipes de la evolución y desarrollo de esta nueva y excitante tecnología. Hoy en día, términos como leiner@mcc.com y http: www.acm.org fluyen fácilmente en el lenguaje común de las personas (1).
Esta pretende ser una historia breve y, necesariamente, superficial e incompleta, de Internet. Existe actualmente una gran cantidad de material sobre la historia, tecnología y uso de Internet. Un paseo por casi cualquier librería nos descubrirá un montón de estanterías con material escrito sobre Internet (2).
En este artículo (3), varios de nosotros, implicados en el desarrollo y evolución de Internet, compartimos nuestros puntos de vista sobre sus orígenes e historia. Esta historia gira en torno a cuatro aspectos distintos. Existe una evolución tecnológica que comienza con la primitiva investigación en conmutación de paquetes, ARPANET y tecnologías relacionadas en virtud de la cual la investigación actual continúa tratando de expandir los horizontes de la infraestructura en dimensiones tales como escala, rendimiento y funcionalidades de alto nivel. Hay aspectos de operación y gestión de una infraestructura operacional global y compleja. Existen aspectos sociales, que tuvieron como consecuencia el nacimiento de una amplia comunidad de internautas trabajando juntos para crear y hacer evolucionar la tecnología. Y finalmente, el aspecto de comercialización que desemboca en una transición enormemente efectiva desde los resultados de la investigación hacia una infraestructura informática ampliamente desarrollada y disponible.
Internet hoy en día es una infraestructura informática ampliamente extendida. Su primer prototipo es a menudo denominado National Global or Galactic Information Infrastructure (Infraestructura de Información Nacional Global o Galáctica). Su historia es compleja y comprende muchos aspectos: tecnológico, organizacional y comunitario. Y su influencia alcanza no solamente al campo técnico de las comunicaciones computacionales sino también a toda la sociedad en la medida en que nos movemos hacia el incremento del uso de las herramientas online para llevar a cabo el comercio electrónico, la adquisición de información y la acción en comunidad.
Orígenes de Internet
La primera descripción documentada acerca de las interacciones sociales que podrían ser propiciadas a través del networking (trabajo en red) está contenida en una serie de memorándums escritos por J.C.R. Licklider, del Massachusetts Institute of Technology, en Agosto de 1962, en los cuales Licklider discute sobre su concepto de Galactic Network (Red Galáctica). El concibió una red interconectada globalmente a través de la que cada uno pudiera acceder desde cualquier lugar a datos y programas. En esencia, el concepto era muy parecido a la Internet actual. Licklider fue el principal responsable del programa de investigación en ordenadores de la DARPA (4) desde Octubre de 1962. Mientras trabajó en DARPA convenció a sus sucesores Ivan Sutherland, Bob Taylor, y el investigador del MIT Lawrence G. Roberts de la importancia del concepto de trabajo en red.
En Julio de 1961 Leonard Kleinrock publicó desde el MIT el primer documento sobre la teoría de conmutación de paquetes. Kleinrock convenció a Roberts de la factibilidad teórica de las comunicaciones vía paquetes en lugar de circuitos, lo cual resultó ser un gran avance en el camino hacia el trabajo informático en red. El otro paso fundamental fue hacer dialogar a los ordenadores entre sí. Para explorar este terreno, en 1965, Roberts conectó un ordenador TX2 en Massachusetts con un Q-32 en California a través de una línea telefónica conmutada de baja velocidad, creando así la primera (aunque reducida) red de ordenadores de área amplia jamás construida. El resultado del experimento fue la constatación de que los ordenadores de tiempo compartido podían trabajar juntos correctamente, ejecutando programas y recuperando datos a discreción en la máquina remota, pero que el sistema telefónico de conmutación de circuitos era totalmente inadecuado para esta labor. La convicción de Kleinrock acerca de la necesidad de la conmutación de paquetes quedó pues confirmada.
A finales de 1966 Roberts se trasladó a la DARPA a desarrollar el concepto de red de ordenadores y rápidamente confeccionó su plan para ARPANET, publicándolo en 1967. En la conferencia en la que presentó el documento se exponía también un trabajo sobre el concepto de red de paquetes a cargo de Donald Davies y Roger Scantlebury del NPL. Scantlebury le habló a Roberts sobre su trabajo en el NPL así como sobre el de Paul Baran y otros en RAND. El grupo RAND había escrito un documento sobre redes de conmutación de paquetes para comunicación vocal segura en el ámbito militar, en 1964. Ocurrió que los trabajos del MIT (1961-67), RAND (1962-65) y NPL (1964-67) habían discurrido en paralelo sin que los investigadores hubieran conocido el trabajo de los demás. La palabra packet (paquete) fue adoptada a partir del trabajo del NPL y la velocidad de la línea propuesta para ser usada en el diseño de ARPANET fue aumentada desde 2,4 Kbps hasta 50 Kbps (5).
En Agosto de 1968, después de que Roberts y la comunidad de la DARPA hubieran refinado la estructura global y las especificaciones de ARPANET, DARPA lanzó un RFQ para el desarrollo de uno de sus componentes clave: los conmutadores de paquetes llamados interface message processors (IMPs, procesadores de mensajes de interfaz). El RFQ fue ganado en Diciembre de 1968 por un grupo encabezado por Frank Heart, de Bolt Beranek y Newman (BBN). Así como el equipo de BBN trabajó en IMPs con Bob Kahn tomando un papel principal en el diseño de la arquitectura de la ARPANET global, la topología de red y el aspecto económico fueron diseñados y optimizados por Roberts trabajando con Howard Frank y su equipo en la Network Analysis Corporation, y el sistema de medida de la red fue preparado por el equipo de Kleinrock de la Universidad de California, en Los Angeles (6).
A causa del temprano desarrollo de la teoría de conmutación de paquetes de Kleinrock y su énfasis en el análisis, diseño y medición, su Network Measurement Center (Centro de Medidas de Red) en la UCLA fue seleccionado para ser el primer nodo de ARPANET. Todo ello ocurrió en Septiembre de 1969, cuando BBN instaló el primer IMP en la UCLA y quedó conectado el primer ordenador host. El proyecto de Doug Engelbart denominado Augmentation of Human Intelect (Aumento del Intelecto Humano) que incluía NLS, un primitivo sistema hipertexto en el Instituto de Investigación de Standford (SRI) proporcionó un segundo nodo. El SRI patrocinó el Network Information Center, liderado por Elizabeth (Jake) Feinler, que desarrolló funciones tales como mantener tablas de nombres de host para la traducción de direcciones así como un directorio de RFCs (Request For Comments). Un mes más tarde, cuando el SRI fue conectado a ARPANET, el primer mensaje de host a host fue enviado desde el laboratorio de Leinrock al SRI. Se añadieron dos nodos en la Universidad de California, Santa Bárbara, y en la Universidad de Utah. Estos dos últimos nodos incorporaron proyectos de visualización de aplicaciones, con Glen Culler y Burton Fried en la UCSB investigando métodos para mostrar funciones matemáticas mediante el uso de "storage displays" (N. del T.: mecanismos que incorporan buffers de monitorización distribuidos en red para facilitar el refresco de la visualización) para tratar con el problema de refrescar sobre la red, y Robert Taylor y Ivan Sutherland en Utah investigando métodos de representación en 3-D a través de la red. Así, a finales de 1969, cuatro ordenadores host fueron conectados cojuntamente a la ARPANET inicial y se hizo realidad una embrionaria Internet. Incluso en esta primitiva etapa, hay que reseñar que la investigación incorporó tanto el trabajo mediante la red ya existente como la mejora de la utilización de dicha red. Esta tradición continúa hasta el día de hoy.
Se siguieron conectando ordenadores rápidamente a la ARPANET durante los años siguientes y el trabajo continuó para completar un protocolo host a host funcionalmente completo, así como software adicional de red. En Diciembre de 1970, el Network Working Group (NWG) liderado por S.Crocker acabó el protocolo host a host inicial para ARPANET, llamado Network Control Protocol (NCP, protocolo de control de red). Cuando en los nodos de ARPANET se completó la implementación del NCP durante el periodo 1971-72, los usuarios de la red pudieron finalmente comenzar a desarrollar aplicaciones.
En Octubre de 1972, Kahn organizó una gran y muy exitosa demostración de ARPANET en la International Computer Communication Conference. Esta fue la primera demostración pública de la nueva tecnología de red. Fue también en 1972 cuando se introdujo la primera aplicación "estrella": el correo electrónico.
En Marzo, Ray Tomlinson, de BBN, escribió el software básico de envío-recepción de mensajes de correo electrónico, impulsado por la necesidad que tenían los desarrolladores de ARPANET de un mecanismo sencillo de coordinación. En Julio, Roberts expandió su valor añadido escribiendo el primer programa de utilidad de correo electrónico para relacionar, leer selectivamente, almacenar, reenviar y responder a mensajes. Desde entonces, la aplicación de correo electrónico se convirtió en la mayor de la red durante más de una década. Fue precursora del tipo de actividad que observamos hoy día en la World Wide Web, es decir, del enorme crecimiento de todas las formas de tráfico persona a persona.
Conceptos iniciales sobre Internetting
La ARPANET original evolucionó hacia Internet. Internet se basó en la idea de que habría múltiples redes independientes, de diseño casi arbitrario, empezando por ARPANET como la red pionera de conmutación de paquetes, pero que pronto incluiría redes de paquetes por satélite, redes de paquetes por radio y otros tipos de red. Internet como ahora la conocemos encierra una idea técnica clave, la de arquitectura abierta de trabajo en red. Bajo este enfoque, la elección de cualquier tecnología de red individual no respondería a una arquitectura específica de red sino que podría ser seleccionada libremente por un proveedor e interactuar con las otras redes a través del metanivel de la arquitectura de Internetworking (trabajo entre redes). Hasta ese momento, había un sólo método para "federar" redes. Era el tradicional método de conmutación de circuitos, por el cual las redes se interconectaban a nivel de circuito pasándose bits individuales síncronamente a lo largo de una porción de circuito que unía un par de sedes finales. Cabe recordar que Kleinrock había mostrado en 1961 que la conmutación de paquetes era el método de conmutación más eficiente. Juntamente con la conmutación de paquetes, las interconexiones de propósito especial entre redes constituían otra posibilidad. Y aunque había otros métodos limitados de interconexión de redes distintas, éstos requerían que una de ellas fuera usada como componente de la otra en lugar de actuar simplemente como un extremo de la comunicación para ofrecer servicio end-to-end (extremo a extremo).
En una red de arquitectura abierta, las redes individuales pueden ser diseñadas y desarrolladas separadamente y cada una puede tener su propia y única interfaz, que puede ofrecer a los usuarios y/u otros proveedores, incluyendo otros proveedores de Internet. Cada red puede ser diseñada de acuerdo con su entorno específico y los requerimientos de los usuarios de aquella red. No existen generalmente restricciones en los tipos de red que pueden ser incorporadas ni tampoco en su ámbito geográfico, aunque ciertas consideraciones pragmáticas determinan qué posibilidades tienen sentido. La idea de arquitectura de red abierta fue introducida primeramente por Kahn un poco antes de su llegada a la DARPA en 1972. Este trabajo fue originalmente parte de su programa de paquetería por radio, pero más tarde se convirtió por derecho propio en un programa separado. Entonces, el programa fue llamado Internetting. La clave para realizar el trabajo del sistema de paquetería por radio fue un protocolo extremo a extremo seguro que pudiera mantener la comunicación efectiva frente a los cortes e interferencias de radio y que pudiera manejar las pérdidas intermitentes como las causadas por el paso a través de un túnel o el bloqueo a nivel local. Kahn pensó primero en desarrollar un protocolo local sólo para la red de paquetería por radio porque ello le hubiera evitado tratar con la multitud de sistemas operativos distintos y continuar usando NCP.
Sin embargo, NCP no tenía capacidad para direccionar redes y máquinas más allá de un destino IMP en ARPANET y de esta manera se requerían ciertos cambios en el NCP. La premisa era que ARPANET no podía ser cambiado en este aspecto. El NCP se basaba en ARPANET para proporcionar seguridad extremo a extremo. Si alguno de los paquetes se perdía, el protocolo y presumiblemente cualquier aplicación soportada sufriría una grave interrupción. En este modelo, el NCP no tenía control de errores en el host porque ARPANET había de ser la única red existente y era tan fiable que no requería ningún control de errores en la parte de los hosts.
Así, Kahn decidió desarrollar una nueva versión del protocolo que pudiera satisfacer las necesidades de un entorno de red de arquitectura abierta. El protocolo podría eventualmente ser denominado "Transmisson-Control Protocol/Internet Protocol" (TCP/IP, protocolo de control de transmisión /protocolo de Internet). Así como el NCP tendía a actuar como un driver (manejador) de dispositivo, el nuevo protocolo sería más bien un protocolo de comunicaciones.
Reglas clave
Cuatro fueron las reglas fundamentales en las primeras ideas de Kahn:
Cada red distinta debería mantenerse por sí misma y no deberían requerirse cambios internos a ninguna de ellas para conectarse a Internet.
Las comunicaciones deberían ser establecidas en base a la filosofía del "best-effort" (lo mejor posible). Si un paquete no llegara a su destino debería ser en breve retransmitido desde el emisor.
Para interconectar redes se usarían cajas negras, las cuales más tarde serían denominadas gateways (pasarelas) y routers (enrutadores). Los gateways no deberían almacenar información alguna sobre los flujos individuales de paquetes que circulasen a través de ellos, manteniendo de esta manera su simplicidad y evitando la complicada adaptación y recuperación a partir de las diversas modalidades de fallo.
No habría ningún control global a nivel de operaciones.
Otras cuestiones clave que debían ser resueltas eran:
Algoritmos para evitar la pérdida de paquetes en base a la invalidación de las comunicaciones y la reiniciación de las mismas para la retransmisión exitosa desde el emisor.
Provisión de pipelining ("tuberías") host a host de tal forma que se pudieran enrutar múltiples paquetes desde el origen al destino a discreción de los hosts participantes, siempre que las redes intermedias lo permitieran.
Funciones de pasarela para permitir redirigir los paquetes adecuadamente. Esto incluía la interpretación de las cabeceras IP para enrutado, manejo de interfaces y división de paquetes en trozos más pequeños si fuera necesario.
La necesidad de controles (checksums) extremo a extremo, reensamblaje de paquetes a partir de fragmentos, y detección de duplicados si los hubiere.
Necesidad de direccionamiento global.
Técnicas para el control del flujo host a host.
Interacción con varios sistemas operativos.
Implementación eficiente y rendimiento de la red, aunque en principio éstas eran consideraciones secundarias.
Kahn empezó a trabajar en un conjunto de principios para sistemas operativos orientados a comunicaciones mientras se encontraba en BBN y escribió algunas de sus primeras ideas en un memorándum interno de BBN titulado "Communications Principles for Operating Systems". En ese momento, se dió cuenta de que le sería necesario aprender los detalles de implementación de cada sistema operativo para tener la posibilidad de incluir nuevos protocolos de manera eficiente. Así, en la primavera de 1973, después de haber empezado el trabajo de "Internetting", le pidió a Vinton Cerf (entonces en la Universidad de Stanford) que trabajara con él en el diseño detallado del protocolo. Cerf había estado íntimamente implicado en el diseño y desarrollo original del NCP y ya tenía conocimientos sobre la construcción de interfaces con los sistemas operativos existentes. De esta forma, valiéndose del enfoque arquitectural de Kahn en cuanto a comunicaciones y de la experiencia en NCP de Cerf, se asociaron para abordar los detalles de lo que acabaría siendo TCP/IP.
El trabajo en común fue altamente productivo y la primera versión escrita (7) bajo este enfoque fue distribuida en una sesión especial del INWG (International Network Working Group, Grupo de trabajo sobre redes internacionales) que había sido convocada con motivo de una conferencia de la Universidad de Sussex en Septiembre de 1973. Cerf había sido invitado a presidir el grupo y aprovechó la ocasión para celebrar una reunión de los miembros del INWG, ampliamente representados en esta conferencia de Sussex.
Estas son las directrices básicas que surgieron de la colaboración entre Kahn y Cerf:
Las comunicaciones entre dos procesos consistirían lógicamente en un larga corriente de bytes; ellos los llamaban "octetos". La posición de un octeto dentro de esta corriente de datos sería usada para identificarlo.
El control del flujo se realizaría usando ventanas deslizantes y acks (N. del T.: abreviatura de acknowledgement, acuse de recibo). El destinatario podría decidir cuando enviar acuse de recibo y cada ack devuelto correspondería a todos los paquetes recibidos hasta el momento.
Se dejó abierto el modo exacto en que emisor y destinatario acordarían los parámetros sobre los tamaños de las ventanas a usar. Se usaron inicialmente valores por defecto.
Aunque en aquellos momentos Ethernet estaba en desarrollo en el PARC de Xerox, la proliferación de LANs no había sido prevista entonces y mucho menos la de PCs y estaciones de trabajo. El modelo original fue concebido como un conjunto, que se esperaba reducido, de redes de ámbito nacional tipo ARPANET. De este modo, se usó una dirección IP de 32 bits, de la cual los primeros 8 identificaban la red y los restantes 24 designaban el host dentro de dicha red. La decisión de que 256 redes sería suficiente para el futuro previsible debió empezar a reconsiderarse en cuanto las LANs empezaron a aparecer a finales de los setenta.
El documento original de Cerf y Kahn sobre Internet describía un protocolo, llamado TCP, que se encargaba de proveer todos los servicios de transporte y reenvío en Internet. Kahn pretendía que TCP diera soporte a un amplio rango de servicios de transporte, desde el envío secuencial de datos, totalmente fiable (modelo de circuito virtual) hasta un servicio de datagramas en el que la aplicación hiciera un uso directo del servicio de red subyacente, lo que podría implicar pérdida ocasional, corrupción o reordenación de paquetes.
Sin embargo, el esfuerzo inicial de implementación de TCP dio lugar a una versión que sólo permitía circuitos virtuales. Este modelo funcionaba perfectamente en la transferencia de ficheros y en las aplicaciones de login remoto, pero algunos de los primeros trabajos sobre aplicaciones avanzadas de redes (en particular el empaquetamiento de voz en los años 70) dejó bien claro que, en ciertos casos, el TCP no debía encargarse de corregir las pérdidas de paquetes y que había que dejar a la aplicación que se ocupara de ello. Esto llevó a la reorganización del TCP original en dos protocolos: uno sencillo, IP, que se encargara tan sólo de dar una dirección a los paquetes y de reenviarlos; y un TCP que se dedicara a una serie de funcionalidades como el control del flujo y la recuperación de los paquetes perdidos. Para aquellas aplicaciones que no precisan los servicios de TCP, se añadió un protocolo alternativo llamado UDP (User Datagram Protocol, protocolo de datagramas de usuario) dedicado a dar un acceso directo a los servicios básicos del IP.
Una de las motivaciones iniciales de ARPANET e Internet fue compartir recursos, por ejemplo, permitiendo que usuarios de redes de paquetes sobre radio pudieran acceder a sistemas de tiempo compartido conectados a ARPANET. Conectar las dos redes era mucho más económico que duplicar estos carísimos ordenadores. Sin embargo, mientras la transferencia de ficheros y el login remoto (Telnet) eran aplicaciones muy importantes, de todas las de esta época probablemente sea el correo electrónico la que haya tenido un impacto más significativo. El correo electrónicodio lugar a un nuevo modelo de comunicación entre las personas y cambió la naturaleza de la colaboración. Su influencia se manifestó en primer lugar en la construcción de la propia Internet (como veremos más adelante), y posteriormente, en buena parte de la sociedad.
Se propusieron otras aplicaciones en los primeros tiempos de Internet, desde la comunicación vocal basada en paquetes (precursora de la telefonía sobre Internet) o varios modelos para compartir ficheros y discos, hasta los primeros "programas-gusano" que mostraban el concepto de agente (y, por supuesto, de virus). Un concepto clave en Internet es que no fue diseñada para una única aplicación sino como una infraestructura general dentro de la que podrían concebirse nuevos servicios, como con posterioridad demostró la aparición de la World Wide Web. Este fue posible solamente debido a la orientación de propósito general que tenía el servicio implementado mediante TCP e IP.
Ideas a prueba
DARPA formalizó tres contratos con Stanford (Cerf), BBN (Ray Tomlinson) y UCLA (Peter Kirstein) para implementar TCP/IP (en el documento original de Cerf y Kahn se llamaba simplemente TCP pero contenía ambos componentes). El equipo de Stanford, dirigido por Cerf, produjo las especificaciones detalladas y al cabo de un año hubo tres implementaciones independientes de TCP que podían interoperar.
Este fue el principio de un largo periodo de experimentación y desarrollo para evolucionar y madurar el concepto y tecnología de Internet. Partiendo de las tres primeras redes ARPANET, radio y satélite y de sus comunidades de investigación iniciales, el entorno experimental creció hasta incorporar esencialmente cualquier forma de red y una amplia comunidad de investigación y desarrollo [REK78]. Cada expansión afrontó nuevos desafíos.
Las primeras implementaciones de TCP se hicieron para grandes sistemas en tiempo compartido como Tenex y TOPS 20. Cuando aparecieron los ordenadores de sobremesa (desktop), TCP era demasiado grande y complejo como para funcionar en ordenadores personales. David Clark y su equipo de investigación del MIT empezaron a buscar la implementación de TCP más sencilla y compacta posible. La desarrollaron, primero para el Alto de Xerox (la primera estación de trabajo personal desarrollada en el PARC de Xerox), y luego para el PC de IBM. Esta implementación operaba con otras de TCP, pero estaba adaptada al conjunto de aplicaciones y a las prestaciones de un ordenador personal, y demostraba que las estaciones de trabajo, al igual que los grandes sistemas, podían ser parte de Internet.
En los años 80, el desarrollo de LAN, PC y estaciones de trabajo permitió que la naciente Internet floreciera. La tecnología Ethernet, desarrollada por Bob Metcalfe en el PARC de Xerox en 1973, es la dominante en Internet, y los PCs y las estaciones de trabajo los modelos de ordenador dominantes. El cambio que supone pasar de una pocas redes con un modesto número de hosts (el modelo original de ARPANET) a tener muchas redes dio lugar a nuevos conceptos y a cambios en la tecnología. En primer lugar, hubo que definir tres clases de redes (A, B y C) para acomodar todas las existentes. La clase A representa a las redes grandes, a escala nacional (pocas redes con muchos ordenadores); la clase B representa redes regionales; por último, la clase C representa redes de área local (muchas redes con relativamente pocos ordenadores).
Como resultado del crecimiento de Internet, se produjo un cambio de gran importancia para la red y su gestión. Para facilitar el uso de Internet por sus usuarios se asignaron nombres a los hosts de forma que resultara innecesario recordar sus direcciones numéricas. Originalmente había un número muy limitado de máquinas, por lo que bastaba con una simple tabla con todos los ordenadores y sus direcciones asociadas.
El cambio hacia un gran número de redes gestionadas independientemente (por ejemplo, las LAN) significó que no resultara ya fiable tener una pequeña tabla con todos los hosts. Esto llevó a la invención del DNS (Domain Name System, sistema de nombres de dominio) por Paul Mockapetris de USC/ISI. El DNS permitía un mecanismo escalable y distribuido para resolver jerárquicamente los nombres de los hosts (por ejemplo, www.acm.org o www.ati.es) en direcciones de Internet.
El incremento del tamaño de Internet resultó también un desafío para los routers. Originalmente había un sencillo algoritmo de enrutamiento que estaba implementado uniformemente en todos los routers de Internet. A medida que el número de redes en Internet se multiplicaba, el diseño inicial no era ya capaz de expandirse, por lo que fue sustituido por un modelo jerárquico de enrutamiento con un protocolo IGP (Interior Gateway Protocol, protocolo interno de pasarela) usado dentro de cada región de Internet y un protocolo EGP (Exterior Gateway Protocol, protocolo externo de pasarela) usado para mantener unidas las regiones. El diseño permitía que distintas regiones utilizaran IGP distintos, por lo que los requisitos de coste, velocidad de configuración, robustez y escalabilidad, podían ajustarse a cada situación. Los algoritmos de enrutamiento no eran los únicos en poner en dificultades la capacidad de los routers, también lo hacía el tamaño de la tablas de direccionamiento. Se presentaron nuevas aproximaciones a la agregación de direcciones (en particular CIDR, Classless Interdomain Routing, enrutamiento entre dominios sin clase) para controlar el tamaño de las tablas de enrutamiento.
A medida que evolucionaba Internet, la propagación de los cambios en el software, especialmente el de los hosts, se fue convirtiendo en uno de sus mayores desafíos. DARPA financió a la Universidad de California en Berkeley en una investigación sobre modificaciones en el sistema operativo Unix, incorporando el TCP/IP desarrollado en BBN. Aunque posteriormente Berkeley modificó esta implementación del BBN para que operara de forma más eficiente con el sistema y el kernel de Unix, la incorporación de TCP/IP en el sistema Unix BSD demostró ser un elemento crítico en la difusión de los protocolos entre la comunidad investigadora. BSD empezó a ser utilizado en sus operaciones diarias por buena parte de la comunidad investigadora en temas relacionados con informática. Visto en perspectiva, la estrategia de incorporar los protocolos de Internet en un sistema operativo utilizado por la comunidad investigadora fue uno de los elementos clave en la exitosa y amplia aceptación de Internet.
Uno de los desafíos más interesantes fue la transición del protocolo para hosts de ARPANET desde NCP a TCP/IP el 1 de enero de 1983. Se trataba de una ocasión muy importante que exigía que todos los hosts se convirtieran simultáneamente o que permanecieran comunicados mediante mecanismos desarrollados para la ocasión. La transición fue cuidadosamente planificada dentro de la comunidad con varios años de antelación a la fecha, pero fue sorprendentemente sobre ruedas (a pesar de dar la lugar a la distribución de insignias con la inscripción "Yo sobreviví a la transición a TCP/IP").
TCP/IP había sido adoptado como un estándar por el ejército norteamericano tres años antes, en 1980. Esto permitió al ejército empezar a compartir la tecnología DARPA basada en Internet y llevó a la separación final entre las comunidades militares y no militares. En 1983 ARPANET estaba siendo usada por un número significativo de organizaciones operativas y de investigación y desarrollo en el área de la defensa. La transición desde NCP a TCP/IP en ARPANET permitió la división en una MILNET para dar soporte a requisitos operativos y una ARPANET para las necesidades de investigación.
Así, en 1985, Internet estaba firmemente establecida como una tecnología que ayudaba a una amplia comunidad de investigadores y desarrolladores, y empezaba a ser empleada por otros grupos en sus comunicaciones diarias entre ordenadores. El correo electrónico se empleaba ampliamente entre varias comunidades, a menudo entre distintos sistemas. La interconexión entre los diversos sistemas de correo demostraba la utilidad de las comunicaciones electrónicas entre personas.
La transición hacia una infraestructura global
Al mismo tiempo que la tecnología Internet estaba siendo validada experimentalmente y usada ampliamente entre un grupo de investigadores de informática se estaban desarrollando otras redes y tecnologías. La utilidad de las redes de ordenadores (especialmente el correo electrónico utilizado por los contratistas de DARPA y el Departamento de Defensa en ARPANET) siguió siendo evidente para otras comunidades y disciplinas de forma que a mediados de los años 70 las redes de ordenadores comenzaron a difundirse allá donde se podía encontrar financiación para las mismas. El Departamento norteamericano de Energía (DoE, Deparment of Energy) estableció MFENet para sus investigadores que trabajaban sobre energía de fusión, mientras que los físicos de altas energías fueron los encargados de construir HEPNet. Los físicos de la NASA continuaron con SPAN y Rick Adrion, David Farber y Larry Landweber fundaron CSNET para la comunidad informática académica y de la industria con la financiación inicial de la NFS (National Science Foundation, Fundación Nacional de la Ciencia) de Estados Unidos. La libre diseminación del sistema operativo Unix de ATT dio lugar a USENET, basada en los protocolos de comunicación UUCP de Unix, y en 1981 Greydon Freeman e Ira Fuchs diseñaron BITNET, que unía los ordenadores centrales del mundo académico siguiendo el paradigma de correo electrónico como "postales". Con la excepción de BITNET y USENET, todas las primeras redes (como ARPANET) se construyeron para un propósito determinado. Es decir, estaban dedicadas (y restringidas) a comunidades cerradas de estudiosos; de ahí las escasas presiones por hacer estas redes compatibles y, en consecuencia, el hecho de que durante mucho tiempo no lo fueran. Además, estaban empezando a proponerse tecnologías alternativas en el sector comercial, como XNS de Xerox, DECNet, y la SNA de IBM (8). Sólo restaba que los programas ingleses JANET (1984) y norteamericano NSFNET (1985) anunciaran explícitamente que su propósito era servir a toda la comunidad de la enseñanza superior sin importar su disciplina. De hecho, una de las condiciones para que una universidad norteamericana recibiera financiación de la NSF para conectarse a Internet era que "la conexión estuviera disponible para todos los usuarios cualificados del campus".
En 1985 Dennins Jenning acudió desde Irlanda para pasar un año en NFS dirigiendo el programa NSFNET. Trabajó con el resto de la comunidad para ayudar a la NSF a tomar una decisión crítica: si TCP/IP debería ser obligatorio en el programa NSFNET. Cuando Steve Wolff llegó al programa NFSNET en 1986 reconoció la necesidad de una infraestructura de red amplia que pudiera ser de ayuda a la comunidad investigadora y a la académica en general, junto a la necesidad de desarrollar una estrategia para establecer esta infraestructura sobre bases independientes de la financiación pública directa. Se adoptaron varias políticas y estrategias para alcanzar estos fines.
La NSF optó también por mantener la infraestructura organizativa de Internet existente (DARPA) dispuesta jerárquicamente bajo el IAB (Internet Activities Board, Comité de Actividades de Internet). La declaración pública de esta decisión firmada por todos sus autores (por los grupos de Arquitectura e Ingeniería de la IAB, y por el NTAG de la NSF) apareció como la RFC 985 ("Requisitos para pasarelas de Internet") que formalmente aseguraba la interoperatividad entre las partes de Internet dependientes de DARPA y de NSF.
Junto a la selección de TCP/IP para el programa NSFNET, las agencias federales norteamericanas idearon y pusieron en práctica otras decisiones que llevaron a la Internet de hoy:
Las agencias federales compartían el coste de la infraestructura común, como los circuitos transoceánicos. También mantenían la gestión de puntos de interconexión para el tráfico entre agencias: los "Federal Internet Exchanges" (FIX-E y FIX-W) que se desarrollaron con este propósito sirvieron de modelo para los puntos de acceso a red y los sistemas *IX que son unas de las funcionalidades más destacadas de la arquitectura de la Internet actual.
Para coordinar estas actividades se formó el FNC (Federal Networking Council, Consejo Federal de Redes) (9). El FNC cooperaba también con otras organizaciones internacionales, como RARE en Europa, a través del CCIRN (Coordinating Committee on Intercontinental Research Networking, Comité de Coordinación Intercontinental de Investigación sobre Redes) para coordinar el apoyo a Internet de la comunidad investigadora mundial.
Esta cooperación entre agencias en temas relacionados con Internet tiene una larga historia. En 1981, un acuerdo sin precedentes entre Farber, actuando en nombre de CSNET y NSF, y Kahn por DARPA, permitió que el tráfico de CSNET compartiera la infraestructura de ARPANET de acuerdo según parámetros estadísticos.
En consecuencia, y de forma similar, la NFS promocionó sus redes regionales de NSFNET, inicialmente académicas, para buscar clientes comerciales, expandiendo sus servicios y explotando las economías de escala resultantes para reducir los costes de suscripción para todos.
En el backbone NFSNET (el segmento que cruza los EE.UU.) NSF estableció una política aceptable de uso (AUP, Acceptable Use Policy) que prohibía el uso del backbone para fines "que no fueran de apoyo a la Investigación y la Educación". El predecible e intencionado resultado de promocionar el tráfico comercial en la red a niveles locales y regionales era estimular la aparición y/o crecimiento de grandes redes privadas y competitivas como PSI, UUNET, ANS CO+RE, y, posteriormente, otras. Este proceso de aumento de la financiación privada para el uso comercial se resolvió tras largas discusiones que empezaron en 1988 con una serie de conferencias patrocinadas por NSF en la Kennedy School of Government de la Universidad de Harvard, bajo el lema "La comercialización y privatización de Internet", complementadas por la lista "com-priv" de la propia red.
En 1988 un comité del National Research Council (Consejo Nacional de Investigación), presidido por Kleinrock y entre cuyos miembros estaban Clark y Kahn, elaboró un informe dirigido a la NSF y titulado "Towards a National Research Network". El informe llamó la atención del entonces senador Al Gore (N. del T.: Vicepresidente de los EE.UU. desde 1992) le introdujo en las redes de alta velocidad que pusieron los cimientos de la futura «Autopista de la Información».
La política de privatización de la NSF culminó en Abril de 1995 con la eliminación de la financiación del backbone NSFNET. Los fondos así recuperados fueron redistribuidos competitivamente entre redes regionales para comprar conectividad de ámbito nacional a Internet a las ahora numerosas redes privadas de larga distancia.
El backbone había hecho la transición desde una red construida con routers de la comunidad investigadora (los routers Fuzzball de David Mills) a equipos comerciales. En su vida de ocho años y medio, el backbone había crecido desde seis nodos con enlaces de 56Kb a 21 nodos con enlaces múltiples de 45Mb.Había visto crecer Internet hasta alcanzar más de 50.000 redes en los cinco continentes y en el espacio exterior, con aproximadamente 29.000 redes en los Estados Unidos.
El efecto del ecumenismo del programa NSFNET y su financiación (200 millones de dólares entre 1986 y 1995) y de la calidad de los protocolos fue tal que en 1990, cuando la propia ARPANET se disolvió, TCP/IP había sustituido o marginado a la mayor parte de los restantes protocolos de grandes redes de ordenadores e IP estaba en camino de convertirse en el servicio portador de la llamada Infraestructura Global de Información.
Notas
(1) Quizás esto constituya una exageración basada en la residencia en Silicon Valley del autor principal del artículo.
(2) En una visita reciente a una librería de Tokio, uno de los autores contó hasta 14 revistas en inglés dedicadas a Internet.
(3) Una versión abreviada de este artículo aparece en la publicación del 50 aniversario de Communications of the ACM (CACM), Febrero de 1997. Los autores quisieran expresar su agradecimiento a Andy Rosenbloom, editor senior de CACM, por inducirnos a escribir el presente artículo y por su inestimable asistencia para editar tanto éste como la citada versión abreviada.
(4) La Advanced Research Projects Agency (ARPA, Agencia de Proyectos de Investigación Avanzada) cambió su nombre a Defense Advanced Research Projects Agency (DARPA, Agencia de Proyectos de Investigación Avanzada para la Defensa) en 1971, más tarde retomó su antigua denominación ARPA en 1993, para volver a DARPA en 1996. Nosotros la llamaremos siempre con su nombre actual (DARPA).
(5) Fue a partir del estudio de RAND como se inició el rumor de que ARPANET era algo relacionado con la construcción de una red resistente a la guerra nuclear. En realidad, esto nunca fue cierto. Solamente el estudio de RAND sobre seguridad vocal tomaba en consideración la guerra nuclear. Sin embargo, el trabajo posterior en Internetting hizo énfasis en la robustez y capacidad de supervivencia, incluyendo la capacidad de resistir la pérdida de grandes porciones de las redes en uso.
(6) Incluyendo entre otros a Vinton Cerf, Steve Crocker y Jon Postel. Más tarde se unieron a ellos David Crocker que jugó un importante papel en la documentación de los protocolos de correo electrónico y Robert Braden que desarrolló el primer NCP y después TCP para grandes ordenadores IBM y también jugó un papel a largo plazo en el ICCB y el IAB.
(7) Esta fue más tarde publicada como: V.G. Cerf y R.E. Kahn, "A Protocol for Packet Network Interconnection", IEEE Trans. Comm. Tech., vol. COM-22, V5, May 1974, pp. 627-641.
(8) El deseo de intercambiar correo electrónico llevó, sin embargo, a la aparición de uno de los primeros libros sobre Internet: A Directory of Electronic Mail Addressing and Networks de Frey y Adams, sobre traducción y envío de direcciones de correo.
(9) Denominado originalmente FRICC (Federal Research Internet Coordinating Committee, Comité de Coordinación Federal de Investigación sobre Internet).
Thank por la recopilacion
Dino
:@ :@ :@ :@ :@ :@ :@ :@ :@ :@ :@ :@
