Proposing amd64-hardened architecture for Debian

Facing last week’s Heartbleed bug the need for improving the security of our systems became more apparent than usually. In Debian there are widely used methods for Hardening packages at build time and guidelines for improving the default installations’ security.

Employing such methods usually come at an expense, for example slower code execution of binaries due to additional checks or additional configuration steps when setting up a system. Balancing between usability and security Debian chose an approach which would satisfy the most users by using C/C++ features which only slightly decrease execution speed of built binaries and by using reasonable defaults in package installations.

All the architectures supported by  Debian aims using the same methods for enhancing security but it does not have to stay the same way. Amd64 is the most widely used architecture of Debian according to popcon and amd64 hardware comes with powerful CPU-s. I think there would be a significant amount of people (being one of them :-)) who would happily use a version of Debian with more security features enabled by default sacrificing some CPU power and installing and setting up additional packages.

My proposal for serving those security-focused users is introducing a new architecture targeting amd64 hardware, but with more security related C/C++ features turned on for every package (currently hardening has to be enabled by the maintainers in some way) through compiler flags as a start.

Introducing the new architecture would also let package maintainers enabling additional dependencies and build rules selectively for the new architecture improving the security further. On the users’ side the advantage of having a separate security enhanced architecture instead of a Debian derivative is the potential of installing a set of security enhanced packages using multiarch. You could have a fast amd64 installation as a base and run Apache or any other sensitive server from the amd64-hardened packages!

I have sent the proposal for discussion to debian-dev, too. Please join the discussion there or leave a comment here.

Update: Many of you wondered if amd64-hardened could have prevented the exploitation of the Heartbleed vulnerability. I have posted a proof of concept to show that using -fsanitize=address and disabling custom freelist would have protected systems against stealing data using the exploits.

Disabling the custom freelist-like solutions and enabling-fsanitize=address would be part of amd64-hardened to make memory protection techniques work effectively thus I think if we had this architecture ready at the beginning of April, it would have been immune to Heartbleed.

5 thoughts on “Proposing amd64-hardened architecture for Debian

  1. Jonathan

    Which hardening flags would have stopped heartbleed? Which flags do you propose are applied to this new arch, which are rejected for “pure” amd64? What impact do you expect those flags to make in practise, performance-wise?

    Reply
    1. Réczey Bálint Post author

      I don’t know about any flags which would have stopped Heartbleed, but there are some which would make attacking systems harder.
      One flag which is not being used is -fsanitize=address against exploiting memory related bugs because it causes 2x slowdown typically.

      Reply
  2. Anonymous Java Developer

    I think the Heartbleed bug is a symptom of bad software quality and bad software testing. Many free software packages, especially smaller ones, are not well tested. You’re lucky if the software comes with some unit tests. Ideally, the software should have both unit tests and higher-level tests (integration, system, acceptance – depending on your terminology) that can be run at every build.

    On the distribution side of things, my suggestion would be to apply static analysis tools on the source code of relevant packages and work with the upstreams to fix the revealed bugs. This has the advantage of helping derivatives and users on other architectures. Not sure how the situation in the C and C++ world is, but there are good quality free software tools available for Java (e.g. FindBugs) that can reveal both performance problems and hard-to-find bugs.

    Reply
    1. Réczey Bálint Post author

      We are working both on improving testing http://ci.debian.net/ and towards running static analysis by rebuilding the archive using Clang http://clang.debian.net/ which would allow running Clang based static analyzers, but static analysis can’t fully replace run-time checks yet.

      The realistic mid-term goal for Debian is keeping the archive in a good shape enabling full rebuilds and accepting and tracking static/dynamic analysis results from external sources like it happened when ForAllSecure filed ~5000 bugs based on their analysis: http://forallsecure.com/mayhem.html

      Reply
  3. Pingback: Progress report on hardened1-linux-amd64, a potential Debian port with PIE, ASAN, UBSAN and more | Obsessed with reality

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.