KdReserved0 is my fault
If you haven’t read https://medium.com/@pyrojoe314/the-hardest-month-of-work-in-my-life-ms10-015-5c408ad6cc06 or
https://medium.com/@pyrojoe314/my-first-professional-public-speaking-experience-b385869a84e9 they are the prequels to this. At this point in October 2010, I’m still a Microsoft SDE II with only 4 years of experience.
After my Virus Bulletin talk on Alureon getting into the 64-bit Windows kernel and bypassing Code Integrity, I was pushing hard for us to prioritize getting our kernel scanning working on 64-bit. I was told to back up my asks with data. I pointed to the historical efficacy of this malware family spreading, their clear development skill, and that Win7 was heading toward 50% x64, but I was told that wasn’t hard data.
The problem was, getting the hard data was just as expensive from a development standpoint as building detection. Unlike TDL3, TDL4 wasn’t leaving an obvious telltale in user land, which meant no exploratory kernel scanning and no data on prevalence.
Come December, I get a ping from someone on the WinSE team. We’d been working together on doing app-compat tests with prevalent rootkits for kernel patches since MS10–015. We wanted to avoid that happening again. He told me the highest non-graphics driver crash we had telemetry for was likely TDL4 and OEMs were getting concerned. I had my data.
It was TDL4, and it was bad. This malware family was officially on Microsoft’s s**t list before that. The problem was, at the time, code integrity was not considered a security boundary. The other problem was it was an MBR based rootkit, so even the earliest Defender could run, we couldn’t get out in front of it. (This is part of the inspiration of ELAM on UEFI.) Our hands were a bit tied. We couldn’t pull a Kaspersky and do direct IDE I\O to the MBR then force reboot. The Windows kernel team would have shown up with torches and pitchforks.
We needed a way to get in front of this, and I realized that the malware was relying on the size of kdcom.dll’s export table to infect it from the MBR. Hence KdReserved0. A new export that did nothing other than break the malware load chain.
Saying this patch was controversial is an understatement. MSRC insisted that this could not be a security patch because Code Integrity on x64 was not considered a security boundary. WinSE wanted this thing gone because OEMs were getting very concerned about it.
The compromise was KB2506014. It fixed as much of the boot-loader as was possible without requiring a FIPS recertification of Windows 7, while also adding KdReserved0 so that MSRT could clean up as much TDL4 as possible. The patch had some of the most confused framing of a Windows patch. It was a reliability patch, that addressed a security issue, but was not a security patch. It knocked out ~70% of the botnet, so I’m not going to get too grumpy about semantics.
A lot more improvements in code integrity went into Windows 8. Test signing didn’t go away, but a lot of the other paths did. Also the original Windows on ARM for the first Surface had user mode code integrity hardened against a similar attack on smss.exe.
Nothing here was a perfect solution. But that’s the nature of complex software, and trying to secure it. What happened was that a number of people that cared deeply about customers figured out the best solution they could given technical and business limitations. It wasn’t perfect, but it’s what we could do.
