MS10-015 may cause Windows XP to blue screen (but only if you have malware on it)

Published: 2010-02-19
Last Updated: 2010-02-19 01:39:31 UTC
by Mark Hofman (Version: 1)
6 comment(s)

Last week we received quite a number of reports that the patch for MS10-015 was causing XP machines to display the dreaded BSOD (http://isc.sans.org/diary.html?storyid=8209).  The comments of that diary already suggested that the BSOD may have been related to a rootkit on the machine and it looks like this was correct.  If you were infected with the TDL3/TDSS/tidserv AKA Alureon rootkit  and applied the patch, then you would get the BSOD as the patch changed some pointers and the malware now tried to execute an invalid instruction.  

Lucky for us the malware writers have addressed this issue and it shouldn't happen again for those who are newly infected with this particular piece of malware.  A shame really, as  it was a convenient way in which to identify infected machines. If you did get the BSOD on your machine or on machines in your organisation, then you should consider the possibility that the machines are infected.

Marco's page (http://www.prevx.com/blog/143/BSOD-after-MS-TDL-authors-apologize.html ) and the Microsoft page (http://blogs.technet.com/mmpc/archive/2010/02/17/restart-issues-on-an-alureon-infected-machine-after-ms10-015-is-applied.aspx) go into the details.

Mark

 

 

6 comment(s)

Comments

Hmm... Makes me wonder... What if we like running malware? Is there a website I can visit to download the latest version of this rootkit, so I can still apply the patch from Microsoft without running into a blue screen? :)

Just kidding... but on a more serious note: I agree that it's disappointing that the new infections won't display this symptom anymore. It also makes me wonder if the malware (which I have not yet researched) would push its own updates to the infected machines...

Just a thought :)
Maybe Microsoft could smoke out this problem with hashes.

http://isc.sans.org/tools/hashsearch.html
I've been reading a lot info on this subject alluding to the fact that the file ATAPI.SYS was in fact modified by Microsoft and therefore was included in the update. It is this modified file that the rootkit did not recognize as being modified and therefore tried to execute an invalid command that caused the BSOD. My question is, was the ATAPI.SYS file actually modified by Microsoft? Some say it's the rootkig that mod'd the file and thus caused the BSOD. But then why would MS include the file in the update to begin with if it wasn't modified.
@dad7732
There's no new or modified version of atapi.sys included in KB977165. KB977165 includes new versions of the Windows Kernel "only". In fact, there's not even any security update relased by via Windows/Auto Update for Windows XP SP3 which includes a modified version of atapi.sys. Please feel free to follow the (non-clickable) links posted in Mark's article.
So what I assume then is that the rootkit that infected many machines is the vector that changed the first four bytes of atapi.sys and subsequent reboot produced the BSOD? I'm not following this very well. What exactly happened with the update then that was a causitive agent to produce the BSOD? IOW why didn't this BSOD happen prior to the update? Thanks for taking the time to respond.
@PeterB: In my Fri Feb 12 2010, 00:55 comment in http://isc.sans.org/diary.html?storyid=8209 I wrote:
-------------------
The binaries are mostly identical; the malware version has 4 bytes changed at the beginning of the file, while, interestingly, it's version information block has been overwritten with the apparent malware code, probably leaving all original functionality intact.
-------------------
That does not exactly mean the first 4 bytes, but two sets of "vectors" (pointers to functioncode) to probably initialization- and perhaps error handling code. This is a typical method for infecting existing binaries, and is used to get the rootkit started at an early stage during boot. It has nothing to do with the BSOD's.

During boot the kernel loads the atapi.sys driver and starts its inititialization code located in modified atapi.sys (where originally the file's version information was stored). That code bootstraps the actual rootkit (whose code is located elsewhere on disk).

The actual rootkit code hooks (redirects) various other vectors in kernel memory, originally pointing to Microsoft functions, to functions within the rootkit. Sometimes these functions act as full replacements, but mostly they act as pre- and post- processing functions, executed before and after the actual Microsoft code is called.

For example, if a user (or her virus scanner) requests the contents of atapi.sys, then the rootkit will divert to special functionality which returns the contents of the old, original file (cloaked somewhere else on disk), as if it *were* C:\Windows\System32\Drivers\Atapi.sys. The rootkit will not perform such actions for most other files. However in the same way it may choose to hide filesystem and registry entries, or return any desired value. E.g. it acts as a man in the middle between user space and kernel space.

MS10-015 changed the memory locations of various vectors, something the rootkit writers did not anticipate. After installing MS10-015, during the next boot, the rootkit overwrote wrong parts of kernel memory resulting in the BSOD's.

See http://www.symantec.com/connect/blogs/tidserv-and-ms10-015 for a nice writeup (rather technical though).

Diary Archives