Last night and this morning, I ran Fedora 18-Alpha-TC3 netinst.iso (x86_64) burned to DVD, and met the bug https://bugzilla.redhat.com/show_bug.cgi?id=849211 . About 40 minutes ago, I re-ran the DVD but the bug had been fixed.
I never explicitly approved any Fedora 18 package signing key. I believe that none (zero) of the current "Fedora 18" [rawhide] packages have been signed. The download files from directory link http://dl.fedoraproject.org/pub/alt/stage/18-Alpha-TC3/Fedora/x86_64/iso/ are not accessed by the secure protocol https:// . There is a *-CHECKSUM given, but it is not signed, either.
The fix for the bug 849211 was automatically downloaded and installed, insecurely. That's just a short step away from a 0-day exploit in the installer.
On 08/17/2012 03:53 PM, John Reiser wrote:
Last night and this morning, I ran Fedora 18-Alpha-TC3 netinst.iso (x86_64) burned to DVD, and met the bug https://bugzilla.redhat.com/show_bug.cgi?id=849211 . About 40 minutes ago, I re-ran the DVD but the bug had been fixed.
I never explicitly approved any Fedora 18 package signing key. I believe that none (zero) of the current "Fedora 18" [rawhide] packages have been signed. The download files from directory link http://dl.fedoraproject.org/pub/alt/stage/18-Alpha-TC3/Fedora/x86_64/iso/ are not accessed by the secure protocol https:// . There is a *-CHECKSUM given, but it is not signed, either.
The fix for the bug 849211 was automatically downloaded and installed, insecurely. That's just a short step away from a 0-day exploit in the installer.
What evidence do you have that anything was downloaded and installed? Are you sure it wasn't just a transient or timing bug that didn't happen a second time around? Or there was some unknown trigger that is different the second time around? Please show us some sort of evidence of any sort of download and application of updated content for the installer.
The only mechanism we have in place for that is updates images, which you have to explicitly ask for.
Putting aside that question, the packages for F18 are indeed signed.
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/Fed... 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/Fed... and its line in *-CHECKSUM without cryptographic discovery.
Jesse is correct that today's installer infrastructure *is* signed, even for rawhide. 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.
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. 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. 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*.
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/Fed... 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/Fed... 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.
On 2012-08-18 12:39, Jesse Keating wrote:
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/Fed... 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/Fed... 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.
For the record, it used to be the case that the TC / RC builds never got outside of the Red Hat VPN. It used to not really make sense given the nexus between how quickly TC/RC builds increment, and the time it took to upload them to a publicly available location. A few releases back we decided it made sense and we now had the resources to make them 'publicly' available, but they really aren't official 'releases' in any sense, they are test builds that exist for the sole purpose of validation by the Fedora QA team. In other words, you certainly shouldn't use them for anything important. The system by which we make them available was pretty much thrown together on the fly and isn't much more sophisticated than 'dump them in some handy publicly available directory', which is why it's not terribly secure. Given that we've been doing things this way for several releases now it seems like it's an accepted procedure, so it probably would make sense to tighten up on it a little - publish https rather than http links, and sign the checksum files, if it's not too difficult.
anaconda-devel@lists.stg.fedoraproject.org