Re: ldd not working on ET_EXEC executables

[Rich Felker <dalias@libc.org>]

On Thu, Dec 08, 2016 at 04:30:42PM -0600, Laine Gholson wrote:
> You mean RANDMMAP? PaX's RANDMMAP feature ignoring the address your requesting it (without MAP_FIXED) is perfectly valid, to quote POSIX:
> "When MAP_FIXED is not set, the implementation uses addr in an implementation-defined manner to arrive at pa."
> mmap2(0x10000, 73728, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x1234abcd

It's _valid_, but it's a bad implementation choice; it makes it
impossible to request a particular range, which is necessary for
ldso/ldd to load non-PIE programs.

> You're not passing MAP_FIXED to mmap() but are expecting the kernel to still use the address you're giving it, which is wrong.
> (as a side note, glibc works and it uses MAP_FIXED)

This is invalid, and a bug in glibc, as there's no way to know that
you're not mapping over something that's already there (perhaps even
the function that's calling mmap). You can only use MAP_FIXED to map
over top of an existing mapping you already know about and intend to
replace (same with dup2 and file descriptors), not an arbitrary
address range.

Rich


> Thanks,
> 
> Laine Gholson
> 
> On 12/05/16 20:33, Rich Felker wrote:
> >On Mon, Dec 05, 2016 at 07:39:32PM -0600, Laine Gholson wrote:
> >>Hello,
> >>
> >>I am running musl on a ARM platform, and ldd won't work on a executable with the ET_EXEC type.
> >>
> >>running GNU ld 2.25.1, gcc 6.2.0, and musl 1.1.15-git-71-g54991729
> >>
> >> $ gcc -fPIE -pie test.c -o test-pie
> >> $ ldd test-pie
> >><no error>
> >> $ gcc -fno-PIE -no-pie test.c -o test-nopie
> >> $ ldd test-nopie
> >>ldd: test-nopie: Not a valid dynamic program
> >> $ elfedit --output-type DYN test-nopie
> >> $ ldd test-nopie
> >><no error>
> >>
> >>Any idea why ldd says executables with the ET_EXEC type aren't valid?
> >
> >strace it; I suspect you'll find that mmap is not honoring the
> >requested address. This is a bug introduced intentionally by grsec/pax
> >and perhaps other hardened kernels.
> >
> >Rich
> >