This commit fixes a byte order warning for both sha1.c and md5.c like so:
sha1.c:127:6: warning: #warning Undetermined or unsupported Byte Order... We will try LITTLE_ENDIAN [-Wcpp]
Also removed a couple of header includes that appear not be needed.
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.
[client] (Franck Joncourt) Contributed a patch to allow the fwknop
client to be stopped during the password entry prompt with Ctrl-C before
any SPA packet is sent on the wire.
[client+server] Applied patch from Franck Joncourt to remove unnecessary
chmod() call when creating client rc file and server replay cache file.
The permissions are now set appropriately via open(), and at the same
time this patch fixes a potential race condition since the previous code
used fopen() followed by chmod().
- [client] Added '-P udpraw' to allow the client to send SPA packets over
UDP with a spoofed source IP address. This is in addition to the
original 'tcpraw' and 'icmp' protocols that also support a spoofed
source IP.
- [server] Bug fix to accept SPA packets over ICMP if the fwknop client
is executed with '-P icmp' and the user has the required privileges.
- [client+server] Fernando Arnaboldi from IOActive found that strict
filesystem permissions for various fwknop files are not verified. Added
warnings whenever permissions are not strict enough, and ensured that
files created by the fwknop client and server are only set to user
read/write.
- [client] Fernando Arnaboldi from IOActive found a local buffer overflow
in --last processing with a maliciously constructed ~/.fwknop.run file.
This has been fixed with proper validation of .fwknop.run arguments.
Chop any trailing '/' char, be more careful about handling incoming large HTTP
responses, print the HTTP request and response in --verbose --verbose mode.
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 (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
