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
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.
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).
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.
This is a fairly significant commit that lays the groundwork for getting
selectable HMAC modes working for both the client and server. One libfko API
change was required so that the hmac_type is passed into fko_new_with_data().
This allows the server to set the hmac_type via access.conf stanzas. The
effort in this commit will be extended to allow HMAC MD5, SHA1, and SHA512
also function properly.
Now that encryptions keys and hmac keys may be acquired from /dev/random with
--key-gen (and base64 encoded), they may contain NULL bytes. This emphasizes
the need to not leverage code that assumes C-style strings when making use of
key information.
