Using the 'fiu-run' fault injection binary, a couple of cases were
turned up with libfko does not properly check the strdup() return value.
This commit fixes these issues, and here is an illustration of the stack
trace for one such issue:
Core was generated by `../client/.libs/fwknop -A tcp/22 -a 127.0.0.2 -D
127.0.0.1 --get-key local_spa.'.
Program terminated with signal 11, Segmentation fault.
#0 __strnlen_sse2 () at ../sysdeps/x86_64/multiarch/../strnlen.S:34
34 ../sysdeps/x86_64/multiarch/../strnlen.S: No such file or directory.
(gdb) where
#0 __strnlen_sse2 () at ../sysdeps/x86_64/multiarch/../strnlen.S:34
#1 0x00007effa38189bc in _rijndael_encrypt (enc_key_len=<optimized out>, enc_key=<optimized out>, ctx=0x7effa5945750) at fko_encryption.c:141
#2 fko_encrypt_spa_data (ctx=0x7effa5945750, enc_key=<optimized out>, enc_key_len=<optimized out>) at fko_encryption.c:605
#3 0x00007effa381a2d6 in fko_spa_data_final (ctx=0x7effa5945750, enc_key=enc_key@entry=0x7fff3ff4aa10 "fwknoptest", enc_key_len=<optimized out>, hmac_key=hmac_key@entry=0x7fff3ff4aaa0 "", hmac_key_len=0) at fko_funcs.c:489
#4 0x00007effa405f2fb in main (argc=<optimized out>, argv=<optimized out>) at fwknop.c:449
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)
This commit updates all authorship and copyright information to include a
standard header that references the AUTHORS and CREDITS file. This standard
header was written by the Debian legal team at the request of Franck Joncourt.
Integer lengths that are negative are never valid. This commit also
extends the fuzzing capabilities of the test/fko-wrapper code to
validate libfko calls with negative length arguments, and one crash
scenario with a negative length for the encryption key was found (and
fixed) this way.
[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 fixes a couple of overflow conditions for Rijndael and HMAC keys
that are larger than anticipated maximums. In the case of Rijndael, PKCS#5 1.5
is supported up to key sizes of 32 bytes or smaller (and maintains compatibility
with OpenSSL, and future versions will support PKCS#5 2.0 (PBKDF2) while allowing
for larger key sizes. HMAC keys may be up to 128 bytes even for digest
algorithms such as SHA256 that have block sizes that are smaller than this.
Bug fix to check b64_decode() return value to ensure that
non-base64 encoded data is never used. Even though other validation
routines checked decoded results, it is important to discard invalid
data as early as possible. Note too that such invalid data would only
be provided to b64_decode() after proper decryption, so the client must
provide authentic SPA data.
