[PATCH] elf: fix maplength computation when loading a library

[Florian Weimer]

* Riccardo Schirone:

> glibc assumes loadable segment entries (PT_LOAD) in the program header
> table appear in ascending order, sorted on the p_vaddr member.

This order is required by the ELF specification.

| PT_LOAD
|
| […] Loadable segment entries in the program header table appear in
| ascending order, sorted on the p_vaddr member.

<http://www.sco.com/developers/gabi/latest/ch5.pheader.html>

In the past, our position was that ld.so does not have to react in
well-defined ways to invalid ELF binaries.

> An attacker could still try to overwrite existing libraries by using
> an executable with loadable segments with fixed addresses, however this
> would be much harder as ASLR should make existing libraries' position
> random enough.

I'm not sure about that.  It's true that you need to map 1 TiB of data
to get reliable execution.  But I expect you can use alias mappings to
achieve that with a reasonable file size.  On x86-64, even null bytes
(without file backing) will likely work because they are interpreted as

  add %al, (%rax)

And %rax is the start of the mapping when the mmap system call returns.
If the attacker has placed the actual shell code via another PT_LOAD
segment at a high address, execution will eventually reach it (maybe
after a couple of minutes, admittedly, but the alias mapping approch can
avoid this).

So I would say that your patch does not actually fix the bug. 8-(

I think the more reliable fix would be to check in
elf/dl-map-segments.h:_dl_map_segments that the load commands do not
overlap the dynamic linker itself.  That would also produce nicer ldd
errors in case an ET_EXEC executable maps over the dynamic loader by
accident (bug 20857).

Thanks,
Florian