Twitter
78
February 14, 2014
PEFS Security Audit
This is the result of a short 13-hour security audit of Private Encrypted File System (PEFS).
Thanks to Matt Olander for funding this audit.
-----------------------------------------------------------------------
PEFS Security Audit
Taylor Hornby
February 07, 2014
-----------------------------------------------------------------------
1. Introduction
This report documents the results of a 13-hour security audit on
Private Encrypted File System (PEFS). The audit uncovered several
minor problems, some of which may compromise confidentiality.
1.1. What is PEFS?
PEFS [1] is an encrypted filesystem similar to EncFS and eCryptFS.
PEFS is unlike block-level encryption (e.g. TrueCrypt) in that the
ciphertext mirrors the directory structure of the plaintext.
1.2. Audit Scope
The audit was performed by reading the PEFS source code [2]. The git
commit hash of the code that was audited is:
fb7c4a188cfa7ba69987a1a61104c56f63db5395
This audit focused primarily on PEFS's cryptographic design and
implementation. This includes PEFS's use of crypto primitives, but
not the implementations of the primitives themselves (i.e. the AES
implementation). Some integer overflow issues were discovered, but
looking for memory corruption vulnerabilities was not a priority of
the audit. Bugs in the file system implementation (pefs_vnops.c) were
also out of scope.
2. Issues
This section covers all of the security issues discovered during the
audit. They are each given a rating in three variables:
Exploitability: How hard is it for an attacker to exploit?
Security Impact: How bad is it if an attacker can exploit it?
Confirmation: Has the vulnerability been confirmed to exist?
2.1. HMAC and Other Secrets Not Compared in Constant Time
Exploitability: Low
Security Impact: Low
Confirmation: Confirmed by inspecting the code.
On line 357 of pefs_key.c, memcmp() is used to verify an HMAC. This
introduces a timing attack that an attacker might be able to use to
compute the HMAC of an arbitrary message. This is the HMAC used when
encrypting child keys for the key chains feature, not the VMAC (which
is compared in constant time).
There are several other non-constant-time comparisons. I am not sure
if they are relevant to security:
- The comparison of ptk_tweak in pefs_tkey_cmp() in pefs_vnops.c.
- Comparison of what might be cleartext filenames in
pefs_enccn_parsedir() in pefs_vnops.c.
- The comparisons of pk_keyid in pefs_crypto.c, pefs_ctl.c, and
pefs_keychain.c.
In general, when secrets are compared for equality, it should be done
in constant time so that the running time does not leak information
about their actual values.
2.2. Same Key Used for HMAC and Encryption
Exploitability: Very Low
Security Impact: Low
Confirmation: Confirmed by inspecting the code.
This issue affects the key chain system, which is an optional PEFS
feature. If the key chains feature is not used, the file encryption
is unaffected.
The same key is used for encryption and authentication in pefs_key.c.
This happens in the pefs_key_cipher() procedure. The variable 'key'
is created by HMACing a distinguisher string with another key called
pxk_key. The resulting 'key' is used twice: Once to encrypt the data,
and a second time to HMAC the ciphertext.
This does not create immediate problems, but using the same key for
multiple purposes is a bad practice. Instead, use HKDF to generate
two separate keys for the two different purposes.
2.3. Zero IV Used with CTR Mode in pefs_key.c
Exploitability: Medium (Depends on the use case.)
Security Impact: High
Confirmation: Confirmed by inspecting the code.
This issue affects the key chain system, which is an optional PEFS
feature. If the key chains feature is not used, the file encryption
is unaffected.
The pefs_key_cipher() procedure in pefs_key.c encrypts data using AES
in CTR mode with a zero IV. This means that if multiple messages are
encrypted with the same key, they are XORed with the same keystream.
Here's an example of how this can be exploited to reveal the context
of another user's files:
The key chain graph looks like:
A -> Z
A -> S
B -> S
The 'Z' key is encrypted with a parent key that only Alice knows.
The 'S' key is encrypted with Alice's parent key as well. Bob also
has access to 'S'.
In this scenario, Bob knows S, so he can XOR the known value of
S with Alice's encryption of S to get the key stream generated by
Alice's parent key. Bob can then XOR this with Alice's Z ciphertext
to get Z. If Bob did not know S, he could learn Z XOR S by XORing the
two ciphertexts together.
This is a problem whenever a parent key encrypts two or more children
keys. Instead of using a NULL IV, a random IV should be generated at
encryption time and stored in the ciphertext (remember to HMAC the IV
too!).
2.4. No Salt Used When Hashing Password
Exploitability: Medium
Security Impact: Medium
Confirmation: Confirmed by inspecting the code.
When deriving a key from a password, PEFS does not use salt. This is
necessary, otherwise an attacker can use pre-computation attacks
(lookup tables, rainbow tables, etc.) to significantly speed up the
process of cracking PEFS-encrypted directories with weak passwords.
Not using a salt was an explicit design decision to avoid having to
store metadata. I recommend adding an (optional?) mode with metadata
to support having a salt, so that if it fits the user's use case,
they can benefit from the additional security.
2.5. Ambiguous Filename Encryption Padding
Exploitability: Very Low
Security Impact: Very Low
Confirmation: Confirmed by inspecting the source code.
The filename encryption routine pads the plaintext with null bytes.
This is fine, since file names can't contain null bytes in UNIX, but
if this code is reused for something else, it could become a problem.
Pad the plaintext unambiguously by using a padding mode like PKCS#7.
2.6. Filename Encryption is Not Randomized When Files are Renamed
Exploitability: Medium (Depends on how the user renames files.)
Security Impact: Low
Confirmation: Confirmed by inspecting the source code.
PEFS uses a random 64-bit value, called the tweak, to differentiate
between encrypted files. This value is actually re-used for three
things. It's used as part of the XTS mode tweak, to "randomize" the
filename encryption, and as the VMAC IV (after being encrypted).
For the filename encryption, the tweak value is used as a substitute
for an IV. Filenames are encrypted by first prefixing the tweak, then
encrypting them in CBC mode with a zero IV.
This is a problem, because the tweak does not change when files are
renamed. With CBC mode, the IV has to be chosen randomly at the time
of encryption, or it isn't IND-CPA secure. If the filename is
changed, the new ciphertext will be identical to the old ciphertext
up to the block that contains the first difference. See the third
part of this image for an awesome visual demonstration:
https://pbs.twimg.com/media/BekWHdVCYAAgsSm.jpg:large
There are plans to solve this problem by encrypting filenames with
wide-block encryption like EME2. This should be an adequate solution,
but it needs more analysis.
There may be other problems with the tweak design as well. More
analysis is recommended in Section 5.3
2.7. Part of Files Encrypted with CTR Mode
Exploitability: High
Security Impact: Medium-High
Confirmation: Confirmed by inspecting the code.
If a file's size in bytes is not evenly divisible by 16, the last
block of bytes (up to 15 bytes) is encrypted with CTR mode. If the
last block is ever changed, and an attacker has the ciphertexts from
before and after the change, they can XOR both ciphertexts together
to learn the XOR of the old and new plaintexts. If the attacker knows
(or can guess) the old plaintext, they can get the new plaintext.
The relevant code is in xts_smallblock() in pefs_xts.c.
The only good remediation for this (that I can think of) involves
increasing the file size so that it is divisible by 16 bytes. I think
the severity vulnerability justifies the increase in complexity.
2.8. gf_mul128() Does Not Execute In Constant Time
Exploitability: Low
Security Impact: Low
Confirmation: Confirmed by inspecting the source code.
The gf_mul128() procedure, part of the XTS implementation in
pefs_xts.c, branches on a value related to its input, which could
enable side channel attacks:
static __inline void
gf_mul128(uint64_t *dst, const uint64_t *src)
{
static const uint8_t gf_128_fdbk = 0x87;
int carry;
carry = shl128(dst, src);
if (carry != 0) // <-- time difference could leak 'carry'
((uint8_t *)dst)[0] ^= gf_128_fdbk;
}
I don't know if this leaks enough information to break the encryption
(very probably not), but it's better to be safe and do it in constant
time anyway. A constant time conditional XOR is given in [3].
2.9. Memory Corruption / Integer Overflows
Exploitability: Unknown
Security Impact: High (If exploitable)
Confirmation: Not confirmed.
I noticed several bits of code with integer overflow and
signed/unsigned problems. I didn't have time to check if any of these
are exploitable, or are even values controlled by the attacker, but
I will list them here to err on the side of caution:
- In pefs_name_encrypt(), the "+ 1" in the file name size check
could overflow the integer and make the check pass even if
the filename is too long:
r = PEFS_NAME_NTOP_SIZE(pefs_name_padsize(size)) + 1;
if (r > MAXNAMLEN) {
return (-ENAMETOOLONG);
}
- In pefs_enccn_set(), the variable encname_len is a *signed*
integer. It is checked to be less than MAXPATHLEN then passed to
memcpy(). When it gets passed to memcpy(), it is cast to
a size_t, which is unsigned. If encname_len has a negative value,
it will pass the first check, then memcpy will interpret it as
a large unsigned value:
if (encname_len >= MAXPATHLEN)
panic("pefs_enccn_set: invalid encrypted name length: %d",
encname_len);
// ...
memcpy(pec->pec_buf, encname, encname_len);
((char *) pec->pec_buf)[encname_len] = '\0';
pec->pec_cn.cn_namelen = encname_len;
- Several possibilities for integer overflows in pefs_xbase64.c:
if (datalength + 1 > targsize)
return (-1);
// ...
target[tarindex] |= (pos - Base64) >> 4;
if ((size_t)tarindex + 1 < targsize)
target[tarindex+1] =
((pos - Base64) & 0x0f) << 4 ;
// ...
target[tarindex] |= (pos - Base64) >> 2;
if ((size_t)tarindex + 1 < targsize)
target[tarindex+1] =
((pos - Base64) & 0x03) << 6;
- Another in pefs_write_int() that could cause the
vnode_pager_setsize() call to be skipped, which might lead to
memory corruption down the road:
nsize = fsize;
MPASS(uio->uio_offset <= fsize);
if (uio->uio_offset + uio->uio_resid > nsize) {
PEFSDEBUG("pefs_write: extend: 0x%jx (old size: 0x%jx)\n",
uio->uio_offset + uio->uio_resid, nsize);
nsize = uio->uio_offset + uio->uio_resid;
vnode_pager_setsize(vp, nsize);
}
3. Commendations
PEFS does a lot of things right. It uses standard constructions like
XTS mode, PBKDF2, and HKDF. It also diligently zeroes buffers that
once contained sensitive information. This makes auditing easier.
Correction 12/05/2014: XTS mode is probably not the ideal option, see
Thomas Ptacek's blog post for good reasons why:
http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/
4. Recommendations
There are some things that PEFS could do better:
- Instead of re-implementing CBC mode in pefs_name_enccbc(), it
would be better to use a well-tested implementation from a crypto
library.
- Use test vectors in unit tests and runtime tests to make sure the
crypto algorithms (XTS, HKDF, PBKDF2, AES, SHA, etc.) are
correct.
- Make pefs_hkdf_expand() take a uint8_t instead of an int for the
'idx' parameter, so that there is a compiler warning when the
function is used incorrectly. Or check that 'idx' is between
0 and 255.
5. Future Work
5.1. Memory Corruption Vulnerabilities
This audit did not focus on "classic" memory corruptions
vulnerabilities. Because of the integer overflow issues documented in
Issue 2.9, I think PEFS could benefit from an audit that specifically
focuses on these concerns.
5.2. The Tweak's Triple Burden
The 64-bit random tweak is re-used for three different purposes:
1. It acts like an IV for the filename encryption.
2. It is part of the XTS mode tweak.
3. (After being Encrypted) The VMAC IV.
There was not enough time in the audit to determine whether any of
these three uses interact in negative ways that would, for example,
lead to at least one of filename encryption, file contents
encryption, or the VMAC being broken. More analysis is needed.
The VMAC's IV appears to be taken from its input, which probably
causes problems. This issue was not investigated in this audit since
the VMAC is only used as a non-cryptographic checksum, and should not
be relied on for security.
6. Conclusion
This audit found several issues, the most significant of which are
issues 2.3, 2.6, and 2.7. The possible existence of memory corruption
bugs (Issue 2.9) is worrisome as well, since this code runs in kernel
space.
PEFS would benefit from more auditing time.
7. References
[1] https://wiki.freebsd.org/PEFS
[2] https://github.com/glk/pefs
[3] http://www.iacr.org/archive/ches2009/57470001/57470001.pdf
