Replace strlcpy() with memcpy() since the source buffer is not a string.
strlcpy() caught this anyway, but memcpy() usage is probably more valid.
==29766==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x562bc2e50420 in strlcpy /home/mbr/git/fwknop.git/common/strlcpy.c:61:3
#1 0x562bc2e25362 in process_packet /home/mbr/git/fwknop.git/server/process_packet.c:225:5
#2 0x7fa6173c9d57 (/lib64/libpcap.so.1+0x1fd57)
#3 0x562bc2e2456a in pcap_capture /home/mbr/git/fwknop.git/server/pcap_capture.c:227:15
#4 0x562bc2e13ef0 in main /home/mbr/git/fwknop.git/server/fwknopd.c:296:13
#5 0x7fa61643724a in __libc_start_main /usr/src/debug/glibc-2.27-74-g68c1bf8097/csu/../csu/libc-start.c:308:16
#6 0x562bc2d9dec9 in _start (/home/mbr/git/fwknop.git/server/.libs/fwknopd+0x1dec9)
Uninitialized value was created by a heap allocation
#0 0x562bc2da6c84 in malloc (/home/mbr/git/fwknop.git/server/.libs/fwknopd+0x26c84)
#1 0x7fa6173ca996 (/lib64/libpcap.so.1+0x20996)
SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/mbr/git/fwknop.git/common/strlcpy.c:61:3 in strlcpy
utils.c:217:13: warning: variable 'i' is incremented both in the loop header and in the loop
body [-Wfor-loop-analysis]
i++;
^
utils.c:213:34: note: incremented here
for (i=0; i<strlen(str); i++)
strlcat() needs to be informed about the actual size of the buffer. Two
calls simply used the size expected, thus potentially allowing
stack-based buffer overflows.
There is no direct security impact in this case, since the code affected
is on the client side, and the input comes from configuration
information.
In fwknop, the values generated using random() are only used for the ID
field of raw IP packets. As indicated in the corresponding comments,
this value does not really matter, and it does not really have to be
random at all.
However, it should not hurt to initialize the entropy pool before
generating random values. arc4random() would be a better choice, but it
is not portable across the range of systems currently supported by
fwknop.
execvp() is (usually) equivalent to execvpe(), without enforcing any
change to the environment. However, unlike execvp(), execvpe() is not
standardized by POSIX, and may therefore not be available nor detected
when configuring the project (like on NetBSD).
No place could be found in fwknop to be using execvpe() and changing the
environment. Therefore it seems only logical (and safer) to use execvp()
instead.
This also updates the tests to reflect this change.
