[SSSD] [PATCH] Properly null-terminate socket path
Dmitri Pal
dpal at redhat.com
Mon Jun 14 15:00:45 UTC 2010
Stephen Gallagher wrote:
> On 06/14/2010 10:48 AM, Dmitri Pal wrote:
>
>> Jakub Hrozek wrote:
>>
>>> On 06/14/2010 04:13 PM, Stephen Gallagher wrote:
>>>
>>>> On 06/14/2010 10:10 AM, Stephen Gallagher wrote:
>>>>
>>>>> https://fedorahosted.org/sssd/ticket/540
>>>>>
>>>>> It was unlikely, but if the path to the socket file exceeded 108
>>>>> characters, this strncpy would be unterminated and the results could be
>>>>> unexpected. This was not an exploitable vulnerability.
>>>>>
>>>>>
>>>> I forgot to mention, this patch should apply to both master and
>>>>
>>> sssd-1-2.
>>>
>>>
>>> ACK
>>>
>> I am not sure... From man page:
>>
>> sun_family always contains AF_UNIX. sun_path contains the
>> zero-terminated pathname of the
>> socket in the file system. If sun_path starts with a null byte (’’ ’),
>> then it refers to the
>> abstract namespace maintained by the Unix protocol module. The socket’s
>> address in this
>> namespace is given by the rest of the bytes in sun_path. Note that names
>> in the abstract
>> namespace are not zero-terminated.
>>
>> So the right approach would probably be memcpy of the sizeof rather than
>> strncpy.
>> It really depends whether we trust the claim above that it is NULL
>> terminated and we can guarantee that we are not going to ever get
>> addresses in the abstract namespace.
>>
>>
>
> I'm not sure where you're going with this. We're strncpy()ing FROM
> rctx->sock_name (which we ourselves construct and can guarantee is
> null-terminated) into addr.sun_path. What we're doing here is making
> sure that if rctx->sock_name exceeds the size of addr.sun_path, then we
> ensure that it is null-terminated.
>
> We're guaranteed that the first byte of addr.sun_path will never be NULL
> here, so there's no concern about the abstract namespace.
>
>
If we are do it ourselves. I guess it is Ok.
--
Thank you,
Dmitri Pal
Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
More information about the sssd-devel
mailing list