Aaron Sigel reported to us a stack-based buffer overflow in the SNMP backend of CUPS when parsing the reply to an SNMP print lookup request. Exploitation may allow the remote execution of arbitrary code on the cups server. I'll attach a patch. Stefan and Timo, do not commit anything to CVS yet, as this issue is under embargo until Dec. 13. Please attach an updated ebuild to this bug (possibly also addressing bug 201042 ?) and we will do prestable testing here.
Created attachment 137954 [details, diff] cups-SNMP-CVE-2007-5849.patch
ping
Created attachment 138275 [details] cups-1.2.12-r4.ebuild
Created attachment 138277 [details] cups-1.3.4-r4.ebuild
Created attachment 138279 [details] cups-CVE-2007-5849.patch
Created attachment 138281 [details] pdftops-1.20.gentoo, fixing bug #201042
Thanks. Arch Security Liaisons, please test the attached ebuild (cups-1.2.12-r4) and report it stable on this bug. Target keywords : "alpha amd64 arm hppa ia64 m68k mips ppc ppc64 s390 sh sparc x86" CC'ing current Liaisons: alpha : ferdy amd64 : welp hppa : jer ppc : dertobi123 ppc64 : corsair sparc : ferdy x86 : tsunam For the change in the pdftops script, you should probably try printing a pdf file with lp(r) on a ps printer.
prints fine (well, at least not worse than before) on amd64.
(In reply to comment #7) > For the change in the pdftops script, you should probably try printing a pdf > file with lp(r) on a ps printer. PDF file to local PS printer ... ok PDF file to remote PS printer ... ok Test page from Windows to remote PCL printer ... ok x86 is fine.
Adding Ferris for sparc since i can't test this on sparc.
Tested on sparc only with a remote printer, because that is all I have. That said, sparc is fine, both with .ps files and with .pdf files (using the attached pdftops-1.20.gentoo filter). That said, why is ferdy the sparc liaison for security bugs? As far as I know, he is not a sparc user, and he is not a sparc developer, last I knew. Unless you have a good reason not to, please use either me or armin76 as the sparc arch contact.
Adding Blackb|rd to alpha since nobody in the alpha team can test this, he's in process of becoming a dev, so there's no problem.
sorry, a typo above lists ferdy for sparc, while it should be fmccor. Ferris, please excuse me and please test.
(In reply to comment #11) > That said, why is ferdy the sparc liaison for security bugs? As far as I know, > he is not a sparc user, and he is not a sparc developer, last I knew. Unless > you have a good reason not to, please use either me or armin76 as the sparc > arch contact. Blame me. Of course, you and Raul are our primary sparc contacts.
Tobias (Blackb|rd) just tested it and says: <Blackb|rd> Emerges fine on alpha. <Blackb|rd> Printing of PDF, PS, TXT works, as does remote printing and printer browsing. He couldn't post in this bug, dunno why. So alpha is okay, and ia64 as well. Thanks Tobias
Works for HPPA.
looks good on ppc64, too.
ppc looks good as well
Disclosure of this vulnerability has been pushed to Monday, 17.12.
This is public via http://www.cups.org/str.php?L2589 Printing, please commit this ebuild to the tree with stable keywords for the arches that responded.
(In reply to comment #13) > sorry, a typo above lists ferdy for sparc, while it should be fmccor. Ferris, > please excuse me and please test. > As mentioned in Comment 11, sparc is fine.
Arches, please test and mark stable net-print/cups-1.2.12-r4. Target keywords : "alpha amd64 arm hppa ia64 m68k mips ppc ppc64 s390 sh sparc x86" Already stabled : "alpha amd64 hppa ia64 ppc ppc64 sparc x86" Missing keywords: "arm m68k mips s390 sh"
GLSA 200712-14, thanks everyone.
