The following security advisory is sent to the securiteam mailing list, and can
be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
Cisco IPSec IKE Multiple DoS Vulnerabilities
------------------------------------------------------------------------
SUMMARY
IP Security, or IPSec, is a set of protocols standardized by the IETF to
support encrypted and/or authenticated transmission of IP packets. IPSec
is a protocol commonly used in Virtual Private Networks (VPNs). The
Internet Key Exchange (IKE) protocol is used to negotiate keying material
for IPSec Security Associations (SAs) and provides authentication of
peers.
Multiple Cisco products contain vulnerabilities in the processing of IPSec
IKE (Internet Key Exchange) messages. The vulnerabilities can be exploited
to produce a denial of service.
DETAILS
Vulnerable Systems:
* Cisco IOS versions based on 12.2SXD, 12.3T, 12.4 and 12.4T
* Cisco PIX Firewall versions up to but not including 6.3(5)
* Cisco PIX Firewall/ASA versions up to but not including 7.0.1.4
* Cisco Firewall Services Module (FWSM) versions up to but not including
2.3(3)
* Cisco VPN 3000 Series Concentrators versions up to but not including
4.1(7)H and 4.7(2)B
* Cisco MDS Series SanOS versions up to but not including 2.1(2)
The first case is LAN-to-LAN VPN operation in which two devices negotiate
an IPSec connection between them for the purposes of connecting two remote
LANs via an IPSec tunnel. In this case the devices negotiating the IPSec
connection generally have static IP addresses, and the IPSec tunnel is up
as long as there is traffic that needs to traverse the tunnel.
Successful exploitation of the vulnerability on the Cisco MDS Series may
result in the restart of the IKE process. All other Cisco MDS device
operations will continue normally.
The second case is a Remote Access (RA) VPN which is typically used to
allow remote clients a connection to a secure network or service. A common
example of this is a user connecting to a corporate network while away
from the office. In this scenario, the remote user could be connecting
from anywhere, and their IP address is not static, but rather dynamically
assigned via the transport provider.
Successful exploitation of the vulnerabilities on all other Cisco devices
may result in the restart of the device. The device will return to normal
operation without any intervention required.
IKE is not a requirement for the establishment of IPSec connections.
Depending on your requirements and the devices involved, it may be
possible to statically configure the SA information and disable IKE. This
type of configuration may not be possible in the case of RA VPNs due to
the user's IP address being unknown prior to the establishment of the
IPSec connection.
Only Cisco IOS images that contain the Crypto Feature Set contain the
vulnerable IPSec code.
When receiving certain malformed packets, vulnerable Cisco devices may
reset, causing a temporary Denial of Service (DoS).
Workaround:
The effectiveness of any workaround 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 is the most appropriate for
use in the intended network before it is deployed.
For customers that use IPSec, but do not require IKE for connection
establishment, IPSec connection information may be able to be entered
manually, and IKE can be disabled, eliminating the exposure.
Note: Due to the potential complexity of configuring IPSec information,
this is likely not a viable alternative for most customers, but is
mentioned here for completeness. Please consult your product documentation
for further information on static IPSec configuration.
Restricting IKE Messages:
It is possible to mitigate the effects of this vulnerability by
restricting the devices that can send IKE traffic to your IPSec devices.
Due to the potential for IKE traffic to come from a spoofed source
address, a combination of Access Control Lists (ACLs) and anti-spoofing
mechanisms will be most effective.
ADDITIONAL INFORMATION
The information has been provided by <mailto:psirt@cisco.com> Cisco
Systems Product Security Incident Response Team.
The original article can be found at:
<http://www.cisco.com/warp/public/707/cisco-sa-20051114-ipsec.shtml>
http://www.cisco.com/warp/public/707/cisco-sa-20051114-ipsec.shtml
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to:
list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to:
list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any
kind.
In no event shall we be liable for any damages whatsoever including direct,
indirect, incidental, consequential, loss of business profits or special
damages.
