[server] Updated PCAP_LOOP_SLEEP default to 1/10th of a second (in
microseconds). This was supposed to be the default anyway, but C
Anthony Risinger reported a bug where fwknopd was consuming more
resources than necessary, and the cause was PCAP_LOOP_SLEEP set by
default to 1/100th of a second - this has been fixed.
This commit fixes memory leaks like the following in the fwknop client:
HEAP SUMMARY:
in use at exit: 300 bytes in 11 blocks
total heap usage: 100 allocs, 89 frees, 16,583 bytes allocated
16 bytes in 1 blocks are indirectly lost in loss record 1 of 11
at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x5146C59: __nss_lookup_function (nsswitch.c:456)
by 0x5C3D63E: ???
by 0x50FF3FC: getpwuid_r@@GLIBC_2.2.5 (getXXbyYY_r.c:256)
by 0x508938E: cuserid (cuserid.c:37)
by 0x4E3983A: fko_set_username (fko_user.c:65)
by 0x4E38D5C: fko_new (fko_funcs.c:84)
by 0x10A824: main (fwknop.c:75)
16 bytes in 1 blocks are indirectly lost in loss record 2 of 11
at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x5146C59: __nss_lookup_function (nsswitch.c:456)
by 0x5C3D658: ???
by 0x50FF3FC: getpwuid_r@@GLIBC_2.2.5 (getXXbyYY_r.c:256)
by 0x508938E: cuserid (cuserid.c:37)
by 0x4E3983A: fko_set_username (fko_user.c:65)
by 0x4E38D5C: fko_new (fko_funcs.c:84)
by 0x10A824: main (fwknop.c:75)
16 bytes in 1 blocks are indirectly lost in loss record 3 of 11
at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x5146C59: __nss_lookup_function (nsswitch.c:456)
by 0x5C3D672: ???
by 0x50FF3FC: getpwuid_r@@GLIBC_2.2.5 (getXXbyYY_r.c:256)
by 0x508938E: cuserid (cuserid.c:37)
by 0x4E3983A: fko_set_username (fko_user.c:65)
by 0x4E38D5C: fko_new (fko_funcs.c:84)
by 0x10A824: main (fwknop.c:75)
16 bytes in 1 blocks are indirectly lost in loss record 4 of 11
at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x5146C59: __nss_lookup_function (nsswitch.c:456)
by 0x5C3D68C: ???
by 0x50FF3FC: getpwuid_r@@GLIBC_2.2.5 (getXXbyYY_r.c:256)
by 0x508938E: cuserid (cuserid.c:37)
by 0x4E3983A: fko_set_username (fko_user.c:65)
by 0x4E38D5C: fko_new (fko_funcs.c:84)
by 0x10A824: main (fwknop.c:75)
Enhanced the libfko decoding routine to include bounds checking on decrypted
SPA data. This includes verifying the number of fields within incoming SPA
data (colon separated) along with verifying string lengths of each field.
When using the --nat-local argument on the fwknop client command line, the
fwknopd server needs to add an INPUT ACCEPT rule for the requested access
since the incoming connection is destined for a local socket. Added test
suite support to test --nat-local access.
[test suite] Minor bug fix to ensure that all file_find_regex() calls return
true if all regex's are matched and false if any regex does not match data in
the specified file.
Richard Haas reported the test suite failing on Mac OS X systems with the
existence check for the libfko library. Damien Stuart advised that the library
has a different extention '.dylib' on Mac OS X, so this change accounts for the
difference.
This change ensures that we only cache replay digests for those SPA packets
that actually decrypt. Not doing this would have allowed an attacker to
potentially fill up digest cache space with digests for garbage packets.
This commit fixes a bug where the same encryption key used for two stanzas in
the access.conf file would result in access requests that matched the second
stanza to always be treated as a replay attack. This has been fixed for
the fwknop-2.0.1 release, and was reported by Andy Rowland. Now the fwknopd
server computes the SHA256 digest of raw incoming payload data before
decryption, and compares this against all previous hashes. Previous to this
commit, fwknopd would add a new hash to the replay digest list right after
the first access.conf stanza match, so when SPA packet data matched the
second access.conf stanza a matching replay digest would already be there.
