- [server] Fernando Arnaboldi from IOActive found several DoS/code
execution vulnerabilities for malicious fwknop clients that manage to
get past the authentication stage (so a such a client must be in
possession of a valid access.conf encryption key). These vulnerbilities
manifested themselves in the handling of malformed access requests, and
both the fwknopd server code along with libfko now perform stronger input
validation of access request data. These vulnerabilities affect
pre-2.0.3 fwknop releases.
- [test suite] Added a new fuzzing capability to ensure proper server-side
input validation. Fuzzing data is constructed with modified fwknop
client code that is designed to emulate malicious behavior.
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
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
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.
*/
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.
Now that encryptions keys and hmac keys may be acquired from /dev/random with
--key-gen (and base64 encoded), they may contain NULL bytes. This emphasizes
the need to not leverage code that assumes C-style strings when making use of
key information.
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.
Added --key-gen to allow KEY_BASE64 and HMAC_KEY_BASE64 keys to be created from
reading random data from /dev/random. These keys can be placed within server
access.conf files and corresponding client .fwknoprc files for SPA
communications. The HMAC key is not used yet with this commit, but that is
coming.
For SPA packets encrypted with Rjindael, fwknop has always used CBC mode
even though ECB mode is mentioned in a couple of places. This change makes
more transparent use of block_encrypt() and block_decrypt() to ensure that
the appropriate mode is used. The default is CBC mode, but others can be
selected as well (-M <mode> for the fwknop client, and ENCRYPTION_MODE in
access.conf for the fwknopd server).
This is a significant update to allow AES encryption modes to be selected on a
per-key basis. For now, only ECB and CBC (recommended) modes are supported.
The default is ECB modes in order to maintain backwards compatibility with the
older perl version of fwknop and the Crypt::CBC CPAN module. This will likely
be changed to use CBC mode by default because of its better security
properties.
In the access.conf file on the server side, there is a new configuration
variable "ENCRYPTION_MODE" that controls the mode for the corresponding AES
key. On the client side, a new command line argument "--encryption-mode"
controls how the client encrypts SPA packets.
The two memory leaks were found with the test suite running in
--enable-valgrind mode - here are the relevant error messages:
For fwknopd server GPG clean up:
==345== 9 bytes in 1 blocks are definitely lost in loss record 2 of 2
==345== at 0x4C2815C: malloc (vg_replace_malloc.c:236)
==345== by 0x52F6B81: strdup (strdup.c:43)
==345== by 0x10FA57: add_string_list_ent (access.c:308)
==345== by 0x110513: parse_access_file (access.c:387)
==345== by 0x10B5FB: main (fwknopd.c:193)
For fwknop client rc file processing:
==8045== 568 bytes in 1 blocks are still reachable in loss record 12 of 12
==8045== at 0x4C2815C: malloc (vg_replace_malloc.c:236)
==8045== by 0x50A53AA: __fopen_internal (iofopen.c:76)
==8045== by 0x10C3FF: process_rc (config_init.c:446)
==8045== by 0x10C8F6: config_init (config_init.c:671)
==8045== by 0x10AC9E: main (fwknop.c:62)
There is also a new clean_exit() function that makes it easier to ensure that
resources are deallocated upon existing.
Added the 'const' qualifier to function prototype variables where possible.
In addition, reduced some functions to file-scope with 'static' where possible.
Also made a few minor changes to remove extra whitespace, and fixed a bug
in create_fwknoprc() to ensure the new fwknoprc filehandle is closed.
