Re: Compromising Debian Repositories
Michael Stone:
> On Sun, Aug 04, 2013 at 10:12:40AM +0200, Heimo Stranner wrote:
>> I think the real issue is about if the malicious patch is not part of
>> the source package
>
> Why? It certainly makes your argument simpler if you arbitrarily
> restrict the problem set, but it isn't obvious that it makes sense. If I
> was going to backdoor something, I'd just make an innocent-looking
> coding error that would enable a successful exploit; I certainly
> wouldn't put in a commented section of code that says "backdoor here".
> With sufficient effort it wouldn't be hard to inject such a
> vulnerability that would go unnoticed for years--and
> I'm not sure why
> that's less of an issue than someone making a one-time build with a
> malicious patch that is not part of the source package.
An innocent-looking coding error requires a malicious maintainer.
A malicious patch not part of the source code can be done by any
adversary who compromised the build server. I think the latter is more
simple, risk free and anonymous.
Getting rid of possibilities for intentional innocent-looking coding
error is possible as well. First of all, how much security is the goal
vs required effort? Is pragmatic security, as in "no random script kiddy
can take down any Debian powered systems" sufficient or is it "we don't
want all the three letter agencies around the globe being always able to
remotely access any Debian system".
As far I know, only lower level programming languages such as assembler,
C and C++ open up for sophisticated intentional innocent-looking coding
errors, right? Bugs possibly leading to remote code execution are much
more obvious to spot in higher level languages such as python?
If that case and more than pragmatic security is the goal, the use of
lower level languages should be restricted to cases where other
solutions aren't possible (bootloader etc.). And frozen. So that the
code is 100% stable and vulnerability free after some time. It should be
possible in theory if our machines get more performance over time? I
think that would be quite painful to rewrite so many tools.
Are there any better solutions to the trusting trust issue? Or will the
fight against backdoors be lost at some point?
Reply to: