[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20120102181157.GA24173@openwall.com>
Date: Mon, 2 Jan 2012 22:11:57 +0400
From: Solar Designer <solar@...nwall.com>
To: Oswald Buddenhagen <ossi@....org>
Cc: Jeff Mitchell <mitchell@....org>, oss-security@...ts.openwall.com,
cve@...re.org
Subject: Re: Disputing CVE-2011-4122
On Mon, Jan 02, 2012 at 01:15:23PM +0100, Oswald Buddenhagen wrote:
> On Wed, Dec 28, 2011 at 03:25:09AM +0400, Solar Designer wrote:
> > ... is it valid and not a vulnerability when installing a package
> > (containing kcheckpass) unexpectedly (for a sysadmin) lets any user on
> > the system invoke any of the configured PAM stacks, some of which may
> > have side-effects?
>
> i pondered this possibility when i initially added the override
> parameter to kcheckpass, but i couldn't come up with anything usefully
> exploitable - it would have to be some right which is granted to the
> user *only* by this particular service - but not full logins.
The side-effects don't necessarily have to involve a right being granted
to the user. They may be, for example, connections made to external
authentication servers (increasing load on those, etc.), log file
records being made, notifications being sent to external servers or to
sysadmins, a resource being consumed (e.g., successful authentication
for a certain heavy service may count towards a configured maximum
number of concurrent uses). Then, a certain PAM module may trust, say,
an environment variable assuming that the corresponding PAM stacks are
never used from SUID/SGID programs - an assumption that you break.
> this seems
> a bit far-fetched. so while you have a valid point in principle,
Yes, a bit far-fetched. Yet for an upstream piece of software, you have
to consider issues like that.
> it doesn't seem particularly relevant for desktop systems.
Just because a piece of software is intended for desktop systems doesn't
mean it will only be installed on such. It is not too uncommon to have
extra/unneeded packages installed on servers. This indicates a sloppy
sysadmin practice, yet as an upstream author you need to ensure that
your own software doesn't make things worse if installed on a server.
Also, some servers actually have GUI desktops as well on purpose (e.g.,
to accommodate GUI installers and configuration tools of applications
that are actually needed on the server).
> fwiw, linux-pam's pam_unix has an own setuid helper for shadow pw
> verification for some time now. most services don't actually need root
> for authentication at all. consequently, it is usually not useful to
> install kcheckpass setuid root at all, which makes this whole discussion
> somewhat irrelevant in the first place (except that the upstream
> makefiles will still try to install with setuid root).
Yes, but this exception you mention (the upstream Makefiles installing
the program SUID root) is a sufficient reason to have this discussion.
Thanks,
Alexander
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.
