The Evil Side of Automatic Software Updates

Automatic software updates are supposed to make your life easier. But vulnerable updating mechanisms can help your enemies instead.

By Simson Garfinkel

E-mail this article | Printer friendly

Webcasts

White Papers

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.

1 2 || Next >>

Add a Comment: Your comment will be displayed at the bottom of this page, at the discretion of CSOonline.
* Name:
* Title:
* Corp:
* E-mail:
* Subject:
* Your Comment:
	* Required fields.
We do not post comments promoting products or services. Comments are owned by whomever posted them. CSO is not responsible for what they say. Selected comments may be published in CSO magazine. We will not sell your personal information. We do display your name, title, and corporation but not your e-mail address.