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

[OndÅej BÃlka <neleai at seznam dot cz>]

On Fri, Jul 17, 2015 at 09:43:29AM +0200, Florian Weimer wrote:
> On 07/17/2015 09:35 AM, OndÅej BÃlka wrote:
> 
> > Also could you explain how this is security risk? If that needs
> > modification of elf then attacker could run arbitrary commands by
> > overriding main for example.
> 
> Just because I comment on a thread doesn't mean I consider it
> security-related.
> 
> Or what do you mean?
> 
Well here I did bit distracted in reading thread, starting reply, then
writing what I wanted to ask to wrong post. I wanted to reply instead to
what Carlos wrote:

"
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?
"