Set restrictive permissions on /etc/fwknop/ directory and /etc/fwknop/* files.
Current default permissions on /etc/fwknop/ and /etc/fwknop/* are too lax.
Implemented a new check to ensure that the iptables 'comment' match exists to
ensure the proper environment for fwknopd operations. This check is controlled
by the new ENABLE_IPT_COMMENT_CHECK variable, and was suggested by Hank
Leininger.
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
Added FLUSH_IPFW_AT_INIT and FLUSH_IPFW_AT_EXIT for ipfw firewalls to emulate
the corresponding functionality that is implemented for iptables firewalls.
Bug fix for ipfw firewalls to ensure that if the ipfw expire set is zero, then
do not disable this set whenever the FLUSH_IPFW* variables are enabled.
These changes were suggested by Jonathan Schulz.
Applied patch from Jonathan Schulz to ensure that the fwknop client reads all
data from a remote webserver when resolving the client IP address in -R mode.
Jonathan indicated that some webservers would transfer HTTP headers and data
separately, and a single recv() would therefore fail to get the necessary IP
information.
This commit fixes the following memory leak found with the test suite running
in valgrind mode:
HEAP SUMMARY:
in use at exit: 217 bytes in 3 blocks
total heap usage: 27 allocs, 24 frees, 5,260 bytes allocated
44 bytes in 1 blocks are definitely lost in loss record 1 of 3
at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x50CB861: strndup (strndup.c:46)
by 0x4E3A4D4: fko_verify_hmac (fko_hmac.c:54)
by 0x4E394DD: fko_new_with_data (fko_funcs.c:220)
by 0x10B3A7: main (fwknop.c:408)
44 bytes in 1 blocks are definitely lost in loss record 2 of 3
at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x50CB801: strdup (strdup.c:43)
by 0x4E3A3FC: fko_calculate_hmac (fko_hmac.c:162)
by 0x4E3A552: fko_verify_hmac (fko_hmac.c:86)
by 0x4E394DD: fko_new_with_data (fko_funcs.c:220)
by 0x10B3A7: main (fwknop.c:408)
129 bytes in 1 blocks are definitely lost in loss record 3 of 3
at 0x4C2B7B2: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4E36A03: add_salted_str (cipher_funcs.c:298)
by 0x4E3A587: fko_verify_hmac (fko_hmac.c:75)
by 0x4E394DD: fko_new_with_data (fko_funcs.c:220)
by 0x10B3A7: main (fwknop.c:408)
LEAK SUMMARY:
definitely lost: 217 bytes in 3 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
still reachable: 0 bytes in 0 blocks
suppressed: 0 bytes in 0 blocks
This commit fixes the following (found with the test suite in valgrind mode):
568 bytes in 1 blocks are still reachable in loss record 1 of 1
at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x50B1C9A: __fopen_internal (iofopen.c:76)
by 0x10D0CD: process_rc (config_init.c:516)
by 0x10D645: config_init (config_init.c:752)
by 0x10AB13: main (fwknop.c:70)
This commit fixes the following memory caught with the test suite in valgrind
mode:
HEAP SUMMARY:
in use at exit: 285 bytes in 4 blocks
total heap usage: 11 allocs, 7 frees, 3,179 bytes allocated
5 bytes in 1 blocks are indirectly lost in loss record 1 of 4
at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x50CB801: strdup (strdup.c:43)
by 0x4E3A7B2: fko_set_username (fko_user.c:96)
by 0x4E39628: fko_new (fko_funcs.c:86)
by 0x10AB54: main (fwknop.c:83)
7 bytes in 1 blocks are indirectly lost in loss record 2 of 4
at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4E395D7: fko_new (fko_funcs.c:62)
by 0x10AB54: main (fwknop.c:83)
17 bytes in 1 blocks are indirectly lost in loss record 3 of 4
at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4E3A06A: fko_set_rand_value (fko_rand_value.c:114)
by 0x4E39605: fko_new (fko_funcs.c:75)
by 0x10AB54: main (fwknop.c:83)
285 (256 direct, 29 indirect) bytes in 1 blocks are definitely lost in loss record 4 of 4
at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4E395BA: fko_new (fko_funcs.c:46)
by 0x10AB54: main (fwknop.c:83)
LEAK SUMMARY:
definitely lost: 256 bytes in 1 blocks
indirectly lost: 29 bytes in 3 blocks
possibly lost: 0 bytes in 0 blocks
still reachable: 0 bytes in 0 blocks
suppressed: 0 bytes in 0 blocks
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)
