Fuzz passphrase API of Secure Cell

[ilammy]

This PR adds fuzzers for new Secure Cell API added in #577, and fixes implementation bugs found by those fuzzers.

Currently passphrase API supports only Seal mode so we add tools for that only (just like master key API is right now). In fact, the tools are more or less copypasta of master key tools.

Additionally, I have found that using the default 200,000 PBKDF2 iterations provides very unfulfilling fuzzing experience of around 7 executions per second. Lowering iteration count to 10 allows AFL to run 800 attempts every second which results in much more reasonable time until interesting crashes. Thus I have added a compile-time switch to adjust the iteration count. It is used only for fuzzing builds and is not documented.

Now, on to the bugs...

Validate key length on decryption

This is the first crash found by AFL. Decryption code fails to validate key length encoded in algorithm field of Secure Cell header and just proceeds to use it, assuming that it’s one of 128, 192, 256 bits.

Maximum value allowed by data format is 4096 bits (512 bytes), but the code allocates only 32 bytes for the derived key. Longer keys will cause a buffer overflow which allows an attacker to overwrite return address stored on the stack and to theoretically execute arbitrary code. Practically, this can be used for denial of service by exploiting the much more likely outcome – crash due to a segmentation fault.

Fix the issue by validating the key length and allowing only values produced by Themis: 128, 192, or 256 bits.

Avoid unsigned overflow in length computations

This is much more insidious one. Turns out that code like this:

length += sizeof(hdr->auth_tag_length) + hdr->auth_tag_length;

can cause an unsigned overflow on 32-bit systems which later leads to buffer overflow caused by incorrect pointer computations. To handle that we ensure that length never overflows by using a wider type for it (uint64_t).

Another fun fact is that code like this

length += hdr->iv_length + hdr->auth_tag_length + hdr->kdf_context_length;

can also overflow of all those fields are unsigned 32-bit (and they are). And on 32-bit platforms

length += sizeof(hdr->auth_tag_length) + hdr->auth_tag_length;

can overflow too because size_t is 32-bit.

We avoid intermediate overflows by spelling out additions:

length += hdr->iv_length;
length += hdr->auth_tag_length;
length += hdr->kdf_context_length;
// u64 += u32

which causes the compiler to generate correct code.

Bad news here is that unsigned integer overflow is fully defined in C and this issue is normally not caught by sanitizers, static analyzers, etc. Well... let's hope that at least this piece of code is now free from such bugs.

Checklist

• Change is covered by automated tests
• The coding guidelines are followed
• Example projects and code samples are updated