and fwknopd_utests binaries.
When profil coverage is enbaled, lcov filee are parsed by test-fwknop.pl and added
to the main profil coverage report in the output directory.
Running make from the main directory build the c-unit test suites if enabled.
Add a new fko_set_encoded_data() function gated by #define
FUZZING_INTERFACES to allow encryption and authentication to be bypassed
for fuzzing purposes (and only fuzzing purposes). The fko-wrapper code
has been extended to process data in the
test/fko-wrapper/fuzz_spa_payloads file, which is created by the new
python fuzzer. Typical workflow is:
$ cd test/fko-wrapper
$ ../spa_fuzzer.py > fuzz_spa_payloads
$ make fuzzing
(as root):
./test-fwknop.pl --enable-profile-coverage --enable-fuzzing-interfaces --enable-all --include wrapper
[+] Starting the fwknop test suite...
args: --enable-profile-coverage --enable-fuzzing-interfaces --enable-all --include wrapper
Saved results from previous run to: output.last/
Valgrind mode enabled, will import previous coverage from:
output.last/valgrind-coverage/
[+] Total test buckets to execute: 2
[Rijndael] [fko-wrapper] multiple libfko calls (with valgrind)......pass (1)
[Rijndael] [fko-wrapper] multiple libfko calls......................pass (2)
[profile coverage] gcov profile coverage............................pass (3)
[valgrind output] [flagged functions] ..............................pass (4)
Run time: 5.85 minutes
[+] 0/0/0 OpenSSL tests passed/failed/executed
[+] 0/0/0 OpenSSL HMAC tests passed/failed/executed
[+] 4/0/4 test buckets passed/failed/executed
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.
Added --disable-gpg to the autoconf ./configure script
via configure.ac. This makes it easy to not have fwknop/fwknopd
link against libgpgme even if it is installed on the local system.
The Debian hardening-includes package sets CFLAGS and LDFLAGS as follows for PIE support:
_HARDENED_PIE_CFLAGS := -fPIE
_HARDENED_PIE_LDFLAGS := -fPIE -pie
The configure.ac file has been updated to conform to the above.
- [client+server] Fernando Arnaboldi from IOActive found that strict
filesystem permissions for various fwknop files are not verified. Added
warnings whenever permissions are not strict enough, and ensured that
files created by the fwknop client and server are only set to user
read/write.
- [client] Fernando Arnaboldi from IOActive found a local buffer overflow
in --last processing with a maliciously constructed ~/.fwknop.run file.
This has been fixed with proper validation of .fwknop.run arguments.
