In a recent article entitled Attacks on Package Managers, there are many things discussed by a group of Computer Science students (and maybe some instructors) at the University of Arizona.  While I can not address how Debian protects their APT repositories or how Fedora (or anyone else) protects their YUM repositories, I can discuss how CentOS protects its update system used by default to deliver updates to users.

 CentOS Mirrors

First, let me explain the CentOS mirror system.  CentOS directly controls about 30 mirror servers from which we serve updates via yum and rsync to other public mirrors and to users directly.  These mirrors are members of the CentOS.org domain and are totally controlled by the CentOS project.  These mirrors can be totally trusted because only CentOS Project personel have login or update access to these machines.

A second set of mirrors are called the CentOS "Public Mirrors".  These mirrors are monitored by a system called mirmon, the results are listed here .  These public mirrors are also listed here in another format for ease of finding a close mirror.  The first major fault in the study linked above is that these mirmon monitored mirrors are only the first step in being assinged to provide updates directly to CentOS users.  Just being listed as a mirror DOES NOT MEAN that yum (as configured by CentOS by default) is going to use that mirror.  Please see the mirrorlists sectionbelow for that selection process.

Mirmon uses a couple files within the mirror to verify that a mirror is doing updates and it is a "Coarse" test that we use to decide which mirrors will be subjected to the mirrorlist tests below.  If you are rsyncing a local mirror of your own from one of the public mirrors, I recommend that you use more than one, then you can be sure one person is not in any way modifying anything.

Mirrorlists

The aspect of CentOS security which this study totally ignores is called the CentOS mirrorlists.  This system is the one that is actually used (in a default setup as published by CentOS ) to deliver updates to users.  CentOS uses a script to download a file called repomd.xml from every repo on every server listed as active in the CentOS Public Mirrors. Once we have that file, we check it against the same file from the master CentOS server.  If the file from the public mirror is different than the file on our CentOS master mirror, then that server is not published on our mirrorlists.

The mirrorlist generation process runs non-stop in a loop testing each and every CentOS "Public Mirror" on every run.  With the current number of public mirrors it takes a maximum of 2-3 hours for a mirror that does not have the same repomd.xml file in a repo to be removed from the mirrorlist.

CentOS does not just check one repo on a given public mirror, we check each and every repomd.xml file from each and every published repository on each and every public mirror.

The CentOS mirrorlist is only 10 servers long, even though we have about 200 mirrors listed in our list.  There is a different list for each country where the 10 listed servers is geographically picked and if 10 public servers are not found, CentOS.org mirrors back fill the list to 10 servers.  This means that every mirror listed is NOT even used in our mirrorlists.

If you are using the default CentOS update method, you can rest assured that you are being provided a geographically accurate (by country) and updated (tested and regenerated every 2-3 hours) mirrorlist.

The Study

Now I will discuss the issues brought up by the above article and discuss if these issues apply to CentOS.

First, lets discuss the Metadata Replay attack that they list.  This attack is not at all a concern with CentOS if the default method (the CentOS mirrorlists) is used to do updates because every 2-3 hours if an individual repository on a mirror is not updated, it is not on the mirrorlist.  If you are running your own mirror that you update from a public mirror, you can write your own script to download the repomd.xml file from the proper place at http://mirror.centos.org/ and you can check yours file against this file, if they are the same then you have a good set of metadata ... with that you will get the correct updates.

The next attack they discuss is the Mirror Control attack.  This one is also NOT a problem for people using the default CentOS update system, since each and every repomd.xml file (the same one you get if you use yum and the default mirrorlist) is verifed on every mirror every 2-3 hours.  Is it possible for someone to provide a fake file to the centos testing machine, and a different one to other people.  Yes, if they know the IP address of each and every machine we might possibly use to test the mirror then they might be able to give us a redirected file and give everyone else a different metadata file.  Even IF they did that, they do not have packages signed by a centos.org key.  Because of our repomd.xml file checking, the likelyhood of this attack (as with the first one) is almost 0.

The other major problem that they discuss is a man-in-the-middle attack.  Without using HTTPS, a person MIGHT be able to use a man in the middle attack.  It is not a simple thing to do, and it does not get any "malicious" software (since CentOS requires signed packages) ... though it might be possible to list old files so that updates are not done.  This would be a very hard thingto undertake just to prevent an update, though possible in theory.

The Bottom Line

Being listed as a "Public Mirror" DOES NOT MEAN that a system is being listed in the CentOS yum mirrorlist.  CentOS does other checks and our mirrorlists are safe.  You can easily make sure that your system is updated by running yum at consistent intervals and requiring  all packages are signed.

If you are creating your own mirror, you can check your repomd.xml file against those at http://mirror.centos.org/

If you use packages signed by a centos.org key, you can be sure we released it.  If you monitor the CentOS Announce mailing list you can see when Security Patches are released.

Should you be concerned about security updates and install them when they are released ... YES.

 Is the sky falling ... NO.