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 attachment 62357 [details] testcase 1 sh cgi script that crashes opera/firefox by sending content-encoding: gzip.
Created attachment 62358 [details] testcase 2 (png) png file with a specially crafted IDAT chunk.
Created attachment 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 attachment 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 attachment 62457 [details, diff] proposed patch Mark Adler proposed the attached patch
Vapier/Solar please advise/provide an updated ebuild.
Created attachment 62463 [details] zlib-1.2.2-r1.ebuild
Created attachment 62464 [details, diff] 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
