Bugzilla Bug 97547

I've discovered a data stream that causes zlib to corrupt an data structure,
resulting in the linked application dumping core.

Upstream contacted, but no reponse, awaiting vendor-sec to suggest alternate
contact address. (note this is totally unrelated to bug 94584 )

Created an attachment (id=62357) [details]
testcase 1

sh cgi script that crashes opera/firefox by sending content-encoding: gzip.

Created an attachment (id=62358) [details]
testcase 2 (png)

png file with a specially crafted IDAT chunk.

Created an attachment (id=62386) [details]
testcase 1 (cgi script)

This should crash any web browser that uses zlib to handle gzip content
encoding. confirmed with dillo, firefox, opera, mozilla.

Created an attachment (id=62396) [details]
testcase 3 (.gz)

specially crafted gzip file that should crash application using gzread()

$ display testcase.gz
Segmentation fault
$ clamscan testcase.gz
Segmentation fault
...etc.

$ MALLOC_CHECK_=1 identify testcase.gz 
malloc: using debugging hooks
*** glibc detected *** malloc: top chunk is corrupt: 0x08075840 ***
*** glibc detected *** free(): invalid pointer: 0x08073c78 ***
Segmentation fault

This looks like it could be exploitable to me, perhaps via sshd and corrupt
chunks of deflated data (although UsePrivilegeSeperation should stop it being
useful) or via web browser, emailed images, and so on.

Contacted Mark Adler, co-author of zlib who says he has forwarded my report to 
the developers mailing list for investigation.

Created an attachment (id=62457) [details]
proposed patch

Mark Adler proposed the attached patch

Vapier/Solar please advise/provide an updated ebuild. 

Created an attachment (id=62463) [details]
zlib-1.2.2-r1.ebuild

Created an attachment (id=62464) [details]
zlib-1.2.2-inftrees.patch

Updated patch using diff -u to go along with the updated ebuild

Due to the nature of this and the testcases, please lets aim for getting this
one 
out on or by Wend Jul 6th

ive got local zlib ebuilds/patches ready to go ...

Adding a selected member of releng (kugelfang) to make sure that any 
snapshots are not taken before the final release day.

kugelfang: this is still a confidential bug. 
If you could relay that fact a pretty critcial package bug is about to be fixed 
without sharing too may details to the rest of releng other than it being a core 
system package we would be thankful.

Anybody here can request CAN assignment please? (jaervosz || taviso)

Just talked with plasmaroo. Resnapshotting is no problem, we're still in
prerelease phase. Thanks for letting us know!

zlib author informs me CERT has been notified.

Colin Percival requested a CVE.

this is CAN-2005-2096

Could be exploitable, raising rating.

Arch Security liaisons, please test zlib 1.2.2-r1 and report back on this bug. 
Do NOT commit anything to Portage. 

I get this on ppc64:

$ display image.png
display: Corrupt image `image.png`.
$ 

I think that this correct, so ppc64 could go stable.

Looks sane on sparc.

Looks good on ppc. Adding KillerFox to CC for testing on hppa (I'm working with
him to test it).

Other than that, why do we have to test such simple patches? Everyone who
understands a bit of C knows that this code won't break on another architecture.
So testing it on one or two would be enough. I know it's policy and such, but
that's just what I think.

Looks good on hppa.

Fine for amd64. gunzip didn't vomit on testcase_3.gz :-)

This is public at 1400UTC today.

Public followup on bug 98121
GLSA 200507-05