[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Introducing the hardening-wrapper package (was: Exim4 problems)



Hallo!

On Tue, 17 May 2011 11:31:37 +0200, Svante Signell <srs@kth.se> wrote:
> Further info. I think the problem is with gcc-4.6 mis-compiling.

Well, that's not quite right.  But it's not very wrong either...

> (Another issue is the memora acces problems in gdb: bothe present with
> gcc-4.4 and gcc-4.6).
> 
> Building exim-4.75-3 with gcc-4.6 -O2 results in a segfault:
> (even though the packages are successfully built: debian/minimaltest
> script is only present in 4.76-1)
> 
> gdb build-tree/build-exim4-daemon-{light,heavy}/exim
> 
> (gdb) run
> Starting program: exim4-4.75/build-tree/build-exim4-daemon-light/exim 
> Cannot access memory at address 0x726f2030
> Cannot access memory at address 0x726f2030
> [...]

I can reproduce all of this.  The ``problem'':

    $ grep HARDENING debian/rules 
    export DEB_BUILD_HARDENING=1
    #export DEB_BUILD_HARDENING_FORTIFY=0

This has, according to debian/changelog, recently been enabled.  I took
notice of this package when I ran ``apt-get build-dep exim4'' this
afternoon.

    $ apt-cache show hardening-wrapper
    Package: hardening-wrapper
    Version: 1.32
    Installed-Size: 116
    Maintainer: Package Hardening <hardening-discuss@lists.alioth.debian.org>
    Architecture: hurd-i386
    Depends: gcc | g++, perl
    Description: Compiler wrapper to enable security hardening flags
     Replaces gcc, g++, and ld with wrapper scripts that set security
     hardening
     compilation flags, as an alternative to changing gcc specs.  Enabled
     when
     DEB_BUILD_HARDENING=1 is set.
    Homepage: http://wiki.debian.org/Hardening
    [...]

Apparently there's something going very wrong for us, for some of the
hardening flags, such that GDB gets confused, SEGFAULTs arise, and all
what we've seen.  Svante, sorry, I really didn't expect something like
that...  (Welcome to the wonderful world of debugging.)  The reason I
don't know yet.  Perhaps some GCC specs oddity.  Or something in glibc/in
the dynamic linker.

Change that flag to DEB_BUILD_HARDENING=0, and exim4's mini-testsuite
will pass.

I can also tell you why the build didn't SEGFAULT on the Debian buildd:
the testsuite is only run if the Debian-exim user exists (in
/etc/passwd), and that one only exists if the exim4-config package is
installed -- which it probably isn't on the buildd.

Next step, I: Upload a thusly-fixed exim4 to debian-ports?  (So that the
Debian Installer is usable again.)

Next step, II: Figure out what's going wrong.  Svante, interested?  I
would begin as follows.

Figure out which hardening flag is the culprit.  For this, leave
DEB_BUILD_HARDENING_FORTIFY=1 set, but disable individual flags until it
succeeds.  /usr/bin/hardened-cc defines the following defaults:

    DEB_BUILD_HARDENING_STACKPROTECTOR=1
    DEB_BUILD_HARDENING_FORTIFY=1
    DEB_BUILD_HARDENING_FORMAT=1
    DEB_BUILD_HARDENING_PIE=1

You can override these by putting [...]=0 into debian/rules.

The Stack Protector should be fine.  Fortifying I don't know.  Format I'd
expect to be OK.  PIE I don't know -- has this ever been tested for
anything?  This testing is easily done with our friend exim4.

In parallel, you could test this with some tiny test program that is more
quickly built than exim4: a C file with a main function that calls, for
example, stat on some file (see ``man 2 stat'' for an example).  Build it
like this:

    $ DEB_BUILD_HARDENING=1 gcc -Wall -g -O2 -o hardened file.c
    $ ./hardened [...]

This one should SEGFAULT.  If not, you need another test program.

    $ gcc -Wall -g -O2 -o normal file.c
    $ ./normal [...]

This one should work fine.

    $ DEB_BUILD_HARDENING=1 DEB_BUILD_HARDENING_PIE=0 gcc -Wall -g -O2 -o hardened-no-PIE file.c
    $ ./hardened-no-PIE [...]

This one we don't know.  Try to figure out if there's a single
DEB_BUILD_HARDENING_* flag that toggles the behavior.

With the same method you can try to figure out which flag it is that
confuses GDB.  Might be the same one that triggers the SEGFAULT, might be
something else.


Grüße,
 Thomas

Attachment: pgpdj_6dp1i6Z.pgp
Description: PGP signature


Reply to: