apology: no actual 0-day exploit in anaconda

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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*.

-- 

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list


[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux