Bug#763399: Hardening dpkg/apt

[Michael Vogt <mvo@debian.org>]

On Mon, Sep 29, 2014 at 09:24:35PM +0000, bancfc@openmailbox.org wrote:
> Package: apt
> Version: all

Thanks for your bugreport. 
 
> Sometimes apt/dpkg can contain vulnerable, remotely exploitable bugs
> which s a big risk when used over the untrusted internet. 
>
> As it happens, anyone could have been in a position to run
> man-in-the-middle attacks with the latest security hole
> [CVE-2014-6273] in apt-get. What makes this bug cripling is that
> updating apt to fix it would have exposed it to what the fix was
> supposed to rpevent, so manually downloading the package out of band
> was the safest option this time.

I totally agree that we need to do more to protect the downloaders
(and Julian pointed to some efforts for this already).

In this particular case got some protection from the fact that we
build apt with the default dpkg-buildflags which include
_FORITY_SOURCE=2 [1].

This helps to mitigate the recent apt buffer overflow, the sprintf()
call is translated to sprintf_chk() and I'm not aware of a way to
exploit this other than to trigger a abort(). I checked the generated
assembler for the __sprintf_chk call and the max buffer size is
correctly loaded into %edx so it seems like the protection is
working. If there is a way to circumvent this, then I would love to
hear more about the details of such a attack!

> In order to drastically limit an attackers options I recommend
> creating a seccomp-bpf filter for apt and dpkg to limit what they
> can do should a weak function be remotely exploited. Other options
> include enabling any and all compile-time binary hardening such as
> PIE, RELRO, CANARY etc.
[..]

All hardening except for PIE and ld -z are currently enabled, these
two will be enabled with the next upload (probably in experimental
first).

We do want to go further and protect the downloaders but there is some
more work involved here, we need to move the proxy auto-detection out
of the acquire method first but once that is done, we can further lock
down the downloader code.

Help with this effort is of course very welcome :) !

Thanks,
 Michael

[1] Apt has all hardening features enabled in the debian/experimenal
branch now and we plan to move this to unstable soon.