A DoS vulnerability in strongSwan was discovered, which is triggered by XAuth usernames and EAP identities in versions 5.0.3 and 5.0.4.
A recent bug report on one of our mailing lists lead to the discovery of a denial-of-service vulnerability in strongSwan (CVE-2013-5018).
It can be triggered by specially crafted XAuth usernames and EAP identities. Affected are the xauth-generic and xauth-eap plugins as well as the following EAP plugins: eap-aka, eap-identity, eap-peap, eap-sim, eap-ttls. Also affected are the SASL implementation in libpttls and the tnc-pdp plugin. A crash can also be triggered locally by a crafted PEM encoded file. Injecting code is not possible by such attacks.
A segmentation fault is caused if an XAuth username or EAP identity is received that starts with either 0 or 1 (ASCII, 0x30 and 0x31 hex,
technically 0x04 also triggers it, but this is harder to craft) and whose remaining bytes can be interpreted as single- or multi-byte ASN.1
length (for instance, a single character < 0x80). An example for such a username is 15 (0x3135) as can be seen in the bug report.
The plugins listed above call identification_create_from_data() to parse the username/identity, which first calls is_asn1() to determine if the given data is ASN.1 encoded. This function in turn calls asn1_length() but handles the return value incorrectly, if the parsed ASN.1 length is invalid (e.g. if the parsed length is longer than the actual data). If the remaining data length is exactly zero, a check for terminating newlines causes an integer overflow and subsequently a segmentation fault.
strongSwan versions 5.0.3 and 5.0.4 are affected by this issue.
Because the vulnerable function (is_asn1) is also called by the pem plugin, a similar bug can be triggered locally by a specifically crafted PEM encoded file that starts with either 0x04, 0x30, or 0x31 and follows the structure described above. Since this plugin is only used to load local certificate, private key or CRL files, which can't be changed without proper privileges, the severity of this issue is minor.
All strongSwan versions since 4.1.11 are affected by this issue. In releases before 4.3.0 pluto's own ASN.1 parser is also affected.
While is_asn1() never handled the return value of asn1_length() correctly, this did not cause any problems before the additional check for newlines was added with 4.1.11. Therefore, earlier releases as well as users of the original X.509 patch for FreeS/WAN (Openswan, Libreswan) are not vulnerable.
The just released strongSwan 5.1.0 fixes this vulnerability. For older releases we provide two patches, one for versions since 4.3.0 the other for versions before that.