The Security of Automatic Updates

Have you updated your computer’s antivirus software today? Have you configured your desktop to automatically download and install its security updates? What about your copies of Microsoft Office, Adobe Acrobat, Mozilla Firefox and even consumer applications like Intuit Quicken? All of these programs now have built-in update capabilities. Are you using them?

Presumably your answer to all of these questions is yes. In these days of online attacks, malicious hackers and aggressive spyware, you need to either aggressively download your updates or else keep your computer isolated from both the Internet and your internal networks. Unpatched computers don’t last very long in the wild these days. As a result, virtually all operating systems, applications and even shareware come with the ability to check for new updates—and most of these systems can be configured to automatically download and install the updates without human intervention.

But there is a problem with many updating systems, as a recent paper by three researchers at the University of Massachusetts makes alarmingly clear. Many update systems, it seems, are themselves riddled with security vulnerabilities. In the paper, which was presented this past July at the First Usenix Workshop on Hot Topics in Security, professor Kevin Fu and his graduate students Anthony Bellissimo and John Burgess show that update systems in popular software packages like McAfee VirusScan and Mozilla Firefox can actually be used to take over a computer that’s trying to update itself!

The so-called secure update problem is twofold, say the researchers. First and foremost, programs need to have some way of authenticating their updates to establish their legitimacy. But it is also critically important that programs have an authenticated connection to the update server. In the rest of this column I’ll discuss why both of these authentications are important, and I’ll show what can go wrong with one or both missing. This is an issue that CSOs need to be aware of.

The Code’s Source

As the name implies, having an update authenticated means that there is some way for the software doing the update to assure itself that the update is an authentic version from the intended source. Without authentication, a clever attacker can arrange for the program doing the update to download and run an exploit instead. In practice, updates should be authenticated with a digital signature—they should be signed with a private key. The matching public key should be embedded inside the application doing the update. Before the update is run, the application should verify the digital signature. If the signature doesn’t verify, the update should be deleted.

The UMass researchers discovered that many programs don’t authenticate their updates. That may not be so surprising—lots of software has security vulnerabilities, after all. But what is surprising is that among the products that didn’t have digitally signed updates were McAfee VirusScan and McAfee Virex, two antivirus, anti-malware programs. While any program can have a bug, the failure to use digital signatures to authenticate code that’s being downloaded and run is really a design flaw. Such a failure implies that the program’s authors don’t understand the kinds of threats that they are claiming to protect against. (A spokesperson for McAfee says that the vulnerability was confined to a small piece of legacy Virex code and that the problem was patched in February 2006.)

Exploiting the flaw in the McAfee products and other programs is actually a lot easier than you might think. Most of these unsecured update systems simply go to a Web or FTP server, check the time stamp on the most recent file and download the file if it’s new enough. The address of the server is usually hard-coded into the program doing the update, although occasionally it is stored in a configuration file. To exploit the flaw, all the attacker needs to do is send the program doing the update to a server that’s run by the attacker.

One way to send the program to the wrong website is with a DNS-based attack. Just run your software at a café offering wireless Internet service and wait until some other computer does a DNS query to find the IP address of the update server. Since your program is running at the café, it can answer the DNS query faster than the legitimate DNS server and point the inquiring computer toward the wrong destination. Another exploit would be to run your own wireless access point, wait for some victim to attempt a connection to the update server and respond to the request with your hostile code. In either case, the update that gets downloaded might contain some kind of worm or Trojan horse. When the program is run, the victim’s computer will be compromised.

I wonder if antivirus programs scan their own updates for viruses before the updates get installed.

Signing updates with a digital signature doesn’t prevent the hostile code from being downloaded, but it does prevent the code from being run. Unfortunately, this is only half the battle. Even if updates are signed, an attacker capable of intercepting DNS requests or diverting Internet traffic can still use an update service to take over an unsuspecting victim’s computer.

Remember, a signature on an update just means that the update is authentic—it doesn’t mean that the update is any good. Even legitimate updates have security vulnerabilities occasionally. Vulnerable updates are usually replaced in short order once the vulnerability is discovered. But if an attacker obtains a copy of a vulnerable update and can feed it to an unsuspecting client, the attacker could then use the vulnerability to exploit the victim.

Another way that an attacker can subvert the update process is to run an update server that always responds, “No updates today!” Clients will then connect, find no update and disconnect—and never know that they have been deceived. A well-placed attacker could prevent an entire organization from installing security updates for a period of time, then attack all the organizations’ vulnerable machines.

Connection Check

To detect these attacks, the client needs to authenticate not just the update itself but also the connection to the update server. One way to do this is by having the client connect to the server using SSL; this assures the authenticity of the server’s DNS name, assuming that the SSL client’s built-in certificate authority certificates haven’t been corrupted. A slightly more clever way to authenticate the server is to have it publish a signed message on a daily or hourly basis that reports the date of the most recent update. The advantage of this approach is that the updates don’t need to be downloaded with SSL and don’t depend upon the public-key infrastructure. Updates could even be mirrored on unsecured, public FTP servers.

Of course, an attacker who controls the Internet connection can simply prevent the client from reaching its update server entirely. But in this case, the client will at least know that something is wrong. It might then notify its human operator or shut down and refuse to operate until it can verify for sure that there are no new updates available.

Secure update mechanisms have largely been ignored both by developers and by computer security establishments, says Fu. The UMass paper evaluated the update systems built into Apple’s Mac OS, Microsoft Windows, Adobe Acrobat, Microsoft Office on the Mac, Mozilla Firefox, Fugu, McAfee VirusScan, McAfee Virex and Debian Linux. None of the systems properly authenticated the connection between the update client and the update server at the time that the study was performed, although Windows Update and Mozilla Firefox made some attempt. Fu notes McAfee’s claims of having addressed the vulnerabilities, although McAfee did not provide details.

The problem here is that updates are becoming a more and more vital part of our information infrastructure. An increasing number of computers with embedded software—including those in navigation systems, voting machines, cell phones, and even implanted medical devices like pace­makers and insulin pumps—require regular software updates. Even software designed to play audio CDs can have security vulnerabilities, as demonstrated by the recent fiasco with Sony Music’s attempt at digital rights management. Indeed, a system that doesn’t have provisions for taking software updates but potentially takes data from the outside world, risks catastrophic failure, for there is no way to fix a security vulnerability if one should be discovered. But as demonstrated by the research presented at the Usenix workshop, those software update facilities themselves can be a source of vulnerability if they are not properly implemented.

One of the problems here is that every developer needs to implement its own secure update facility. It would be far better if secure updates were a service provided by the operating system on servers, desktops and cell phones. Just as these platforms provide SSL and secure storage, they could also give developers a way to register for automatic version tracking and updating of their applications.

Until such features are available, the security of updates will be just one more thing that CSOs need to address.