This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] CVE-2019-1010023: add check for load commands mapping [#22851]
- From: Florian Weimer <fweimer at redhat dot com>
- To: Zhipeng Xie <xiezhipeng1 at huawei dot com>
- Cc: <rschiron at redhat dot com>, <libc-alpha at sourceware dot org>, <lvying6 at huawei dot com>, <joseph at codesourcery dot com>, <roland at hack dot frob dot com>
- Date: Tue, 11 Feb 2020 15:32:02 +0100
- Subject: Re: [PATCH] CVE-2019-1010023: add check for load commands mapping [#22851]
- References: <20200206144055.16981-1-xiezhipeng1@huawei.com>
* Zhipeng Xie:
> Glibc assume the following constraint in 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
>
> Some check needed to fix vulnerability in load commands mapping
> reported by
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=22851
Sorry, I don't think this fixes the issue because even with increasing,
non-overlapping load segments, a crafted binary can eventually map over
the dynamic loader, as explained here:
<https://www.sourceware.org/ml/libc-alpha/2019-12/msg00634.html>
I failed to consider in that post that we also need to protect the
dynamic loader heap, which is not reflected in the load segments of the
dynamic loader.
We could use MAP_FIXED_NOREPLACE in ldd mode if the kernel supports it.
Or it's possible that in ldd mode, we can completely drop MAP_FIXED
without ill effects because we do not depend on absolute addresses
anywhere (but that would need some experimentation).
Using MAP_FIXED_NOREPLACE in general is problematic because there might
be legacy binaries with overlapping load segments which will no longer
load afterwards.
Thanks,
Florian