Re: [PATCH] Avoid mapping past end of shared object (BZ #18685)

["Carlos O'Donell" <carlos at redhat dot com>]

On 07/16/2015 10:55 PM, Mike Frysinger wrote:
> On 16 Jul 2015 22:45, Carlos O'Donell wrote:
>> On 07/16/2015 10:08 PM, Mike Frysinger wrote:
>>> On 16 Jul 2015 13:17, Carlos O'Donell wrote:
>>>> On 07/16/2015 12:36 PM, Andreas Schwab wrote:
>>>>> Perhaps ldd should use a specially compiled ld.so that has a lot of
>>>>> extra checks added (so that it can be run on arbitrary objects without
>>>>> creating security hazards).
>>>>
>>>> ldd should be a distinct tool that uses libelf, and provides deeper
>>>> introspection and options. This way we have a second implementation
>>>> of the loader rules in a cleaner and concise form that we can use
>>>> to double-check assertions about load order and cycle breakage,
>>>> and cross-check ld.so changes.
>>>
>>> i agree in having a dedicated/robust tool, but i don't think it means we should 
>>> disable the trace option in the ldso itself.  having a way to get the actual 
>>> details out of the ldso i think is still valuable.
>>
>> Agreed. We need trace to do comparison between eu-ldd and ld.so.
>> We need trace for developers and for runtime dumps which include
>> looking at dlopen/dlmopen calls. We need more trace data to look
>> at namespaces for dlmopen.
>>
>> Making this trace robust against corrupt binaries is a questionable
>> endeavor though?
> 
> i think we need to clarify the goals before we dive into technical details.
> how about:
>   running `ldd <foo>` should be safe (i.e. not crash or be a security hazard)
> 
> if we can all agree on that, then a lot of things shake out from there.

Running `ldd <foo>` should be safe and free of security hazards at a distro
level, but that `ldd` *should* be eu-ldd and based on a hardened and fuzzed
libelf. It should leverage the work we are doing to harden libelf. Hardening
the real loader to serve as an alternate tool is against the "do one thing well"
philosophy. We will always have conflicting goals if we want ld.so to be both
a hardened introspection tool and a fast and performant loader.

Running the result of `elf/ldd.bash.in` (invoking the real loader) should run
the real loader in trace mode. The real loader should rarely compromise to being
slower because it's in trace mode. It should IMO not unduly compromise performance
for hardening against problems which are the result of other failures in the
system e.g. storage, memory, kernel, etc. Where possible some hardening is good
given clearly stated rationale for the change e.g. a real security threat.

In this particular case, hardening against stripped debug data, is the wrong
solution. The debug data must be clearly marked as such since it's actually
not real DSOs or executables, and we've cheated by using objcopy to get something
that looks like a valid ELF file but isn't anymore. We need to stop being sloppy
about how we label that kind of object.

Is that clear enough?

I want to avoid a blanket statement. In this case I think the hardening rational,
that of supporting debug files, is not worth the change in the code.

Cheers,
Carlos.