(or "A week in the life of the Openswan developers" )
When this book entered the final edit stage, we were at version 2.4.1. Two weeks later version 2.4.4 was out. With Openswan releases normally going out every few months, this is rather odd. We decided to write up our clarification in this appendix, as these events are truly the latest developments, and we could no longer update the texts in the regular chapters, as they had already gone into the final publishing stage.
On August 31 2005, Xelerance was notified by the UK's National Infrastructure Security Coordination Centre (NISCC) that a cross-vendor vulnerability had been found in various implementations of the IKE protocol. They could not tell if Openswan was vulnerable, since they did not test it. They required us to sign a "Social Contract" that included terms that the Openswan developers could not agree to.
The biggest problem was that the Openswan developers could not disclose any information about this vulnerability, until NISCC chose to go public themselves, yet no deadline was given for a publication date. This limitation meant that developers could not even fix the bug until the announcement, since Openswan is open-source software. Any change in the code is automatically published, and would disclose the vulnerability information. NISCC said they would likely publish the vulnerability on October 31 2005 but could not make any hard guarantees. No contract was signed.
October 31 came and passed. Then we were told this vulnerability would be disclosed in January, since a large vendor needed more time to repair its IPsec devices. Meanwhile, Openswan developers still did not know whether they were vulnerable or not.
On November 14, NISCC and CERT-FI, the Finnish CERT department, released the vulnerability information including a substantial test suite written by the University of Oulu, Finland. This was probably the worst timing they could have done, since the week before a lot of IPsec developers, including some of the Openswan developers, had been at the IETF meeting in Vancouver, Canada, and were still traveling back home. Even worse was that Openswan developers were not notified beforehand (nor in fact, afterwards). They were given a "0-day exploit" by a National Security organization who had been sitting on this bug for months.
The developers scrambled to run the test suite, which alone took over three hours to run, since it consisted of 5000 test cases that had to run sequentially. They then decided to release Openswan 2.4.2 late that same day, even though it only fixed one of the two bugs that had been encountered. A day later, Openswan 2.4.3 was created, but it turned out to be a dud—the second bug was not properly fixed, and this version was pulled from the web and FTP servers. On November 18, Openswan 2.4.4 was released that properly fixed the second bug.
Looking back after the events, the vulnerabilities were not as shocking as first assumed. The Openswan code actually caught the bogus packets in a controlled matter, in the 'assertion' functions, meaning no buffer overflows or other methods to inject malicious code were ever possible with these exploits. Furthermore, it turned out these two bugs were only triggered in Phase 2, meaning one had to know the shared secret (PSK) to perform an attack. Furthermore, one of the two bugs required Aggressive Mode as well. Aggressive Mode is really only used to talk to Cisco routers, and is hardly used with Openswan at all. The only attack vector for a malicious attacker could be someone from within the organization, severely limiting the impact of these bugs. None of this is discussed in the vulnerability release, nor in the updates that NISCC has since issued.
For more details, see the announcements of Openswan 2.4.3 and Openswan 2.4.4 and our public response to the NISCC vulnerability announcement. These texts can be read at:
http://www.openswan.org/niscc2/
http://lists.openswan.org/pipermail/announce/2005-November/000008.html
http://lists.openswan.org/pipermail/announce/2005-November/000009.html