[prev in list] [next in list] [prev in thread] [next in thread]
List: oss-security
Subject: [oss-security] Re: Linux peer_cred Mischmasch
From: Andy Lutomirski <luto () amacapital ! net>
Date: 2014-07-24 18:14:49
Message-ID: 53D14D19.1060603 () amacapital ! net
[Download RAW message or body]
On 07/22/2014 11:43 PM, Sebastian Krahmer wrote:
> 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:)
SO_PEERCRED is at least less bad: you'd need to convince someone to call
socket(2) (or maybe connect(2)) on your behalf, which is hopefully much
harder than getting them to call write(2) on your behalf.
I still don't like it, but that ship sailed a long, long time ago.
>
> Sebastian
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic