Re: Compromising Debian Repositories
Volker Birk:> On Sat, Aug 03, 2013 at 10:38:34AM +0000, adrelanos wrote:
>> Volker Birk:
>>> On Sat, Aug 03, 2013 at 09:16:40AM +0000, adrelanos wrote:
>>>> That should help to defeat any kind of sophisticated backdoor on build
>>>> machines.
>>> Really?
>>> How do you detect, if maintainer's patches contain backdoors?
>> Someone else builds the same package (binary) and detects a different
>> checksum. - That required deterministic builds.
>
> There will be the correct checksum, if the maintainer of the package
> does it.
Why?
> So no way to detect that with deterministic builds.
Why not?
> And if
> you're taking the build machine, you can inject “correct” checksums,
> too.
But that will get caught when someone else builds the package and comes
up with a different checksum? Or do you talk about hash collisions?
(Just saw, that you are discussing to move to safer hash algorithms,
thats fine and also a separate issue.)
>>> Attacks on the build process don't seem to be the hugest threats.
>> Why not? Lets make up an example. And attacker only need to compromise
>> the machine which builds the Apache server, doing so with a zero day the
>> attacker bought, lets say thats 10.000 $ or 100.000 $ - within budget of
>> three letter agencies and other criminals. An "investment". A
>> compromised Apache who's SSL traffic has an added weakness by the
>> backdoor is most profitable for economic espionage.
>
> Yes, that's possible. But if I would be the intelligence service, I'd
> better pay one of the maintainers. Job done.
>
>>> Not to mention the build tool chains.
>> Thats probably a separate issue.
>
> Yes, and not a small one (it's a classic). If I would have the job at
> the NSA, I for sure would invest a huge amount of effort to take GCC and
> LLVM. What an impact!
Sure. In my opinion you can only tackle on issue at a time. Of course,
having the big picture in mind and coming up with a better idea to kill
to birds with one stone is even better.
Reply to: