Bug fix discovered with the libfiu fault injection tag
"fko_get_username_init" combined with valgrind analysis. This bug
is only triggered after a valid authenticated and decrypted SPA
packet is sniffed by fwknopd:
==11181== Conditional jump or move depends on uninitialised value(s)
==11181== at 0x113B6D: incoming_spa (incoming_spa.c:707)
==11181== by 0x11559F: process_packet (process_packet.c:211)
==11181== by 0x5270857: ??? (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.4.0)
==11181== by 0x114BCC: pcap_capture (pcap_capture.c:270)
==11181== by 0x10F32C: main (fwknopd.c:195)
==11181== Uninitialised value was created by a stack allocation
==11181== at 0x113476: incoming_spa (incoming_spa.c:294)
Add a new GPG_FINGERPRINT_ID variable to the access.conf file
so that full GnuPG fingerprints can be required for incoming SPA packets
in addition to the appreviated GnuPG signatures listed in GPG_REMOTE_ID.
From the test suite, an example fingerprint is
GPG_FINGERPRINT_ID 00CC95F05BC146B6AC4038C9E36F443C6A3FAD56
- [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.
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.
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 fixes a crash if the replay digest init() routine fails - fwknopd
attempted to make use of replay tracking anyway. The crash was discovered
during testing fwknopd with an AppArmor enforce policy deployed. The
following stack trace shows the crash (taken before the previous static
function commit):
Program received signal SIGSEGV, Segmentation fault.
__strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31
31 ../sysdeps/x86_64/multiarch/../strlen.S: No such file or directory.
(gdb) where
#0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31
#1 0x00007f59cabd8b26 in add_replay_file_cache (opts=opts@entry=0x7fff3eaa0bb0, digest=digest@entry=0x0) at replay_cache.c:516
#2 0x00007f59cabd8cf5 in add_replay (opts=opts@entry=0x7fff3eaa0bb0, digest=digest@entry=0x0) at replay_cache.c:472
#3 0x00007f59cabd62eb in incoming_spa (opts=0x7fff3eaa0bb0) at incoming_spa.c:536
#4 0x00007f59ca56164e in ?? () from /usr/lib/x86_64-linux-gnu/libpcap.so.0.8
#5 0x00007f59cabd7175 in pcap_capture (opts=opts@entry=0x7fff3eaa0bb0) at pcap_capture.c:269
#6 0x00007f59cabd3d4d in main (argc=5, argv=0x7fff3eaa1458) at fwknopd.c:314
* log_msg : New log_set_verbosity(): It sets the default verbosity for the
log module according to the verbose option set by the user through the command
line.
* Remove useless checks of the verbose option when log_msg() is invoked.
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).
Within the access loop always call fko_destroy() right up front whenever
ctx != NULL to ensure a clean slate each time through the loop regardless of
what state may have been reached the previous time through the loop.
These are simple logic fixes that would not have impacted run time to address
the following warnings generated by the CLANG static analyzer:
incoming_spa.c:433:17: warning: Value stored to 'attempted_decrypt' is never read
attempted_decrypt = 1;
^ ~
incoming_spa.c:647:13: warning: Value stored to 'acc' is never read
acc = acc->next;
^ ~~~~~~~~~
This change allows SPA clients to include long messages in command mode and
generally allows decryption operations to dictate success/failure instead of
SPA packet length to gate decryption attempts. Closes#40.
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.
This commit completes the conversion to the strtol() wrapper function in order
to remove all atoi() calls. In addition, variable max values are enforced
using more broadly defined RCHK_* values.
This commit replaces most atoi() calls (which don't report errors) with a strtol()
wrapper function for stronger string -> integer conversion validation.
Added a new '--pcap-file <file>' option to allow pcap files to
be processed directly by fwknopd instead of sniffing an interface. This
feature is mostly intended for debugging purposes.
For GPG mode, added a new access.conf variable "GPG_ALLOW_NO_PW" to make it
possible to leverage a server-side GPG key pair that has no associated
password. This comes in handy when a system requires the user to leverage
gpg-agent / pinentry which can present a problem in automated environments as
required by the fwknopd server. Now, it might seem like a problem to remove
the passphrase from a GPG key pair, but it's important to note that simply
doing this is little worse than storing the passphrase in the clear on disk
anyway in the access.conf file. Further, this link help provides additional
detail:
http://www.gnupg.org/faq/GnuPG-FAQ.html#how-can-i-use-gnupg-in-an-automated-environment
Ensure that an attacker cannot force a replay attack by intercepting an
SPA packet and the replaying it with the base64 version of "Salted__"
(for Rindael) or the "hQ" prefix (for GnuPG). This is an important fix.
The following comment was added into the fwknopd code:
/* Ignore any SPA packets that contain the Rijndael or GnuPG prefixes
* since an attacker might have tacked them on to a previously seen
* SPA packet in an attempt to get past the replay check. And, we're
* no worse off since a legitimate SPA packet that happens to include
* a prefix after the outer one is stripped off won't decrypt properly
* anyway because libfko would not add a new one.
*/
Conflicts:
lib/cipher_funcs.h
This commit fixes the following memory leak found with valgrind:
44 bytes in 1 blocks are definitely lost in loss record 2 of 2
at 0x482BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
by 0x490EA50: strdup (strdup.c:43)
by 0x10CD69: incoming_spa (incoming_spa.c:162)
by 0x10E000: process_packet (process_packet.c:200)
by 0x4862E63: ??? (in /usr/lib/i386-linux-gnu/libpcap.so.1.1.1)
by 0x4865667: pcap_dispatch (in /usr/lib/i386-linux-gnu/libpcap.so.1.1.1)
by 0x10DABF: pcap_capture (pcap_capture.c:226)
by 0x10A798: main (fwknopd.c:299)
Ensure that an attacker cannot force a replay attack by intercepting an
SPA packet and the replaying it with the base64 version of "Salted__"
(for Rindael) or the "hQ" prefix (for GnuPG). This is an important fix.
The following comment was added into the fwknopd code:
/* Ignore any SPA packets that contain the Rijndael or GnuPG prefixes
* since an attacker might have tacked them on to a previously seen
* SPA packet in an attempt to get past the replay check. And, we're
* no worse off since a legitimate SPA packet that happens to include
* a prefix after the outer one is stripped off won't decrypt properly
* anyway because libfko would not add a new one.
*/
This commit fixes the following memory leak found with valgrind:
44 bytes in 1 blocks are definitely lost in loss record 2 of 2
at 0x482BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
by 0x490EA50: strdup (strdup.c:43)
by 0x10CD69: incoming_spa (incoming_spa.c:162)
by 0x10E000: process_packet (process_packet.c:200)
by 0x4862E63: ??? (in /usr/lib/i386-linux-gnu/libpcap.so.1.1.1)
by 0x4865667: pcap_dispatch (in /usr/lib/i386-linux-gnu/libpcap.so.1.1.1)
by 0x10DABF: pcap_capture (pcap_capture.c:226)
by 0x10A798: main (fwknopd.c:299)
