[libfko] Bug fix to not attempt SPA packet decryption with GnuPG without
an fko object with encryption_mode set to FKO_ENC_MODE_ASYMMETRIC. This
bug was caught with valgrind validation against the perl FKO extension
together with the set of SPA fuzzing packets in
test/fuzzing/fuzzing_spa_packets. Note that this bug cannot be
triggered via fwknopd because additional checks are made within fwknopd
itself to force FKO_ENC_MODE_ASYMMETRIC whenever an access.conf stanza
contains GPG key information. This fix strengthens libfko itself to
independently require that the usage of fko objects without GPG key
information does not result in attempted GPG decryption operations. Hence
this fix applies mostly to third party usage of libfko - i.e. stock
installations of fwknopd are not affected. As always, it is recommended to
use HMAC authenticated encryption whenever possible even for GPG modes since
this also provides a work around even for libfko prior to this fix.
This commit implements a single shared utility function for checking the
validaty of an IPv4 address, and both libfko and the fwknopd server use it
now. The client will be updated as well.
This commit replaces the separately implemented client/server
is_base64() check with a single libfko function, and libfko itself now
uses it as well before prepending Rijndael or GnuPG base64 encoded
prefixes.
Nikolay Kolev reported a build issue on Mac OS X 10.9 (Mavericks) where fwknop
copies of strlcpy() and strlcat() functions were conflicting with those that ship
with OS X 10.9.
The solution was to add a configure.ac check for strlcat() and strlcpy() and
wrap "#if !HAVE_..." checks around those functions.
A portion of the build errors looked like this:
/Applications/Xcode.app/Contents/Developer/usr/bin/make all-recursive
Making all in lib
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I ../common -g -O2 -Wall -Wformat -Wformat-security -fstack-protector-all -fstack-protector -fPIE -D_FORTIFY_SOURCE=2 -MT base64.lo -MD -MP -MF .deps/base64.Tpo -c -o base64.lo base64.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I ../common -g -O2 -Wall -Wformat -Wformat-security -fstack-protector-all -fstack-protector -D_FORTIFY_SOURCE=2 -MT base64.lo -MD -MP -MF .deps/base64.Tpo -c base64.c -fno-common -DPIC -o .libs/base64.o
In file included from base64.c:34:
In file included from ./fko_common.h:149:
./fko_util.h:56:9: error: expected parameter declarator
size_t strlcat(char *dst, const char *src, size_t siz);
^
/usr/include/secure/_string.h:111:44: note: expanded from macro 'strlcat'
__builtin___strlcat_chk (dest, src, len, __darwin_obsz (dest))
^
/usr/include/secure/_common.h:39:62: note: expanded from macro '__darwin_obsz'
#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)
^
This commit bumps the fwknop version to 2.5 and sets the libfko version to 2.0 to
signal incompatibility with older libfko versions. Backwards compatibility is
maintained in SPA packet construction, but function prototypes in libfko-2.0 are
no longer compatible with older versions.
This commit also returns non-zero exit status under 'fwknopd --status' if there
is no existing fwknopd process. This is better than always exiting with a zero
status regardless of whether fwknopd is already running or not, and adds a level
of scriptability to --status usage. This change was suggested by George Herlin.
Blair Zajac contributed a patch to handle endian detection on PPC systems
and issue a compile time error if it cannot be determined. This commit affects
the BYTEORDER macro.
Blair Zajac reported that strndup() is not available on some PPC systems, so
this commit switches to use the local lib/fko_util.c implementation similarly
to what is done for Windows systems.
This commit is a follow up to Ryman's report (#85) of a potential timing attack
that could be leveraged against fwknop when strncmp() is used to compare HMAC
digests. All strncmp() calls that do similar things have been replaced with a
new constant_runtime_cmp() function that mitigates this problem.
Lots of places in the code were already using {0} to initialize stack char
arrays, but memset() was being used as well. This commit removes all
unnecessary memset() calls against char arrays that are already initialized
via {0} (which sets all members to zero for such arrays).
Make sure both functions works the same way and refer to the same
encryption mode string.
Updated the fwknop usage message to display the encryption mode.
