This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Avoid mapping past end of shared object (BZ #18685)
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, libc-alpha at sourceware dot org, roland at hack dot frob dot com
- Date: Fri, 17 Jul 2015 09:35:16 +0200
- Subject: Re: [PATCH] Avoid mapping past end of shared object (BZ #18685)
- Authentication-results: sourceware.org; auth=none
- References: <1437033625-13561-1-git-send-email-siddhesh at redhat dot com> <55A8928D dot 2090409 at redhat dot com>
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.