It was reported that StrongSwan 5.1.0 corrected a flaw present in versions 5.0.3 and 5.0.4:
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.
It was also noted that the PEM plugin can call the vulnerable is_asn1() function, and this issue can triggered locally via a specially crafted PEM encoded file. However, the PEM plugin is only used to load local certificates, private keys or CRL files, which require appropriate (root) privileges to change so no trust boundary is crossed.
Patches for StrongSwan are available here: http://download.strongswan.org/patches/12_is_asn1_patch/
In regards to the PEM issue for earlier releases as well as for Openswan and Libreswan, the advisory notes:
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.
Checking the code in Openswan and Libreswan, the additional newline check is indeed not present.
Created strongswan tracking bugs for this issue:
Affects: fedora-all [bug 991216]
Not vulnerable. This issue did not affect the versions of openswan as shipped with Red Hat Enterprise Linux 5 or 6 as they did not include the problematic newline checks when validating ASN.1 length.
Strongswan has been updated and libreswan/openswan do not appear to be affected. I am therefore closing this bug.
That's right, both EPEL6 and current Fedora have 5.1.1, which has this flaw fixed.