This is the last post in the series of updating third-party software. As I reflected in a previous post, I've recently seen multiple glitches in the update process for various commonly used client software when the official update tools are used. If the update process does not work efficiently and accurately, it just only means one thing: lots of end users are vulnerable and exposed to all the client attacks we are seeing in the wild. Let's analyze some current examples for Windows (XP SP2):

• QuickTime 7.4.1: As we announced last week, a new QuickTime update, 7.4.1, was released to fix a security vulnerability. The Apple's Software Update (ASU) tool ("C:\Program Files\Apple Software Update\SoftwareUpdate.exe"),or the QuickTime (QT) update feature at "Help -> Update Existing Software...", do not detect the latest version, 7.4.1 in a system running 7.4. This was also the case with the update from QuickTime 7.3 to 7.3.1. This behaviour occurs under Windows, but not under Mac OS. QuickTime 7.4.1 can be manually downloaded from the Apple's website.
  The update tool connects to "qtsoftware.apple.com", and requests "/cgi-bin/query2?" with a few parameters. If the "lang=xx" value in the request is different from "us", then it reports back that the latest QuickTime version is 7.0.3!! If the value is "us", then it reports back 7.4.1 and 7.1.6 (for older Windows OS versions) as the latests available versions.
  In the non-US case, it requests and retrieves multiple files from various Apple sites (swcatalog.apple.com, swcdn.apple.com, etc), and although the final file contains references to 7.4.1, they are not taken into consideration.
  
  A couple of anonymous ISC readers confirmed a similar behaviour and even notified Apple. It seems Apple does "not believe that this issue is a security exposure.". Sorry, but I disagree.
  
  IMPORTANT!! Yesterday multiple buffer overflow vulnerabilities were released for the QuickTime "QTPlugin.ocx" ActiveX control (including version 7.4.1) that may allow the execution of arbitrary code within the context of the application invoking the ActiveX control (such as Internet Explorer). There is no patch available yet and a DoS exploit is publicly available, and it works. It is recommended to disable the control on IE ("Tools -> Manage Add-ons") or set the kill-bit for CLSID 02BF25D5-8C17-4B23-BC80-D3488ABDDC6B through the registry.

• Java 6 Update 4: Last month we announced the latest Java update, that includes lots of fixes. Even today (a month later), if you run the Java update tool (C:\Program Files\Java\jre1.6.0_0X\bin\jucheck.exe), it reports back that the latest version is Java 6 Update 3. The update process ends up requesting the following XML file: http://javadl-esd.sun.com/update/1.6.0/map-1.6.0.xml. As you can see, it references "http://javadl-esd.sun.com/update/1.6.0/1.6.0_03-b05.xml", that is, Update 3.
  
  As Sun is using Akamai to balance the load, we tested this at the ISC from different places over the world and it seems it is always the case (Thanks to the fellow handlers Daniel, Stephen and Bojan!). You can manually download the latest version from the Sun's website.
  
  It is important to emphasize that all Java updates do not remove the previously installed and vulnerable versions, so you need to remove them manually. Don't forget about it unless you have a reason not to do so!

•  Unprivileged user vs. Administrator: A few third-party Windows software do not show the availability of new updates unless you are running as Administrator. I understand that the installation must be performed with Admin privileges, but the check could be done as a regular user. Best security practices recommend to work as a regular user unless you need to perform administrative operations, so we have a serious conflict here! Just a few examples:
  • Adobe Reader does not show the "Help -> Check for Updates..." menu unless you are running with Administrator credentials.
  • Thunderbird grays out the "Help -> Check for Updates..." menu if you run as a regular user.
  • The Microsoft Update Web page can be accessed as a regular user, but it clearly indicates you need Administrator privileges to install updates from the Website. The problem is that even if you run Internet Explorer as Admin through "Run as...", it doesn't work. You can see and download the updates, but when  they are going to be installed, they fail. This is not the case with the automatic updates, as the "Automatic Updates" service uses the local System account.
  Therefore, the conclusion is that you need to periodically (every day?) login as (or run things as) Administrator to perform periodic tests for new updates. Obviously, this is not practical for end users, so we clearly need to improve the third-party update mechanisms in Windows to be accurate, up-to-date and work smoothly from non-privileged accounts.

 --
Raul Siles
www.raulsiles.com