Buffer bug in filter function about mcrypt_compat HOT 5 CLOSED

This is a cleaner fix:
if ($this->block_mode) {
$bucket->data = $this->buffer . $bucket->data;
$this->buffer = '';

from mcrypt_compat.

So one thing that'd help is some code that'd enable me to reproduce the problem and verify the fix. In lieu of that I can attempt to reproduce the issue based on your description of the problem, but it'd be faster if you could provide that yourself lol.

Being able to reproduce the issue also enables the creation of a unit test.

from mcrypt_compat.

Yes, I agree that the proper procedure would be to provide code to reproduce the issue, however this is a logical flaw that can be described in words. I have encountered this when trying to decrypt data. The scenario was that 13 bytes were in the buffer and 611 bytes in $bucket->data. That makes 624 bytes total that is evenly divided by a block length of 16 and since $extra = strlen($bucket->data) % $this->block_length will be 0 then nothing will be done to take care of the 13 bytes in the buffer since the buffer is only adjusted if there is a remainder. The result is that the 13 bytes remains in the buffer and will cause the decryption to break on the next call to the filter function. Clearing the buffer after its content has been added to $bucket->data solves the problem. How about this test case with a file of size 1888 bytes:
$opts = array('iv'=>$iv, 'key'=>$key, 'mode'=>'cbc');
$fd = fopen($encrypted_file, 'rb');
stream_filter_append($fd, "mdecrypt.rijndael-128", STREAM_FILTER_READ, $opts);
$content .= fread($fd, 653);
$content .= fread($fd, 611);
$content .= fread($fd, 624);

from mcrypt_compat.

Does 0220d59 fix the issue for you?

It is quite difficult to unit test this as PHP doesn't really let you control (in-so-far as I know) how much of the file PHP actually reads. It doesn't look like it looks at the parameters that are passed to fread. Like 653 + 611 + 624 = 1888. So I tried to read the first 653 bytes and $bucket->data was already 1888 so I was unable to test the issue. This was true with php://memory, php://temp and an actual file.

I tried to have two file pointers - one that was write only and one that was read only. I then tried to write 653 bytes with the write-only file pointer and then read the 653 bytes with the read-only file pointer but locking interferes with that.

from mcrypt_compat.

Yes, I have verified that it does fix the issue. Thanks!

from mcrypt_compat.