Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 23 Jul 2014 08:43:25 +0200
From: Sebastian Krahmer <>
Subject: Re: Re: Linux peer_cred Mischmasch

On Tue, Jul 22, 2014 at 12:22:30PM -0700, Andy Lutomirski wrote:
> On 07/22/2014 04:17 AM, Florian Weimer wrote:
> > On 07/22/2014 12:15 PM, Sebastian Krahmer wrote:
> >> While maybe_add_creds() (via SOCK_PASSCRED) and scm_send()
> >> (via unix_{stream,dgram}_sendmsg()) use the real UID,
> >>
> >> cred_to_ucred() (via SO_PEERCRED) passes the EUID (this time
> >> also kuid_munged()).
> > 
> > There should also be a discrepancy regarding when the credentials are
> > captured (time of send for SOCK_PASSCRED, time of socket creation for
> > SO_PEERCRED).  The latter is required because privileged processes
> > assume that they can safely write to stderr, so picking the current
> > process credentials may well introduce vulnerabilities.

It does, and that should be ok.

> > 
> Indeed.  IMO both of these interfaces are flawed, but PASSCRED is
> terminally broken and should never be used.  See, for example,
> CVE-2013-1979, which is the immediate cause of the ruid thing.

Thats what I was wondering whether CVE-2013-1979 only fixed SCM_CREDENTIALS
case and missed to fix SO_PEERCRED.
I am not fully convinced thats OK to get one time the euid and another time
the uid (even though I liked the spy example:)



~ perl
~ $_='print"\$_=\47$_\47;eval"';eval
~ - SuSE Security Team

Powered by blists - more mailing lists

Your e-mail address:

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

Powered by Openwall GNU/*/Linux - Powered by OpenVZ