Mirrors
The Fedora Project is pleased and fortunate to have a large number of both private and public mirrors worldwide to help distribute Fedora software to end user systems.
However, there are potential security risks arising from the use of mirrors which are not directly under the control of the Fedora Project. Fedora takes many active steps to mitigate these risks, including GPG signing of packages, distributing the mirror list via HTTPS, and performing basic content validation on public mirrors, but each user or organization should evaluate the risks themselves, and take appropriate actions.
Risks
Stale Mirrors
A mirror may be somewhat out of date (content has changed on the master mirror system, but has not yet been synced out to a specific mirror). There is a window of opportunity, between when a new security vulnerability is discovered in a package, and when the corresponding errata package is published to the master mirror, but is not yet synced out to a specific mirror. During this time, the specific mirror will publish "stale" content - including the package containing the security failure.
Fedora's MirrorManager system and yum together limit the maximum size of this window to 7 days, though will likely reduce that to 3 days in early 2010. In the event a mirror is more stale than this limit, yum will not use that mirror, and will switch to another mirror.
Malicious Mirrors
As Fedora has no way to know if a mirror is malicious or not, we do not attempt to make that determination, though we do validate the content on non-malicious mirrors. It is possible for a malicious mirror to be listed in the MirrorManager database, and for users to be directed to such a mirror automatically.
A malicious mirror could publish one set of packages for the general public, and a different set of packages for an intended victim. These packages must still be signed by the Fedora key, but could be stale, which could keep the window of opportunity for exploiting a security failure open for longer than normal (up to the limit of staleness noted above).
Log Analysis
While the Fedora Project itself cannot maintain log files about individual package downloads, our mirrors, either public or private, may keep logs of packages downloaded by clients. Logfile analysis may inform the mirror about which software a particular system or set of systems may be running.
Mitigations
Fedora Project Steps
These are steps the Project takes to mitigate these risks on behalf of all users.
- Fedora GPG-signs all packages. Yum will only install packages signed with trusted keys, including the Fedora keys.
- Fedora distributes the mirrorlist to yum using https, to prevent man-in-the-middle attacks through munging of the mirrorlist while in transit.
- Fedora sets a limit on how stale a mirror can be. Yum honors this limit, and refuses to use a mirror that is more stale than the limit.
End User Steps
These are steps that Fedora users may take to mitigate these risks for yourself.
- Run your own private, trusted mirror. Edit your /etc/yum.repos.d/* files to direct your systems to use your private mirror. We provide instructions for setting up your own mirror.
- Present a different IP address to MirrorManager than your actual address. By default, MirrorManager uses your perceived public IP address to direct you to the "best" mirror it knows about. By changing the mirrorlist request URL, you can specify a different IP address to use in making that determination. This could prevent you from being directed to a malicious mirror that has listed itself in the MirrorManager database as being the "best" mirror for your network.
In /etc/yum.repos.d/*.conf, change: mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch to: mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch&ip=some-other-ip-address