Re: Discarding uploaded binary packages
On Tue, 16 Oct 2012, Arno Töll <arno@debian.org> wrote:
> On 16.10.2012 14:00, Russell Coker wrote:
> > There are a fairly small number of Debian servers. So even if the
> > probability of system compromise for a Debian server was the same as for
> > a laptop owned by a random DD the fact that DD workstations outnumber
> > Debian servers by at least 200:1 makes them more of a risk.
>
> Not a strong argument. The impact of a compromise of a buildd [or J
> Random Developer's machine running the buildd] is substantially higher
> given the compromise would affect 30k source packages, as opposed to [1,
> $whatever_gregoa_maintains_today[ of packages distributed amongst 950+
> individual machines.
An attacker wouldn't want to compromise all 30K packages, that would increase
the risk of detection without increasing the benefit. They would want to
compromise a very small number of relatively common packages. For example
they could compromise Apache or a library it depends on, some library that is
used by both KDE and GNOME, dash, bash, or a library used by shells.
Compromising 100% of systems with a high probability of detection would be a
lot less useful than compromising 50% with a low probability of detection.
So compromising the workstation of a random DD who packages only some programs
that aren't particularly popular wouldn't be a very effective attack in the
short term. But using such an attack to target other DDs would be easier than
using it to target build servers. For example an attacker who compromised a
single program could file a bug report saying that it gave a SEGV when run
with a new version of a particular library and have a good chance that the
maintainer of the library would do a test...
> Moreover, if you go down that path, you do not win anything of the state
> being, as an attacker can still make a sourceful upload which enters the
> archive unaudited as well.
The advantage for the good people is that source can be audited. While it is
difficult to audit source it's possible without huge effort, particularly as
the changes made in the process of Debian packaging are generally small when
compared to the upstream source.
Currently we have no certainty of the version of the libraries and compiler
used for building a package. So if a package has a different binary when it's
rebuilt that isn't evidence of attack. Determining what parts of the binary
change might be due to actual differences in operation of the program as
opposed to the same logic with different compilation is going to take some
work.
Comparing two different versions of a Debian package at the source level to
determine if the changes appear to match the changelog shouldn't be THAT
difficult. Comparing two different binaries is going to be a lot harder.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
Reply to: