A

Unresolved and Upcoming

Issues

This appendix lists some of the latest developments and issues that will be relevant to users of Openswan.

Linux Kernel Developments

Both the Linux networking stack and the IPsec transformation code (XFRM) are undergoing major changes as of kernel version 2.6.12, up to and including the latest version. Some of these changes keep on breaking KLIPS on every major and minor release. The Openswan developers cannot keep up with every minor version, so we advise you to stick to full releases such as 2.6.14, and not releases such as 2.6.14.7 or 2.6.15-rc1.

For each item in the networking code that has changed, you will find a define in the file

openswan-2/linux/include/openswan/ipsec_kversion.h that switches between the old and the

new behavior.

Kernel API Changes between 2.6.12 and 2.6.14

The following table lists relevant changes to the kernel API:

Version	ipsec_kversion.h define	Description
2.6.12+	HAVE_SOCK_ZAPPED	sk->sk_zapped changed to sock_flag(sk,
		SOCK_ZAPPED)
2.6.12+	NET_26_12_SKALLOC	sk_alloc argument order change
2.6.13+	HAVE_SOCK_SECURITY	skb->security vanished
2.6.13+	HAVE_SKB_NF_DEBUG	skb->nf_debug vanished
2.6.14+	HAVE_TSTAMP	skb->stamp changed to skb->tstamp
2.6.14+	HAVE_INET_SK_SPORT	tcp_tw_bucket vanished for inet_sk()
2.6.14	HAVE_MISSING_IP_DEFAULT_TTL	sysctl_ip_default_ttl vanished (by accident?)
(only?)

kernel-devel

Unresolved and Upcoming Issues

If you send the developers patches for newer kernels, please try to use this method of creating a define in ipsec_kversion.h and using that define in the actual KLIPS code.

Normally, these defines should work fine. If you have problems with these defines, or think your problems are related to these, you can override them either in ipsec_kversion.h, or better by setting a proper define for MODULE_EXTRA_INCLUDE.

Red Hat Kernel Developments

The problem described above is the prime reason why recent Red Hat kernels have been so unstable when used with KLIPS. Red Hat kernels tend to incorporate the above kernel features one version before they appear in the Torvalds Linux kernel. For instance, sk_alloc() was already changed in one of the 2.6.11-based Fedora kernel versions, but appeared in 2.6.12 in the Torvalds Linux kernel.

The spec file, as shipped with Openswan in openswan-2/packaging/Red Hat/openswan.spec,

shows the proper use of MODULE_EXTRA_INCLUDE.

Fedora Kernel Source/Headers Packaging Change

Fedora has changed where the kernel source can be found on a few occasions. First it was in a kernel-source binary RPM, then moved to a kernel source RPM, and is now in the

binary RPM package.

To build KLIPS, some kernel header files are needed. Usually, there is a softlink in /lib/ modules/`uname -r`/build that points to the proper location. Fedora has changed this a bit, with a new scheme to save on disk space that hardlinks all the kernel source files that did not change between kernel revisions in /usr/src/kernels/. This is mostly noticeable by the extremely long time it takes to post-process the kernel-devel package installation. It will take at least several minutes. We have had mixed results when adding and removing those kernel-devel packages, ending up with no proper kernel headers in any of the kernel trees installed.

MD5 Insecurities

Every few months, a new article appears on the "holes" in the MD5 hashing algorithm. It is true that some uses for MD5 are now far less secure than originally thought. SHA-1 is affected in a similar way. However, these hashing algorithms are vulnerable for hashes stored long-term, for instance, MD5 hashes of binary files, such as those used to check file integrity by tripwire and the RPM package manager (for example when invoked with rpm -V openswan).

However, IPsec uses keyed MD5, also called HMAC. This means that an attacker would have to break an MD5 hash PER PACKET. And on top of that, all the mathematical shortcuts that these MD5 vulnerabilities are based on do not work for HMAC-MD5.

The greatest danger of MD5 and SHA-1 being broken is in their use within X.509 certificates, though even those are still considered to be safe for quite a while. The official IETF view is "walk, not run, to another secure hashing algorithm". Whether this will be SHA-256 or another algorithm is not yet known.

306

Appendix A

Discontinuation of Openswan 1 by the End of 2005

By the time this book becomes available, Openswan 1 will have been fully discontinued. That means no new versions will be released, not even for grave security vulnerabilities. Since Openswan 1 itself was the continuation of Super FreeS/WAN, neither should be deployed, and current deployments should be phased out. Items specific to Openswan 1 have been left out of this book completely.

Update on UML Testing Suite Installation

Some additional scripts have been added to the contrib/ directory to greatly simplify the building of the UML-based test harness. If you run into problems and want to assist by showing us test results or adding new tests, please see the new UML scripts in the contrib/ directory.

Openswan GIT Repositories

The developers of Openswan might be moving from CVS to GIT. Currently, repositories are kept both in CVS and GIT. If you wish to use the GIT trees instead of the CVS trees, you should install the appropriate software: git and cogito. Run the following commands to check out a copy of the latest Openswan 2 development tree:

#mkdir git

#cd git

#cg-clone http://git.openswan.org/public/scm/openswan.git/.git

To update a previously checked-out tree, run:

# cg-fetch

For more information about git, see docs/HACKING/GitSOP, docs/HACKING/HowToGit, and

docs/HACKING/PostToYourOwnGitTree. For up-to-date information on development tools used by

Openswan, see http://www.openswan.org/development/.

For general information about git, see http://git.or.cz/.

Openswan on Windows and Mac OS X Updates

The Openswan userland currently runs on both Windows (using cygwin) and on Mac OS X (using Xcode). Both can only run with the "NO_KERNEL" kernel interface at this point. We hope to continue our porting efforts by porting the appropriate kernel hooks to those platforms. On Windows, this will likely happen by using the free ipsec2k library. This library is available on SourceForge.net. For Mac OS X, the kernel_netkey interface will need to be ported to the Apple KAME interface. Since NETKEY itself is a port of KAME, this should not be an impossible task.

Both these tasks require commitments for which Xelerance currently has no resources. If you wish to sponsor these projects by submitting code or by making a financial contribution, please contact Xelerance.

307

Unresolved and Upcoming Issues

Known Outstanding Bugs

There are currently a few unresolved bugs that might affect your Openswan installation. You should make sure that the latest release of Openswan has not fixed these issues and also check any

open issues listed at http://bugs.openswan.org/.

•Some people encounter very short UDP fragments on TCP or SYN packets after updating their Openswan from 2.3.x to 2.4.x. This was due to a bug in KLIPS in versions 2.4.0 to 2.4.4. Please upgrade or specify fragicmp=no as workaround.

•It seems that SMP machines might still experience crashes when KLIPS is used. There is a fix in Openswan 2.4.4 which might have resolved this issue.

•There are still some Mac OS X interoperability problems with NAT-T because Apple did not correctly implement the NAT-T specifications. Currently, the initial connection will work fine, but at rekey time, the connection will fail.

•Multiple roadwarriors behind the same NAT router cannot establish transport mode (L2TP) connections to the same Openswan server. A patch is currently being worked on to resolve this.

•There have been reports that using an AMD64 (x86_64) kernel with a 32-bit Openswan userland fails with NETKEY errors.

•Some minor NAT-T issues were reported where Openswan would use the wrong source port or incorrectly detect double NAT.

•type=transport and rightsubnet=vhost:%priv should work together but give a bogus

error. (Workaround: remove type=transport and it will still use transport mode.)

Vulnerability Fixes in Openswan 2.4.4

(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.

308

Appendix A

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

309