Didier,
On 2012-11-28, at 6:58 AM, Didier 'OdyX' Raboud o...@debian.org wrote:
...
DocumentRoot has to be fixed that way IMHO as the attack is immediate and I
think it's a suitable fix for our stable releases. For SystemGroup, I think
it's reasonably okay to leave that bug open for stable
Marc,
On 2012-11-28, at 9:00 AM, Marc Deslauriers marc.deslauri...@canonical.com
wrote:
On 12-11-27 11:38 PM, Michael Sweet wrote:
After looking at this patch in detail, it doesn't actually prevent users in
the lpadmin group from modifying cupsd.conf and performing the specified
privilege
Michael,
On 12-11-29 10:12 AM, Michael Sweet wrote:
So, your alternate fix doesn't actually solve the problem as I can still
do something like:
PageLog /var/log/cups/../../../etc/shadow
Adding a check for ../ in the path will catch that, easy fix...
Also, there are a lot of other
Le mercredi, 28 novembre 2012 05.38:58, Michael Sweet a écrit :
After looking at this patch in detail, it doesn't actually prevent users in
the lpadmin group from modifying cupsd.conf and performing the specified
privilege escalation.
An alternate fix for cups-1.5 and earlier that
Didier,
Indeed, we can add additional directory checks to the simple fix, or for
purposes of the Debian packages just disable certain directives if they should
not be configured from their defaults.
WRT setting SystemGroup, that /is/ a valid configuration change that some sites
make;
Le mercredi, 28 novembre 2012 12.41:27, Michael Sweet a écrit :
Indeed, we can add additional directory checks to the simple fix, or for
purposes of the Debian packages just disable certain directives if they
should not be configured from their defaults.
Sure; sounds good.
WRT setting
On 12-11-27 11:38 PM, Michael Sweet wrote:
After looking at this patch in detail, it doesn't actually prevent users in
the lpadmin group from modifying cupsd.conf and performing the specified
privilege escalation.
An alternate fix for cups-1.5 and earlier that specifically addresses the
FYI, as a security fix for our stable releases in Ubuntu, we plan on
disabling cupsd.conf modification in the web interface entirely.
Attached is the patch we plan on using.
Marc.
Description: fix privilege escalation by disabling config file editing via
the web interface
Author: Marc
Le mardi, 27 novembre 2012 15.30:46, Marc Deslauriers a écrit :
FYI, as a security fix for our stable releases in Ubuntu, we plan on
disabling cupsd.conf modification in the web interface entirely.
Attached is the patch we plan on using.
Hi Marc,
while testing your patch I noticed it was not
On 12-11-27 03:51 PM, Didier 'OdyX' Raboud wrote:
Le mardi, 27 novembre 2012 15.30:46, Marc Deslauriers a écrit :
FYI, as a security fix for our stable releases in Ubuntu, we plan on
disabling cupsd.conf modification in the web interface entirely.
Attached is the patch we plan on using.
Hi
Note: disabling he web interface is not enough, you also need to disable HTTP
PUT in cupsd, which takes care of cupsctl too. However, since that also
disables helpful things like changing the log level you might want to
reconsider fixing things that way...
Sent from my iPad
On 2012-11-27, at
After looking at this patch in detail, it doesn't actually prevent users in the
lpadmin group from modifying cupsd.conf and performing the specified privilege
escalation.
An alternate fix for cups-1.5 and earlier that specifically addresses the
reported problem by requiring the log files to
Control: found -1 1.5.3-2.6
Control: found -1 1.5.3-2.4
Hi Jörg, and thanks for your bugreport,
as far as I understand your report, there are two seperate issues:
a) members of the lpadmin group can login to the webinterface password-less,
using the /var/run/cups/certs/0 file that they can
Control: forwarded -1 https://www.cups.org/str.php?L4223
Le samedi, 10 novembre 2012 12.48:39, Didier 'OdyX' Raboud a écrit :
* Report bug to upstream tracker (I'll do it)
This has now been done, to STR #4223, currently hidden from public view as it
is tagged as security.
Cheers,
OdyX
Didier 'OdyX' Raboud [2012-11-10 12:48 +0100]:
* Have cupsd run as lp user
We had done that in Debian for several years for security reasons. We
had a huge patch to make most of cups work as user lp, but at some
point I gave up: it caused too many bugs, didn't work with a lot of
third-party
Control: found -1 1.4.4-7+squeeze1
On 11/10/2012 06:48 AM, Didier 'OdyX' Raboud wrote:
I have successfully used your exploit script on the Sid version, tagging as
found there.
Just to complete the picture, I tried the exploit on squeeze, and it
works there too.
--
To UNSUBSCRIBE, email to
[Re-adding security team to CC.]
On 11/10/2012 07:44 AM, Martin Pitt wrote:
Didier 'OdyX' Raboud [2012-11-10 12:48 +0100]:
* Have cupsd run as lp user
We had done that in Debian for several years for security reasons. We
had a huge patch to make most of cups work as user lp, but at some
Package: cups
Version: 1.4.4-7+squeeze1
Severity: critical
Tags: security
Justification: root security hole
Members of lpadmin cat read /var/run/cups/certs/0. With this key it is possible
to access the cups web interface as admin. You can edit the cups config file
and set the page log to any
A line break got inserted into the script while posting. Here is the
correct one.
--
Mit freundlichen Grüßen,
Jörg Ludwig
IServ GmbH
Rebenring 33
38106 Braunschweig
Telefon: 0531-3804450
Fax: 0531-4287745
Mobil: 0179-9101055
E-Mail: joerg.lud...@iserv.eu
Internet:
19 matches
Mail list logo
