Am 01.07.15 um 13:03 schrieb steffan.kar...@fox-it.com: > From: Steffan Karger <steffan.kar...@fox-it.com> > > Sebastian Krahmer from the SuSE security team reported that the buffer > overflow check in openvpn_decrypt() was too strict according to the > cipher update function contract: > > "The amount of data written depends on the block alignment of the > encrypted data: as a result the amount of data written may be anything > from zero bytes to (inl + cipher_block_size - 1) so outl should contain > sufficient room." > > This stems from the way CBC mode works, which caches input and 'flushes' > it block-wise to the output buffer. We do allocate enough space for this > extra block in the output buffer for CBC mode, but not for CFB/OFB modes. > > This patch: > * updates the overflow check to also verify that the extra block required > according to the function contract is available. > * uses buf_inc_len() to double-check for overflows during en/decryption. > * also reserves the extra block for non-CBC cipher modes. > > In practice, I could not find a way in which this would fail. The plaintext > is never longer than the ciphertext, and the implementations of CBC/OFB/CBC > for AES and BF in both OpenSSL and PolarSSL/mbed TLS do not use the buffer > beyond the plaintext length when decrypting. However, some funky OpenSSL > engine I did not check *might* use the buffer space required by the > function contract. So we should still make sure we have enough room > anyway. >
ACK from me. Arne
