If you're not following Mikko's Twitter feed, you may have missed yesterday's news that public proof of concept exploit code for the Windows shortcut (.lnk) vulnerability has been released on exploit-db.com.

This further escalates the danger of the shortcut vulnerability. So far, only the authors of the Stuxnet rootkit have utilized the flaw, but now there's just no doubt that other bad guys will soon follow.

Fortunately some folks are also using the PoC for good.

Didier Stevens (well known for his research on Adobe Reader's /launch feature) tested the exploit with his Ariad tool and it was successfully blocked. Stevens has tested back to Windows 2000 SP4. If you need to maintain a legacy system that's not scheduled for a Microsoft Security update (such as Windows XP SP2), Ariad might be an option.

But Stevens calls Ariad beta software, and so that won't be an option for some. So what else can be done?

Chet Wisniewski at Sophos has suggested using Group Policies to restrict the launch of executables to local hard drives.

And of course, the workarounds from Microsoft's Security Advisory.

  •  Disable the displaying of icons for shortcuts
  •  Disable the WebClient service

Regarding Security Advisory 2286198: parts of it seem unclear to us.

For example, the advisory states:

"The vulnerability exists because Windows incorrectly parses shortcuts in such a way that malicious code may be executed when the user clicks the displayed icon of a specially crafted shortcut."

Yet our analysis indicates otherwise, clicking is not required.

Microsoft's own Malware Protection Center states that the exploit:

"takes advantage of specially-crafted shortcut files (also known as .lnk files) placed on USB drives to automatically execute malware as soon as the .lnk file is read by the operating system. In other words, simply browsing to the removable media drive using an application that displays shortcut icons (like Windows Explorer) runs the malware without any additional user interaction."

Simply browsing the removable drive. No clicking.

And then there's a question about the AutoPlay feature. The advisory states:

"For systems that have AutoPlay disabled, customers would need to manually browse to the root folder of the removable disk in order for the vulnerability to be exploited. For Windows 7 systems, AutoPlay functionality for removable disks is automatically disabled."

But this is what comes up, by default, when we plug a USB device into our Windows 7 test system:

That dialog does say AutoPlay, right? So it seems that AutoPlay isn't automatically disabled on Windows 7 systems.

Perhaps it should have said AutoRun is disabled by default? (Windows 7 is definitely better at handling removal media than previous versions of Windows, but AutoPlay still seems to be a default feature.)

In any case, having AutoPlay disabled isn't much of a mitigating factor for this vulnerability. It's only: click Start, click Computer, and click Removable Disk. Three clicks and you're at risk. But still, organizations should disable the AutoPlay feature in order to limit Windows 7 social engineering tricks.

Ordinarily we wouldn't pick these small nits with Microsoft but we think this is particularly important as it's the advisory that provides official information for those assessing risk to their organizations.

Updated to add: Microsoft has updated their advisory. Our latest post has the details.

On 19/07/10 At 03:56 PM