On Thu, Jan 26, 2012 at 02:23:14PM -0800, Russ Allbery wrote:
> Moritz Muehlenhoff <j...@debian.org> writes:
>
> > Please enabled hardened build flags through dpkg-buildflags.
>
> > I've attached a partial patch. It enables a protected stack and
> > read-only relocs.
>
> > Fortified source functions are not properly enabled. I haven't debugged
> > this further, but it seems as if CPPFLAGS (-D_FORTIFY_SOURCE=2) isn't
> > properly propagated in the upstream build system. You might want to take
> > this upstream or clone the bug.
>
> I took a look at the latter part of this, and so far as I can tell,
> CPPFLAGS are properly propagated. I see the -D appearing on all the
> compilation lines correctly, but hardening-check doesn't see the effects.
>
> I did notice that libxmltooling-lite, which is the same code built to
> disable some features, shows up in hardening-check with:
>
> Fortify Source functions: unknown, no protectable libc functions used
>
> I'm wondering if possibly libxmltooling just has so few protectable
> functions that the few that it has aren't eligible for some reason.
>
> But so far as I can tell, upstream isn't doing anything wrong here, and
> the issue is something else: either there's some sort of problem with how
> the compiler and library implement this that causes it to miss this code
> base, or the functinos aren't eligible.
It appears to be an issue in the xmltooling build system:
$ readelf -sW /usr/lib/x86_64-linux-gnu/libxmltooling-lite.so.5.0.2 | grep
'mem[cpy|set]'
45: 0000000000000000 0 FUNC GLOBAL DEFAULT UND memcmp@GLIBC_2.2.5
(6)
50: 0000000000000000 0 FUNC GLOBAL DEFAULT UND memset@GLIBC_2.2.5
(6)
212: 0000000000000000 0 FUNC GLOBAL DEFAULT UND memcpy@GLIBC_2.2.5
(6)
It should rather use the fortified counter parts, e.g. __memcpy_chk@GLIBC_2.3.4
Cheers,
Moritz
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
