[clug] How you know your Free or Open Source Software Project is doomed to FAIL

Michael Cohen scudette at gmail.com
Thu Jul 30 15:45:24 UTC 2015


On 30 July 2015 at 14:51, Scott Ferguson <scott.ferguson.clug at gmail.com> wrote:
> 'If' you value the integrity of a given machine highly you 'could'
> hard-code the DNS (put it in /etc/hosts).
>
> DNS (cache) poisoning is not something new or occult. DNSSEC is another
> alternative worth considering. (again) set your standards to suit your
> requirements (providing you know your requirements). VM is not hard.
>
> If, as is likely an opponent like the NSA, can control routing - but you
> combine DNSSEC (which Google uses) with SSL, then NSA has to step up
> their game. Their resources are not infinite.

DNSSEC is irrelevant - DNS poisoning is already defended against by SSL.

> Alternative DNS verification schemes won't solve all problems (nothing
> does). You can't control routing outside of your local network (and
> maybe not even there).
>
> Regardless of which method you use to authenticate the relationship
> between the (alleged) owner of an SSL certificate, and the host, or what
> containment you use to execute the code - it's not over if you can
> verify *what* you are receiving.

The use of PGP package signatures might make you feel more secure but
it is exactly the same as serving those packages from an SSL protected
server. Consider the threat model:

- If your server keys are compromised, attacker can MITM the package
(This is the same as if your PGP key is compromised).
- If your server itself is compromised attacker can plant a modified
package - the same as if your PGP keys are compromised.
- SSL does not automatically mean the code is secure - a malicious
distributor can distribute anything from an SSL protected site - also
anyone can sign anything package with their PGP key - just because it
is signed it does not mean its secure.

I think in any conceivable situation you consider a failure with an
SSL hosted package, PGP is also the same. Except SSL is transparent
and much easier to use. With certificate pinning SSL is less
susceptible to CA attacks.

BTW the example you gave before of DNS poisoning (modifying the hosts
file) or adding root CA already require root access. If you have root
access to the machine why would you even care about backdooring a
download?

Michael.



More information about the linux mailing list