Bugzilla Bug 201570

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 an attachment (id=137954) [edit]
cups-SNMP-CVE-2007-5849.patch

ping

Created an attachment (id=138275) [edit]
cups-1.2.12-r4.ebuild

Created an attachment (id=138277) [edit]
cups-1.3.4-r4.ebuild

Created an attachment (id=138279) [edit]
cups-CVE-2007-5849.patch

Created an attachment (id=138281) [edit]
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.