Skip Menu |

This queue is for tickets about the Compress-Raw-Zlib CPAN distribution.

Report information
The Basics
Id: 92521
Status: resolved
Priority: 0/
Queue: Compress-Raw-Zlib

People
Owner: Nobody in particular
Requestors: sri [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 2.064



Subject: Z_OK instead of Z_BUF_ERROR
Hi, It looks like LimitOutput in Compress::Raw::Zlib::Inflate does not work correctly and inflate() keeps returning Z_OK instead of Z_BUF_ERROR. Here's a script that demonstrates the problem. use Compress::Raw::Zlib qw(Z_OK Z_BUF_ERROR Z_SYNC_FLUSH); # 1M "aaa..." my $in = 'a' x 1000000; my $deflate = Compress::Raw::Zlib::Deflate->new(WindowBits => -15, MemLevel => 8); $deflate->deflate($in, my $zip); $deflate->flush($zip, Z_SYNC_FLUSH); # Compression should stop after 10K "aaa..." with Z_BUF_ERROR my $inflate = Compress::Raw::Zlib::Inflate->new( Bufsize => 10000, LimitOutput => 1, WindowBits => -15 ); my $status = $inflate->inflate($zip, my $out); warn 'RESULT: ', length($out), ' of ', length($in), "\n"; warn "OK\n" if $status == Z_OK; warn "BUFFER ERROR\n" if $status == Z_BUF_ERROR; I'd also be very interested if there's a temporary workaround, since having your WebSocket server vulnerable to zip bombs is not particularly nice. -- sebastian
Show quoted text
> I'd also be very interested if there's a temporary workaround, since > having your WebSocket server vulnerable to zip bombs is not > particularly nice.
FYI: I did find a quick workaround that works at least for my use case, since WebSocket messages have their own framing, i know exactly when the compressed message ends and can just check if it has been fully consumed during decompression. -- sebastian
Hey Sebastian, looks like a silly bug in the code. Will need to test it out some more but the tentative fix is very straightforward. Edit Zlib.xs and find these line if (s->flags & FLAG_LIMIT_OUTPUT && (RETVAL == Z_OK || RETVAL == Z_BUF_ERROR )) break; Change them to this if (s->flags & FLAG_LIMIT_OUTPUT && (RETVAL == Z_OK || RETVAL == Z_BUF_ERROR )) { if (s->stream.avail_out == 0) RETVAL = Z_BUF_ERROR; break; } If you feel like giving that a go, and you find issues, please get back to me. cheers Paul
Thanks, works great now! -- sebastian
Oh, almost forgot. The test is missing a "AppendOutput => 1" to prevent ->flush from overwriting $zip, it doesn't appear to matter in this specific case, but might bite anyone who uses it as an example. -- sebastian
On Sun Feb 02 13:03:29 2014, SRI wrote: Show quoted text
> Oh, almost forgot. The test is missing a "AppendOutput => 1" to > prevent ->flush from overwriting $zip, it doesn't appear to matter in > this specific case, but might bite anyone who uses it as an example.
Hey Sebastian - which example are you referring to? Paul
Show quoted text
> Hey Sebastian - which example are you referring to?
I meant the regression test you added. https://metacpan.org/source/PMQS/Compress-Raw-Zlib-2.064/t/09limitoutput.t#L130 -- sebastian
ok, thanks Paul