This alert (and any possible updates) is available at the following URL:
The Openswan project has discovered a vulnerability in the XAUTH
Cisco handling code that could be exploited if openswan connects to a
trusted gateway that has been compromised.
Vulnerable versions: openswan 2.6.25 up to and including openswan 2.6.28
Fixed version : openswan 2.6.29 and above
In very specific circumstances, a buffer overflow and arbitrary shell
commands could be sent to a vulnerable openswan client.
These vulnerabilities can only be triggered when openswan is configured to
connect to a malicious Cisco compatible gateway using XAUTH. It requires
openswan to be configured with *xauthclient=yes and remote_peer_type=cisco,
and requires successful phase1 IKE negotiation. This can only happen to a
vulnerable Openswan client when connecting to a trusted and authenticated
gateway using XAUTH.
An Openswan server receiving VPN connections is not affected by this flaw.
The fields cisco_dns_info and cisco_domain_info were declared as a fixed
length buffer. If enough DNS payloads are sent in one packet, the buffer
will overflow. Additionally, these fields were copied into
fmt_common_shell_out() without being sanitized to make it safe against
exploitable characters, such as single quotes('). This was introduced in
git commit id 3115ee29, on March 19, 2010 and first released in openswan
2.6.25. The vulnerability is fixed in openswan 2.6.29.
For those unable to upgrade to the latest openswan 2.6.29 release, a patch
addressing CVE-2010-3302 (and CVE-2010-3308) can be found at:
Red Hat would like to thank the Openswan project for reporting this issue. Upstream acknowledges D. Hugh Redelmeier and Paul Wouters as the original reporters.
Please use CVE-2010-3302 for these flaws.
The code in question doesn't exist in the versions of openswan shipped in RHEL5 and below.
From looking over the pluto source, this flaw happens during the processing of the R1 message from the server. This is indeed a client issue, not a server flaw.
The initial XAUTH bits are out of the way, so we're probably talking about a compromised server. An attacker trying to MITM a client would need the shared secret key for this to work, which presents various other problems in itself.
Without some other form of attack happeming first, this flaw is harmless by itself.
The first flaw appears to be a heap overflow.
The second flaw overflows the stack, but as stack variable use is quite generous in this fucntion, we should presume a clever attacker could leverage one of the other variables to accomplish the goal of arbitrary code execution.
Yes, upstream agrees this is a client side issue. Their concern is a compromised VPN server could be used to get into the client machine where passwords and confidential documents may be stored. Meaning an attack vector to get into other machines once inside the network.
I am adding an updated specifically for RHEL6. The reason is that upstream patch can not be applied directly to the rhel6 code, and needed some modifications, as the openswan code is RHEL6 is based on an older version (+ red hat patches) than the latest upstream openswan code. In addition, I have done a few corrections in the upstream patch, and informed to upstream about it. So you can notice following differences between upstream patch and rhel6 patch:
1. Cisco related variables are only needs to be put inside #ifdef XAUTH", but in kernel.c file, they have been put incorrectly under both XAUTH and MODECFG. So this is one correction.
2. Changes related to XAUTH_PAM are not needed for this CVE, that are there in the upstream patch.
3. Some changes due to the differences between the rhel6 code and upstream code.
The patch is attached, and have been tested.
Thanks and Regards
Created attachment 448065 [details]
patch for cve-2010-3302
patch for cve-2010-3302
Created attachment 448494 [details]
The final patch used for the CVE release
Oh oops. I just see Avesh attached the patch already.
Created openswan tracking bugs for this issue
Affects: fedora-all [bug 637925]
Can't this bug be closed?
We want to keep it open for now. There's one more product left to fix, that can not be addressed immediately. Thank you.
This issue has been addressed in following products:
Red Hat Enterprise Linux 6
Via RHSA-2010:0892 https://rhn.redhat.com/errata/RHSA-2010-0892.html