Bug fix to correct a memory leak in GnuPG SPA packet handling within
the gpg_decrypt() function. Here is the specific valgrind leak record
that enabled the bug to be found (note that the new valgrind
suppressions usage was critical for finding this bug among all other
libgpgme memory leaks):
==23983== 1,044 bytes in 1 blocks are definitely lost in loss record 7 of 8
==23983== at 0x4C2C494: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23983== by 0x4E41D3A: gpg_decrypt (fko_encryption.c:422)
==23983== by 0x4E42520: fko_decrypt_spa_data (fko_encryption.c:626)
==23983== by 0x1155B0: incoming_spa (incoming_spa.c:519)
==23983== by 0x1180A7: process_packet (process_packet.c:211)
==23983== by 0x506D857: ??? (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.4.0)
==23983== by 0x117865: pcap_capture (pcap_capture.c:270)
==23983== by 0x10F937: main (fwknopd.c:353)
- [server] When GnuPG is used, the default now is to require that
incoming SPA packets are signed by a key listed in GPG_REMOTE_ID for each
access.conf stanza. In other words, the usage of GPG_REQUIRE_SIG
is no longer necessary in order to authenticate SPA packets via the
GnuPG signature. Verification of GnuPG signatures can be disabled with a
new access.conf variable GPG_DISABLE_SIG, but this is NOT a
recommended configuration.
- [client+server] Add --gpg-exe command line argument and GPG_EXE
config variable to ~/.fwknoprc and the access.conf file so that the path
to GnuPG can be changed from the default /usr/bin/gpg path.
Updated pcap_dispatch() default packet count from zero to 100.
This change was made to ensure backwards compatibility with older
versions of libpcap per the pcap_dispatch() man page, and also because
some of a report from Les Aker of an unexpected crash on Arch Linux with
libpcap-1.5.1 that is fixed by this change (closes#110).
[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.
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)
^
Bug fix for --nat-rand-port mode to ensure that the port to be
NAT'd is properly defined so that the fwknopd server will NAT
connnections to this port instead of applying the NAT operation to the
port that is to be accessed via -A. This change also prints the
randomly assigned port to stdout regardless of whether --verbose mode is
used (since it not then the user will have no idea which port is
actually going to be NAT'd on the fwknopd side).
[libfko] Added the ability to maintain backwards compatibility with the
now deprecated "zero padding" strategy in AES mode that was a hold over
from the old perl fwknop implementation. This enables the backwards
compatiblity tests to continue to pass in the test suite.
Added --enable-openssl-checks to send all SPA packets encrypted via libfko
through the OpenSSL library to ensure that the libfko usage of AES is always
compatible with OpenSSL. This ensures that the fwknop usage of AES is properly
implemented as verified by the OpenSSL library, which is a frequently audited
high profile crypto engine. If a vulnerability is discovered in OpenSSL and a
change is made, then the --enable-openssl-checks mode will allow the test suite
to discover this in a automated fashion for fwknop.
Significant bug fix to honor the full encryption key length for
user-supplied Rijndael keys > 16 bytes long. Previous to this bug fix,
only the first 16 bytes of a key were actually used in the encryption/
decryption process even if the supplied key was longer. The result was
a weakening of expected security for users that had keys > 16 bytes,
although this is probably not too common. Note that "passphrase" is
perhaps technically a better word for "user-supplied key" in this
context since Rijndael in CBC mode derives a real encryption/decryption
key from the passphrase through a series of applications of md5 against
the passphrase and a random salt. This issue was reported by Michael T.
Dean. Closes issue #18 on github.
