This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Fri, Jul 17, 2015 at 07:28:45AM +0200, Florian Weimer wrote:
> On 07/16/2015 10:00 AM, Siddhesh Poyarekar wrote:
> > Some valid ELF objects, like .debug files may refer to sections
> > outside themselves since they're loaded and patched up to their parent
> > ELF.  Calling ldd on them may result in a segfault since it may try to
> > read beyond the end of the mapping.  Red Hat bz:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=741105
> > 
> > has an example, although I haven't been able to find a sample
> > reproducer file immediately.  This patch has been carried in Fedora
> > and RHEL for a couple of years now.  Also tested on x86_64 to verify
> > that there are no regressions.
> 
> Can you show the ldd output with this patch applied on some files which
> crashed before?  Is it useful at all?
> 
> I know that debuginfo files usually have garbage interpreter fields, so
> I really doubt that ldd can produce anything useful on debuginfo files.
> 
> +	      errstring = N_("ELF load command past end of file");
> 
> The expectation appears to be that end users see this error message.  It
> needs to better reflect what's going on.
> 
> Is there a way that an ELF file is corrupted in this way, but can be
> still be loaded correctly?  I wonder if this change will break currently
> working programs.  I do think we need to support loading corrupted ELF
> files indefinitely if there ever was a binutils version producing them.
>
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. 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]