Bug#656656: Please enabled hardened build flags

[Moritz Muehlenhoff]

On Thu, Jan 26, 2012 at 02:23:14PM -0800, Russ Allbery wrote:
> Moritz Muehlenhoff <jmm at 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 at GLIBC_2.2.5 (6)
    50: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND memset at GLIBC_2.2.5 (6)
   212: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND memcpy at GLIBC_2.2.5 (6)
 
It should rather use the fortified counter parts, e.g. __memcpy_chk at GLIBC_2.3.4 

Cheers,
        Moritz