This tool shows that it is trivial to re-construct the value memcmp() compares
against by just measuring the time the non-time-constant memcmp() requires to
fail.
It also shows that even when running without any network latencies it gets
very difficult to reconstruct MAC/ICV values, as the time variances due to the
crypto routines are large enough that it gets difficult to measure the time
that memcmp() actually requires after computing the MAC.
However, the faster/time constant an algorithm is, the more likely is a
successful attack. When using AES-NI, it is possible to reconstruct (parts of)
a valid MAC with this tool, for example with AES-GCM.
While this is all theoretical, and way more difficult to exploit with network
jitter, it nonetheless shows that we should replace any use of memcmp/memeq()
with a constant-time alternative in all sensitive places.
While d0d85683 works around a crasher related to the use of libunwind, other
build hangs have been seen in the all test cases. Try to
--disable-unwind-backtraces to see if libunwind is really related to those
and if it fixes these issues.
Ubuntu 12.04 does not seem to provide a sane pkg-config for libiptc or libip4tc.
The monolithic build fails due to missing symbols, so disable it until we have
a newer Ubuntu release.
On Ubuntu 12.04, there seems to be a resource leak related to pthread keys
when initializing glib or related libraries more than once. With our repeated
initialization for libstrongswan tests, we hit the following error:
Lib (gthread-posix.c): Unexpected error from C library during
'pthread_key_create': Resource temporarily unavailable.
The problem is not reproducible on a newer Gnome stack, hence we disable the
glib based soup plugin until we have a more recent Ubuntu on Travis.
Travis still uses Ubuntu 12.04, where no systemd libraries are available. Skip
systemd support on Travis until we have a more recent Ubuntu distribution.
Handling the result for enum_from_name() is difficult, as checking for
negative return values requires a cast if the enum type is unsigned. The new
signature clearly differentiates lookup result from lookup value.
Further, this actually allows to convert real -1 enum values, which could not
be distinguished from "not-found" and the -1 return value.
This also fixes several clang warnings where enums are unsigned.
The salt, or often called implicit nonce, varies between AEAD algorithms and
their use in protocols. For IKE and ESP, GCM uses 4 bytes, while CCM uses
3 bytes. With TLS, however, AEAD mode uses 4 bytes for both GCM and CCM.
Our GCM backends currently support 4 bytes and CCM 3 bytes only. This is fine
until we go for CCM mode support in TLS, which requires 4 byte nonces.
But disable the gcrypt plugin, as it causes leaks.
Also disable the backtraces by libunwind as they seem to cause
threads to get cleaned up after the leak detective already has been
disabled, which leads to invalid free()s.
Not sure if 4 jobs is optimal, but according to the docs each build host
has 1.5 virtual cores available (although "getconf _NPROCESSORS_ONLN"
returns 32, which is probably the number of real cores underneath), so
more jobs might not actually reduce the build time much more.
INCLUDES are now deprecated and throw warnings when using automake 1.13.
We now also differentiate AM_CPPFLAGS and AM_CFLAGS, where includes and
defines are passed to AM_CPPFLAGS only.
Martin Willi