Category: Security

A sleazy QuickTime trick

In a perfect world, we’d be able to choose one media player for everything. In the real world, we need two or three media players to handle the mix of incompatible and proprietary formats available on the Web. So, although I don’t use QuickTime often, I keep a copy installed so that I can see video clips on sites that offer only Apple formats.

If you use QuickTime on Windows or a Mac and you haven’t updated it since January 10, you’re at serious risk. But be careful when you go looking for that security update or you may get more than you bargained for.

On January 10, Apple released a critical update for QuickTime designed to fix five separate vulnerabilities, any of which can result in “arbitrary code execution” if you simply view a specially crafted image file (QTIF, GIF, TIFF, or TGA) or a similarly doctored media file. The vulnerability exists on Windows XP, Windows 2000, and Mac OS X. Sounds at least as serious as the WMF exploit that Microsoft was pilloried for, and indeed it is. (It took 71 days for Apple to come up with the patch after this vulnerability was reported, by the way, but that’s a topic for another day.)

Being a security-conscious sort, I checked my version of the QuickTime Player and determined that it was hopelessly out of date. I had version 6.5.1 installed; these vulnerabilities are fixed in version 7.0.4. I tried the Update Software option from the QuickTime Player menu, but when it finished its quick download and installation I was only at version 6.5.2, and it told me I was completely up to date. So I headed over to Apple’s QuickTime site and was greeted with this page:

I’ve circled the two areas of interest on this page. See that big blue Free Download Now button? That’s what most people will click. I almost did, until I noticed the wording at the top of the page: “QuickTime 7 with iTunes 6.” I don’t want iTunes! But I need that security update. Maybe I should read the security bulletin again. Oh, dear. Right there at the bottom, it has the bad news:

APPLE-SA-2006-01-10 QuickTime 7.0.4:

For Mac OS X v10.3.9 or later
The download file is named: “QuickTimeInstallerX.dmg”
Its SHA-1 digest is: a605fc27d85b4c6b59ebbbc84ef553b37aa8fbca

For Windows 2000/XP
The download file is named: “iTunesSetup.exe”
Its SHA-1 digest is: 1f7d1942fec2c3c205079916dc47b254e508de4e

Well, that’s odd. If I own a Mac, I can just get the QuickTime installer, but because I use Windows I have to install iTunes? Doesn’t seem right.

Hey, what’s that tiny link at the bottom of the QuickTime downloads page? The one that reads QuickTime Standalone Installer? Clicking that link from Internet Explorer installs the QuickTime ActiveX control. Clicking it from Firefox downloads a file called … QuickTimeInstaller.exe. No iTunes required. (Update: The QuickTime ActiveX control only loads in IE if it’s not already installed. The download link leads to the QuickTime installer, regardless of browser.)

This is a crappy way to do business, Apple. The security bulletin should reference the QuickTime installer, not just the iTunes setup file that happens to include the QuickTime Player. And if someone comes to your site looking for a critical security update, don’t push extra software on them.

Years ago, Real used to pull this same crap with their RealPlayer. When you visited the download page, you were steered into the trial version of Real’s subscription-based software, and it took a treasure map and a Sherpa to find the tiny link to the free player. It took a few thousand complaints, but Real finally wised up. Go to Real.com now and you’ll see two buttons of equal size: one offers a 14-day trial of its premium SuperPass product; the other is labeled Free Download. No magnifying glass required.

I never thought I’d say it, but Real is setting the standard when it comes to downloads. Apple, clean up your act.

Update: A visitor from Down Under comments that Real.com is up to its old tricks on sites outside the United States. After telling Real.com that I’m from Australia, I can see what he’s talking about. As a point of reference, here’s what the main U.S. page looks like:

Sanitizing Word documents

A new document from the National Security Agency is getting a lot of link love, thanks to a recent mention by Cory Doctorow at BoingBoing.

Redacting with Confidence: How to Safely Publish Sanitized Reports Converted From Word to PDF, which has a publication date of December 13, 2005, covers an important topic, and the authors do a good job of getting across their primary message: If you plan to publish a document originally created in Word, you have to look very carefully for sensitive information that you don’t want to reveal. When you find it, you have to delete it, permanently, not just hide it or cover it up.

So far, so good. But I was taken aback by this statement:

The following steps were tested with MS Word 2000 and Acrobat 5.0 and 6.0. Other recent versions should work similarly.

“Should work similarly”? That doesn’t give me a lot of confidence. If you’re going to go to the trouble of producing a definitive set of guidelines for such a crucial subject, why use only one seven-year-old version of Word? How long could it have taken to test these procedures with Word 2002 (from Office XP) and Word 2003 (from Office 2003)? And why not give it a run-through with Acrobat 7.0, the current version?

Nope, there’s no secret Windows backdoor

If you’re even remotely interested in Windows security, you’ve probably seen the sensationalist claims from Steve Gibson that the WMF vulnerability was actually a secret backdoor into Windows, deliberately placed there by Microsoft.

I’ve tried to steer clear of this claim so far, because the last thing I want to do is add to the hype over what is at best a highly suspect conspiracy theory. I thought the explanation and rebuttal from Stephen Toulouse of the Microsoft Security Response Center made good sense, but I also understand that some people are going to be justifiably skeptical of any official statement that comes out of Redmond.

But I’ve just run across Mark Russinovich’s detailed analysis of Gibson’s claim, and I feel confident that his conclusion is correct:

In my opinion the backdoor is one caused by a security flaw and not one made for subterfuge.

Mark’s body of work and impressive library of utilities at Sysinternals proves that he knows more about the guts of Windows than just about anyone else on the planet, including lots of Microsoft lifers. He’s also the guy who broke the Sony rootkit story.

When Mark says there’s no conspiracy, that ends the discussion for me.

Windows users, don’t let your guard down

The problem with relying on software tools to keep you safe is that a user with administrative privileges and a little knowledge (which, as everyone knows, is a dangerous thing) can defeat or disable those tools. Two examples of this phenomenon appeared this week.

As I’ve mentioned before, I currently am using Microsoft Windows OneCare Live, an all-in-one security suite that’s in beta release right now. On several occasions, I’ve disabled the firewall to troubleshoot problems with my network connection. Whenever I do that, OneCare prompts me to send a quick note to Microsoft explaining why I turned off this essential protection.

Apparently, lots of people have been dutifully filling in that form. Over at the Windows OneCare Team Blog, Microsoft summarizes the results from those submissions:

Based on our investigation, there are four primary reasons people are turning off their firewall.

  1. Do not think a software firewall is necessary
  2. Do not like the (sometimes incessant) pop-up dialogs
  3. An application failed to install with firewall turned on
  4. An application fails to work with firewall turned on

The entire discussion is worth reading, along with the comments. This is one case where I think “nag” dialogs are essential. In fact, I think one commenter’s suggestion of an option to temporarily disable the firewall for a specified period of time (automatically re-enabling it after the time is up) is a good one.

Example #2 comes from George Ou, who reports that Skype 2.0 looks like a virus. The problem? A bug in the latest version of Skype triggers a Data Execution Prevention warning. The most likely reason is that a chunk of memory that contains executable code isn’t properly marked. In that situation, DEP (which uses a setting in the OS in combination with the CPU itself) views this as a potential attack and blocks execution of the code.

DEP is an excellent first line of defense against buffer overflow attacks and other security vulnerabilities. But in this case what’s likely to happen is that the user, because they want Skype to work right now, is going to configure the program as an exception and turn off the warnings. In fact, that’s exactly what Skype recommends on its support pages.

If that happens often enough, it leaves a gaping security hole. The better approach? Skype users should insist that the company fix its code so that it doesn’t load executable code in segments marked as data only.

Those warnings exist for a reason. Turning off the alarm bell doesn’t make the problem go away.

Here’s why patches get tested

Oops. Security expert Dana Epp notes that the “unofficial” patch for the WMF exploit apparently disabled printing for some people using PostScript printers.

How would you feel if your business had bought in to the hysteria and deployed this untested code in a production environment, and then you missed a deadline to submit a design proposal for a key client that cost you a million-dollar contract?

Lots of good insights in Dana’s post.

A tale of two patches, part 2

Apparently, some people think I chose a bad example yesterday to illustrate my point that patching complex software takes time. So maybe a different example will help.

This Secunia advisory from September 9, 2005 was rated “highly critical”:

Tom Ferris has discovered a vulnerability in Firefox, which can be exploited by malicious people to cause a DoS (Denial of Service) or to compromise a user’s system.

The vulnerability is caused due to an error in the handling of an IDN URLs that contains the 0xAD character in its domain name. This can be exploited to cause a heap-based buffer overflow.

Successful exploitation crashes Firefox and allows code execution but requires that the user is tricked into visiting a malicious web site or open a specially crafted HTML file.

NOTE: Exploit code is publicly available.

This Mozilla.org advisory offered a workaround that involved disabling the IDN functionality

On September 6 a security vulnerability affecting all versions of Mozilla Firefox and the Mozilla Suite was reported to Mozilla by Tom Ferris and on September 8th was publicly disclosed.

On September 9, the Mozilla team released a configuration change which, as a temporary measure to work around this problem, disables IDN in the browser. IDN functionality will be restored in a future product update. The fix is either a manual configuration change or a small download which will make this configuration change for the user.

Sound familiar? That’s exactly how Microsoft initially responded to the WMF exploit.

The patch for this vulnerability (and remember, there was working exploit code out there) was incorporated into Firefox 1.0.7, which was released 12 days later, on September 21.

I’m not trying to “smear the Open Source community.” In fact, I’m an enthusiastic Firefox user and supporter. In the September 9 vulnerability, I don’t think that the Firefox developers were underestimating the problem, nor were they sitting on a patch. The process took 12 days, period. I don’t think the Windows security team was sitting on the WMF exploit either. The process of developing and testing a fix takes time. That’s true of any complex program, including Firefox and Windows.

WMF exploit patch is out right now

Underpromise, overdeliver. That’s the classic advice from business school, and someone at Microsoft learned that lesson well.

Five days earlier than promised, Microsoft has delivered the January 2006 security update for the WMF vulnerability. Why now? Mike Nash, Corporate Vice President for Security, explains on the Microsoft Security Response Center Blog:

[A]ctually creating the update was a straight forward process. The challenge was testing the update on all of the supported versions of Windows and the 23 languages we support and making sure that the set of applications that might be effected by this update are not negatively affected by this change.

On Tuesday morning, we announced that our goal was to have an update available as part of our regular update cycle on January 10th. That date was based on our forecast on where we would be with quality.

So what changed to make us decide to release an update today? Two things: The first is that we have an update that we believe in. The team worked very hard to run all of the key scenarios that we are concerned about. While we would always like to have more time, we are confident in the quality of the update. The second issue is that while there is no imminent threat, a number of customers are seeing exploit traffic hitting their AV, IDS and IPS systems. Interestingly, when you talk to the security vendors they are seeing the rate of infection and the rate of spread actually decrease. But, when I spoke to a number of customers and asked if the current situation warranted an out of band release of the update, they said yes, if we had hit our quality goals. I reminded them of their past feedback about out of band updates being an inconvenience and their preference for the monthly release schedule. Overall, they felt that we had made these out of band releases so infrequent, that doing it once when it matters was not a big deal.

If you have Automatic Updates turned on, you’ll get the update without any effort on your part. If you don’t want to wait, visit Windows Update right now.

A tale of two patches

Update: The point of this post is not “Firefox sucks, too.” The point is that patching complex programs takes time. I’ve posted another example that makes the same point here.

In the comments to yesterday’s post about SANS and the WMF exploit, a visitor remarks:

Bear in mind that when popular open source (such as Firefox) vulnerabilities have been exposed, there were patches available in about 48 to 72 hours. It’s been more than a week since the WMF vulnerability was exposed. The problem is pretty well known by now, and it’s telling that users themselves have managed to generate a fix before Microsoft has.

My, what selective memories people have. Patches in 48-72 hours? Maybe if you’re a developer, but not for mere mortals.

Remember the Firefox IDN exploit? Working exploit code was released on or before February 7, 2005. The updated version that fixed the underlying vulnerability was released on February 24, 2005. That’s 17 days later, for those who don’t have a calculator handy. And on top of that, the Mozilla group didn’t make this available through its auto-update mechanism until roughly a week after the new version was ready.

And yet a chorus of doomsayers are ready to throw Microsoft to the wolves because they plan to release a patch for the WMF exploit via Windows Update 13 days after it was first reported. Based on the Firefox experience, that seems to be about how long it takes to produce a reliable, safe, well-tested patch.

SANS jumps the shark

This rant from Tom Liston at SANS is disgraceful to see on a serious security site. You got problems with Microsoft’s decision? Make your case. Give your readers some evidence. Get angry if you want. But juvenile satire that ignores the business realities of the situation is just stupid, and it’s double-plus-stupid when the rant is completely free of facts or analysis.

My collective opinion of SANS has dropped severely.