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 [EMAIL PROTECTED] 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 :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
