Re: Introducing security hardening features for Lenny
On Tuesday 29 January 2008, Moritz Muehlenhoff wrote:
> The Debian archive is the biggest of all distributions and although
> there's security support for all security issues being found, there's
> still room for improvement and a need for increased resilience against
> flaws not yet discovered.
>
> A group of people have been working on introducing advanced security
> hardening features into our archive:
> http://alioth.debian.org/projects/hardening/
>
> We recommend to activate the following features in individual packages
> for now and discuss how to enable them system-wide later. (Matthias
> Klose proposed a mechanism in debian-devel, which could be used for
> it: http://lists.debian.org/debian-devel/2007/12/msg00090.html).
>
> Some maintainers have already pro-actively enabled these features,
> e.g. in the sendmail and openssh packages, but we're heading for
> full archive coverage now.
>
>
> There are two general classes of enhancements we'd like to apply to
> Debian:
>
> 1. Tool chain features preventing the exploitation of some
> vulnerability classes
>
> Stack protector
> ===============
>
> For a general introduction please see Wikipedia:
> http://en.wikipedia.org/wiki/Stack-smashing_protection
>
> This is relatively straight-forward. While it only addresses classic
> stack buffer overflows, we still have a lot of poorly-reviewed
> special case legacy code in our archive, so this will still be useful
> in practice.
>
> It's included in stock GCC since 4.1 onwards, so people would only
> need to add the compile flags to their packages.
>
> If there are packages which don't work with stack protection, it
> can be overridden with a compile flag. (We would need a lintian
> test to catch these, so that maintainers rather fix bugs in their
> packages than circumventing it with disabling SSP.)
>
> To enable, make sure that "-fstack-protector" ends up in the compiler
> flags.
>
>
> Fortify Source
> ==============
>
> This feature adds validation for internal C functions such as strcpy
> for buffer sizes known during compile time. While vulnerabilities in
> the functions it protects have become uncommon in high-profile apps,
> it will be useful for fringe packages we have in the archive.
>
> This feature is present in glibc since version 2.5, and is enabled
> through the use of "-D_FORTIFY_SOURCE=2" and "-O2" or higher.
>
> Format warnings
> ===============
>
> For a general introduction please see Wikipedia:
> http://en.wikipedia.org/wiki/Format_string_attack
>
> This feature adds a higher level of warning reporting for functions using
> format strings. To enable, add "-Wformat" and "-Wformat-security" flags,
> and pay attention to compile-time warnings.
>
>
>
> 2. Tool chain features enhancing the effectiveness of Address Space
> Layout Randomization, which raises the bar for successful exploitation
> of vulnerabilities.
>
> For a general introduction please see Wikipedia:
> http://en.wikipedia.org/wiki/Address_space_layout_randomization
>
> relro
> =====
>
> This feature marks certain sections of the executable memory space
> read-only after the linker has finished its work. It serves as a
> measure against GOT overwrites, which can make exploits more difficult.
>
> This is enabled via "-Wl,zrelro".
>
>
> Position Independent Executables
> ================================
>
> Currently, modern kernels randomize the location of mmap and stack
> allocation, but the text segment (and subsequent brk memory) is always
> in the same place. In kernels that support text ASLR, programs compiled
> for PIE will gain full position randomization. This has some known
> problems on our more exotic archs, specifically hppa and m68k. These
> tool chains should be patched, so that enabling PIE is a NOP instead of
> forcing every maintainer to jump through hoops.
>
> The flag -fPIE is very similar to -fPIC, but it applies to objects linked
> to form the final executable binary. PIE is enabled by passing "-fPIE" to
> all object builds, and passing "-pie" to the final link.
>
>
> Experimental wrapper package
> ============================
>
> An experimental wrapper has been written, which is available in unstable:
> http://packages.qa.debian.org/h/hardening-wrapper.html
> It contains basic usage information.
>
> You can use it to test compilation w/o much overhead. Lucas Nussbaum made
> a complete archive rebuild and about 700 packages failed to build, mostly
> due to problems with PIE:
> http://people.debian.org/~lucas/logs/2007/11/26.hardening/00lists/
>
> Once you've verified that your package builds and runs correctly, you
> should add the necessary compiler/linker flags to your package's build
> system.
>
> Once a distribution-wide way to add these flags is defined, you can switch
> your package to it.
>
>
>
> Scope of this proposal
> ======================
>
> The target for Lenny is to enable these features in all applications
> with potential security impact, specifically:
>
> - Your application is written in C / C++
> - If your package was subject to a DSA in the recent years
> - If your package parses files from untrusted sources
> - If your package communicates over a network
>
> For some known flaky packages bugs will be filed.
>
> Please be proactive with this.
>
> If you file a bugreport requesting hardening features, please use the
> usertag "hardening" for the user debian-security@lists.debian.org. If
> you have a question wrt to fixing your package to enable hardening
> features, please ask in debian-devel@lists.debian.org and add
> missing information to the Wiki page available at
> http://wiki.debian.org/Hardening
>
> We'll probably need lintian tests to catch packages not enabling these
> features at a later point.
>
> Documentation
> =============
>
> Initial documentation is available at http://wiki.debian.org/Hardening
>
> Discussion surrounding these hardening features can be seen on the list:
> http://lists.alioth.debian.org/mailman/listinfo/hardening-discuss
> (Initial discussion was mostly done in non-archived mail communication,
> though)
>
> Please add what you miss (especially if you are a porter documenting
> arch-specific failure).
>
> On behalf of the debian-hardening project (Kees, Marcus, Russell, Steve,
> Tim and myself): Happy hacking.
The wrapper should be very useful, even for non-security problems. It will
tell you the cause of several ubitquitous segfaults, thus making it easier to
fix them. Good news :-)
Reply to: