MS Task Scheduler Vulnerability Used by Stuxnet Worm To Obtain Administrator System Privileges
( MS10-092, CVE-2010-3888 )
Summary
The Stuxnet worm, which has received extensive media coverage over the last few months, is one of the most sophisticated malware programs ever created. It uses a number of vulnerabilities in Microsoft Windows, some of which were unreported prior to the Stuxnet outbreak. One of those vulnerabilities is in the Windows Task Scheduler. Stuxnet exploits this issue in order to gain elevated system privileges on the system(s) under attack, ultimately resulting in Administrator privileges on the targeted system.
Discussion
Check Point security researcher Ravit Greister recently interviewed one of her fellow researchers, Tomer Teller, about this vulnerability. Here are some highlights from that interview.
Tomer, please explain how the vulnerability works and how a local user can trigger it.
![]() |
Tomer Teller |
The vulnerability is due to a hash collision in the CRC32 algorithm. This hash function is designed to detect accidental changes to raw computer data and is prone to collisions. When we're talking about collisions, we're referring to a situation where two distinct pieces of data have the same hash value. Under the hood, the Task Scheduler saves a file with the Task information and user context into the disk and hashes it using the CRC32 algorithm. Any modification made to that file changes its hash value. An unprivileged user could modify the file's user context from Guest to LocalSystem and "pad" it to cause a collision. This tricks the Task Scheduler into thinking that this is the original Task file, resulting in enhanced user permissions.
Is there any kind of mitigation for this vulnerability?
There is no really good way for IPS to detect such vulnerabilities since it is a design flaw that does not result in an application crash. A good mitigation would be to disable the Task Scheduler Service under the registry until a patch is available.
How was the Scheduler flaw used by the Stuxnet worm? Has this been used by worms before?
Stuxnet was the first worm to introduce this vulnerability. In order to infiltrate deeper into the system, Stuxnet had to run as a privileged user. The worm scheduled a task in the Task Scheduler, and then exploited the hash algorithm to run itself with LocalSystem privilege.
What are your thoughts about where the security exploit market is headed?
Design flaws of this kind seem to attract a lot of attention in the security community since they are usually very reliable in terms of exploitation and most importantly do not leave a noticeable trace. This allows worm writers to stay under the radar for the long term. My prediction is that we will see more and more sophisticated worms coming our way.
Afffected Products
Windows Vista, Windows 7, and Windows Server 2008 R2 are vulnerable to this exploit.
Solution
Check Point recommends applying the patch for this issue as detailed in MS10-092 as soon as is practical.
Originally Published:
Last Updated: 14-Dec-2010
