On 08/17/2012 07:33 PM, John Reiser wrote:
After further review, I agree that such an exploit almost certainly
did *not* happen to me today. I have no direct evidence that it did.
I was not running a network sniffer at the time, any logs were erased
because of early termination of the install, I am not running secure DNS
and have not audited my DNS recently, etc. [Also, if the exploit were
really good, then logs would have been whitewashed, etc.]
Other factors ("transient events", logic bugs, etc.) are sufficient
to explain the behavior that I observed. I apologize for any
unnecessary alarm that my post may have caused.
However, my review confirms that such an exploit *could* occur.
One weak spot is the use of http:// instead of https:// in
http://dl.fedoraproject.org/pub/alt/stage/18-Alpha-TC3/
and below, together with the non-signed
http://dl.fedoraproject.org/pub/alt/stage/18-Alpha-TC3/Fedora/x86_64/iso/Fedora-18-Alpha-TC3-x86_64-CHECKSUM
These are enough to enable an attacker to replace the entire contents of
http://dl.fedoraproject.org/pub/alt/stage/18-Alpha-TC3/Fedora/x86_64/iso/Fedora-18-Alpha-TC3-x86_64-netinst.iso
and its line in *-CHECKSUM without cryptographic discovery.
You are correct. Somebody could use dns poisoning or other tools to
redirect you to their site, replace the isos with their own and
regenerate the checksum file. For the test composes we don't typically
sign the checksum file, but we will for alpha/beta/final.
Jesse is correct that today's installer infrastructure *is* signed,
even for rawhide.
That's not what I said. I said that the /packages/ are signed. The
installer does not currently check that signature though. That's bug 998.
The running installer uses /etc/anaconda.repos.d/*
which [in my copy] have gpgcheck=1. The mirrorlist= and metalink usage are
protected by sha256sum over http://, as a probable performance enhancement
over https:// and/or some uses of PKI. [Such usage does appear to be
the weakest cryptography in the chain.] I apologize again.
https is expensive for content download, which is normally verified by
other means. Anaconda does not currently validate the gpg signatures of
packages. Again, bug 998.
However, I am unaware of _which_ key did sign today's rawhide installer
infrastructure, and I do not recall _when_ I agreed to trust such a key,
or for how long I agreed to trust it.
Kind of an irrelevant question, because the "installer infrastructure",
whatever that means, is not signed, nor does it trust any key for you
(currently). The "agreement" you made was to download and use the
software at your own risk.
Also, I am unaware of the
code in today's installer which consults the relevant revocation lists
to determine whether the owner has attempted to nullify trust in that key.
Given that the installer doesn't attempt to trust /any/ key, it's
somewhat irrelevant that it doesn't consult a revocation list for a key
that it does not trust.
These gaps illustrate some of the reasons for my less-than-complete
trust in today's practical usage. In some ways the weakest link
is the end user, which in parts of this case implicates *me*.
You as the user do have to decide what level of risk you're willing to
take. Nightly branched images and the Test Compose images are not
backed by gpg signatures on the CHECKSUM files. Alpha/Beta/Final are.
You can choose to trust that the owners of the gpg key are who we say
they are, then validate the CHECKSUM file against that key, then
validate the isos against the checksum file. You can then install the
packages from media, not getting any content from the Internet. Once
installed, you can use yum with gpg checking enabled (the default) to
continue to validate downloaded packages against the gpg key you choose
to trust to perform the install in the first place.
--
Jesse Keating
Fedora -- Freedom² is a feature!
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
