[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

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: