Tag Archives: security

Hardening Debian Stretch with PIE is ready but bindnow will be missing

pie-bindnow-notnow-debianHardening all executables by making them position independent by default is basically ready with a few packages to fix (bugs). On the other hand bindnow is not enabled globally (#835146) and it seems it will not be for the next stable release despite my plan :-(.

If you are a maintainer you can still have your packages hardened in Stretch by enabling bindnow per package before 25 January, 2017. It could be a nice present for your users!

update: It is nice to see how enabling PIE in GCC increased PIE coverage while bindnow coverage is improving slowly with maintainers enabling it package by package:


From https://lintian.debian.org/tags/hardening-no-pie.html


From: https://lintian.debian.org/tags/hardening-no-bindnow.html

update 2: Changed the deadline of enabling bindnow per package to align with the start of the full freeze, not the soft freeze.


Harden Debian with PIE and bindnow!

pie-bindnow-debian Shipping Position Independent Executables and using read-only Global Offset Table was already possible for packages but needed package maintainers to opt-in for each package (see Hardening wiki) using the “pie” and “bindnow” Dpkg hardening flags.

Many critical packages enabled the extra flags but there are still way more left out according to Lintian hardening-no-bindnow and hardening-no-pie warnings.

Now we can change that. We can make those hardening flags the default for every package.
We already have the needed patches for GCC (#835148) and dpkg (#835146, #835149). We already have all packages rebuilt once to test which breaks (Thanks to Lucas Nussbaum!). The Release Team already asked porters if they feel their ports ready for enabling PIE and most ports tentatively opted-in (Thanks to Niels Thykier for pushing this!).

What is left is fixing the ~75 open bugs found during the test rebuilds and this is where You can help, too! Please check if your packages are affected or give a helping hand to other maintainers who need it. (See PIEByDefaultTransition wiki for hints on fixing the bugs.) Many thanks to those who already fixed their packages!

If we can get past those last bugs we can enable those badly needed security features and make Stretch the most secure release ever!

Progress report on hardened1-linux-amd64, a potential Debian port with PIE, ASAN, UBSAN and more

It was more that one and a half years ago when I proposed creating a new security &QA focused port for Debian and now I’m happy to share the first bits of it.

Last year I started the bootstrapping during the holidays and I now have the prototype in the form of cross built packages which can be installed next to amd64 packages using multiarch.

The aim of creating the port is still the same, letting people mix fast (amd64) and reasonably hardened (hardened1-linux-amd64) packages on the same system. (Only for QA purposes for now, see update 3.)

You can already try the cross-built packages in an amd64 unstable chroot, but be warned that the packages are not stable yet.

In the following session I tested curl which seems to be working OK, and groff, which seems to be too buggy even for debugging:

debootstrap --arch=amd64 unstable test-hardened1
# mount /proc for ASAN
mount --bind /proc test-hardened1/proc
chroot test-hardened1/
apt-get install debian-keyring
# this is my key, I'll create one dedicated release key later
gpg --keyring /usr/share/keyrings/debian-keyring.gpg -a --export 0x21E764DF | apt-key add -
echo "deb http://hardened1-debian.s3.amazonaws.com/debian-cross-built hardened1-unstable main" >> \
apt-get update
# update apt and dpkg to versions handling the new port
apt-get upgrade
apt-get update
dpkg --add-architecture hardened1-linux-amd64
apt-get update
apt-get install curl:hardened1-linux-amd64
curl -s https://www.debian.org | tail -n2
apt-get install -t hardened1-unstable groff:hardened1-linux-amd64
==20642==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f79cd84698a bp 0x619000006980 sp 0x7ffe89b3a930 T0)
==20642==AddressSanitizer: while reporting a bug found another one. Ignoring.

The next steps are finalizing the changes to apt, dpkg, GCC, glibc and other packages,  rebuilding all packages in hardened1-linux-amd64 sbuild chroots and building the rest of the archive.
Some of the patches are not submitted yet but they are available in a temporary fork of rebootstrap
I hope I’ll be back soon with the recompiled and finalized packages, but until then feel free to try the cross-compiled ones! Patches fixing crashes are always welcome! 🙂

update 1: Some packages like dpkg-dev are not installable, I’m working on them.

update 2: There is one similar project I know of which aims creating an address sanitized Gentoo variant and Hanno Böck will give a presentation about that at FOSDEM.

update 3: Note that using ASAN in its current form opens new attack surfaces thus it is not recommended for securing systems especially since it is incompatible with kernels with Grsecurity patches. The port is in current form allows detecting a lot of bugs thanks to ASAN, but as mentioned int thread at oss-security, but don’t use it on production machines. Experiments with the port might pave the way for an Address Sanitizer version which could be for improving system’s security without opening new ways of bypassing protection.

Run Wireshark on Android using Lil’ Debi!

Running Wireshark for Android has been an dream for a long time. Now it became a reality!

Wireshark running on Android using Lil'Debi

Wireshark running on Android using Lil’Debi

You only need a rooted Android device with ~2GB free space, Internet connectivity and some patience to follow the steps below.

  1. Install Lil’ Debi from Google Play or F-Droid. Lil’Debi will install a Debian root file system in a loop device separately from the Android file system allowing us running Debian side-by-side to the Android apps.
  2. Start Lil’ Debi and create the Debian system with 2000 MB image size. We will need some space for Wireshark, the graphical interface Wireshark depends on and for the capture files.
  3. Start the newly created Debian system and log in to it. You will see the error message “bash: [: : integer expression expected”, but you can continue.
  4. Now run the following commands at the command line to install all the packages Wireshark will need:
    # some important directories are missing from the PATH by default
    export PATH=/sbin:/usr/sbin/:$PATH
    # we will start an X server later
    export DISPLAY=
    # install wireshark an a few things to make it nicer
    apt-get install openbox gnome-themes-standard tshark wireshark
    # gnome-settings-daemon depends on plenty of packages we don't need now,
    # but we need gnome-settings-daemon for the GNOME theme to be applied
    apt-get install --no-install-recommends gnome-settings-daemon
  5. To run graphical applications from the Debian chroot we need to set up an X server on Android because Android uses a different method for presenting the GUI. XServer XSDL is available from Google Play and from SourceForge. Install and start it. It will show the display it is serving which will most probably end with :0, so the DISPLAY environment variable we set before is correct. (If there is an other number after the “:”, fix your DISPLAY variable.)
  6. Start the openbox window manager, gnome-settings-daemon and finally wireshark in capturing mode:
    openbox &
    # if you would like to have bigger menu fonts skip starting gnome-settings-daemon
    gnome-settings-daemon &
    wireshark -k -i wlan0
  7. Switch to the X server to see wireshark starting up, close the warning dialogs start capturing traffic!

I tested the tests above using a Nexus 7 (Asus 2013 version) running CyanogenMod M7, thus root access was granted by default, Lil’ Debi 0.4.7, and XServer XSDL 1.11.14.

update: Lil’ Debi has apparently been removed from Play Store. 🙁

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.