MS10-015 may cause Windows XP to blue screen (but only if you have malware on it)
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
Comments
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 :)
Jeff
Feb 19th 2010
1 decade ago
http://isc.sans.org/tools/hashsearch.html
Daniel Hoffman
Feb 19th 2010
1 decade ago
dad7732
Feb 20th 2010
1 decade ago
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.
Ottmar Freudenberger
Feb 20th 2010
1 decade ago
PeterB
Feb 21st 2010
1 decade ago
-------------------
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).
Bitwiper
Feb 21st 2010
1 decade ago