A flaw in openswan was discovered, whereby when a remote user sends an IKE key length greater than 256 bytes, it can cause openswan to crash. This is due to a NULL pointer dereference in openswan's error handling routines. This flaw was introduced in openswan 2.6.29, due to commit 877454be8 on 2010-09-19. The code in question is: diff --git a/programs/pluto/spdb_v1_struct.c b/programs/pluto/spdb_v1_struct.c index 8b180f2..56af219 100644 --- a/programs/pluto/spdb_v1_struct.c +++ b/programs/pluto/spdb_v1_struct.c @@ -880,7 +883,7 @@ parse_isakmp_sa_body( { case OAKLEY_ENCRYPTION_ALGORITHM | ISAKMP_ATTR_AF_TV: #ifdef IKE_ALG - if (ike_alg_enc_ok(val, 0, c->alg_info_ike, &ugh)) { + if (ike_alg_enc_ok(val, 0, c->alg_info_ike, &ugh, ugh_buf, sizeof(ugh_buf))) { /* if (ike_alg_enc_present(val)) { */ ta.encrypt = val; ta.encrypter = crypto_get_encrypter(val); @@ -1139,7 +1142,7 @@ parse_isakmp_sa_body( * check if this keylen is compatible with * specified alg_info_ike */ - if (!ike_alg_enc_ok(ta.encrypt, val, c->alg_info_ike, &ugh)) { + if (!ike_alg_enc_ok(ta.encrypt, val, c->alg_info_ike, NULL, ugh_buf, sizeof(ugh_buf))) { ugh = "peer proposed key_len not valid for encrypt algo setup specified"; } ta.enckeylen=val; On the second call to the modified ike_alg_enc_ok(), NULL is passed in as fourth argument. On the first call the algo is checked, on the second call the key length is checked. When you look at the code in ike_alg_enc_ok() from ike_alg.c: bool ike_alg_enc_ok(int ealg, unsigned key_len, struct alg_info_ike *alg_info_ike __attribute__((unused)), const char **errp, char *ugh_buf, size_t ugh_buf_len) { [...] if (!ret && *errp) *errp = ugh_buf; return ret; } Which causes a null pointer dereference when ret is FALSE and errp is NULL, as it happens with a valid algo and an invalid key length. The proper code should be: if (!ret && errp) *errp = ugh_buf; return ret;
Upstream patch: diff --git a/programs/pluto/ike_alg.c b/programs/pluto/ike_alg.c index 78aea4a..08b8d82 100644 --- a/programs/pluto/ike_alg.c +++ b/programs/pluto/ike_alg.c @@ -115,7 +115,7 @@ bool ike_alg_enc_ok(int ealg, unsigned key_len, ealg, key_len); } ); - if (!ret && *errp) + if (!ret && errp) *errp = ugh_buf; return ret; } This will be fixed in upstream 2.6.36 release.
It was found that this isn't just limited to AES key lengths, but could also be impacted by 3DES. A revised upstream announcement is as follows: Subject: CVE-2011-3380 Openswan IKE invalid key length vulnerability Release date: Wed Oct 5, 2011 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2011-3380 Security Alert: This alert (and any possible updates) is available at the following URL: http://www.openswan.org/download/CVE-2011-3380/ The Openswan project has discovered a vulnerability in the key length handler in their IKE daemon implementation "pluto". Vulnerable versions: openswan 2.6.29 up to 2.6.35 Fixed version : openswan 2.6.36 Vulnerability information: When an ISAKMP message with an invalid KEY_LENGTH attribute is received, the error handling function crashes on a NULL pointer dereference. Openswan automatically restarts the pluto IKE daemon but all ISAKMP state is lost. This vulnerability does NOT allow an attacker access to the system. This can be used to launch a denial of service attack by sending repeated IKE packets with the invalid key length attribute. Openswan is only vulnerable if the attacker's IP address is allowed to connect to it by a loaded policy. For static tunnels, this is limited to the allowed remote IP address. However, in the case of supporting dynamic clients ("roadwarriors", via right=%any) any IP address can trigger the crash. The crash is independant of the authentication method used (PSK, RAW RSA or X.509), Restricted static IPs could also be spoofed to trigger the vulnerability. This vulnerability happens in the IKE layer before any authentication has taken place, meaning any attacker can crash openswan without the need to know a preshared key (PSK) and without the need for a valid X.509 certificate, as long as there is a potential match for the attacker's IP address and the loaded IKE policies. Vulnerability Details: The function parse_isakmp_sa_body() calls the function ike_alg_enc_ok() twice, once to verify the algorithm and once to verify the key length. In openswan 2.6.29, the second call was changed to pass NULL as the errp pointer. The function ike_alg_enc_ok() error handler improperly dereferences the errp pointer. Full release: The latest openswan release which fixes all known issues can be found at: http://www.openswan.org/download/openswan-2.6.36.tar.gz http://www.openswan.org/download/openswan-2.6.36.tar.gz.asc (GPG signature) Patch: For those unable to upgrade to the latest openswan 2.6.36 release, the following patch can be used to resolve this problem: diff --git a/programs/pluto/ike_alg.c b/programs/pluto/ike_alg.c index 78aea4a..08b8d82 100644 --- a/programs/pluto/ike_alg.c +++ b/programs/pluto/ike_alg.c @@ -115,7 +115,7 @@ bool ike_alg_enc_ok(int ealg, unsigned key_len, ealg, key_len); } ); - if (!ret && *errp) + if (!ret && errp) *errp = ugh_buf; return ret; }
This is now public. External References: http://www.openswan.org/download/CVE-2011-3380/CVE-2011-3380.txt
Acknowledgements: Red Hat would like to thank the Openswan project for reporting this issue. Upstream acknowledges Paul Wouters as the original reporter.
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2011:1356 https://rhn.redhat.com/errata/RHSA-2011-1356.html
Created openswan tracking bugs for this issue Affects: fedora-all [bug 743760]
should this bug be closed?
Yes it should. Thanks for noticing.