Bug#532736: CVE-2009-1391: Buffer overflow in Compress::Raw::Zlib

Niko Tyni ntyni at debian.org
Thu Jun 11 21:00:11 UTC 2009


On Thu, Jun 11, 2009 at 12:42:12PM +0300, Niko Tyni wrote:
> On Thu, Jun 11, 2009 at 10:00:08AM +0200, Stefan Fritsch wrote:
> > Package: perl
> > Version: 5.10.0-19
> > Severity: grave
> > Tags: security
> > Justification: user security hole

> > Compress::Raw::Zlib versions before 2.017 contain a buffer overflow in
> > inflate(). A badly formed zlib-stream can trigger this buffer overflow and cause
> > the perl process at least to hang or to crash.

> > https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2009-1391

> My preliminary understanding is that the minimal fix could be just this hunk:

> -            Sv_Grow(output, SvLEN(output) + bufinc) ;
> +            Sv_Grow(output, SvLEN(output) + bufinc +1) ;

> but I'm not quite sure if we also need the "Only setup the stream output
> pointers if there is spare capacity in the outout SV" part in
> 
>  http://search.cpan.org/diff?from=Compress-Raw-Zlib-2.015&to=Compress-Raw-Zlib-2.017#Zlib.xs 

It now seems to me that the latter part is only relevant with the
LIMIT_OUTPUT functionality first introduced in 2.015. So it shouldn't
be needed for the Lenny security updates.

(I've found no way to pass the function an output buffer for appending
 that's already full to the last byte on the C side. So there should
 always be enough room in the buffer at the initialization phase.)

I've verified that the minimal off-by-one fix above (attached for
convenience) removes the valgrind error in the original proof of concept
(available at https://bugzilla.redhat.com/attachment.cgi?id=346729).

The attached version of the patch applies against
libcompress-raw-zlib-perl/2.012-1 as is, and against
ext/Compress/Raw/Zlib/Zlib.xs in perl/5.10.0-19 with minimal fuzz.

The issue doesn't affect Etch AFAICS, as Compress-Raw-Zlib was only
introduced in the Perl core in the 5.9 development line, and the separate
libcompress-raw-zlib-perl package wasn't present in Etch.

Security team, I'd love to have some confirmation on all this. I'll make
my best to get the fix into sid in the weekend, hopefully Friday night.

@pkg-perl: if somebody wants to handle the separate package, be my
guest. I'll prioritize the perl package and will look at the other one
afterwards if necessary.

Cheers,
-- 
Niko Tyni   ntyni at debian.org


More information about the Perl-maintainers mailing list