Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 19 Jun 2014 14:08:53 +0200
From: Tomas Hoger <thoger@...hat.com>
To: oss-security@...ts.openwall.com
Cc: jamie@...onical.com, cve-assign@...re.org
Subject: Re: Re: cups-browsed remote exploit

Hi!

It seems this CVE request slipped through the cracks.


On Fri, 25 Apr 2014 15:24:15 -0500 Jamie Strandboge wrote:

> On 04/02/2014 03:18 PM, cve-assign@...re.org wrote:
> >> For this it creates a filter-script
> > 
> >> snprintf
> > 
> >> "%s/filter/pdftoippprinter \"$1\" \"$2\" \"$3\" \"$4\" \"$5
> >> $extra_options\"\n", p->name, pdl, make_model, cups_serverbin);
> > 
> >> its easy to inject code to the script e.g. via model name or pdl
> >> key which is taken from the LAN packets.
> > 
> > Use CVE-2014-2707.
> 
> This issue was reported as fixed in 1.0.51:
> http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/revision/7188
> 
> but it was found that the fix was incomplete with the full fix in
> 1.0.53:
> http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/revision/7194
> 
> Should this get a second CVE or should we continue to use
> CVE-2014-2707?

Note that there is another CVE needed for that commit, more specifically
for the "In addition, some fixes against OOB access are done." part.
That issue affects versions before 1.0.41 (which is the first version
affected by CVE-2014-2707) and can be used to crash cups-browsed
remotely.

> Furthermore, another security issue was also fixed in 1.0.53:
> http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/revision/7195
> 
> "
> - cups-browsed: SECURITY FIX: Fix on usage of the
>   "BrowseAllow" directive in cups-browsed.conf. Before, if the
>   argument of a "BrowseAllow" directive is not understood it
>   is treated as the directive not having been there, allowing
>   any host if this was the only "BrowseAllow" directive. Now
>   we treat this as a directive which no host can fulfill, not
>   allowing any host if it was the only one. No "BrowseAllow"
>   directive means access for all, as before (Bug #1204).
> "
> 
> I believe this should receive a CVE.
> 
> Thanks
> 
> References:
> https://bugzilla.novell.com/show_bug.cgi?id=871327
> https://bugs.linuxfoundation.org/show_bug.cgi?id=1204

-- 
Tomas Hoger / Red Hat Security Response Team

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.