MS08-050 concerns an ActiveX control that can be maliciously scripted to leak out personal information such as email addresses.
There appeared to be no need for the control to have this behaviour so giving it a Kill-Bit seemed the correct approach to take. During the extensive testing that each security update undergoes, however, it became apparent that the Kill-Bit wasn’t ideal as it partially broke the Remote Assistance application.
So how do we kill off a control, keep the Remote Assistance functionality and still protect our customers?
Firstly the original control must receive a Kill-Bit to prevent the control being foisted on to users.
Secondly the control was modified so that when it initializes it first checks to see what process it’s running within. If the process attempting to invoke the control is Remote Assistance (1) or if the caller is in a white list of applications found in the registry (2), then the control is permitted to be loaded. Otherwise it will not load.
Finally we issue a Phoenix-Bit (AlternateCLSID) so that Remote Assistance can continue to use the old ClassID.
1 “%SystemRoot%\pchealth\helpctr\binaries\helpctr.exe”
2 “HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths\ImageName\” Where ImageName is the name of the executable that is to be added to the list (e.g. foo.exe), has the value “AllowMessengerExecHandleFailure” of type DWORD and the data set to 1
- Security Vulnerability Research & Defense Bloggers
*Postings are provided “AS IS” with no warranties, and confers no rights.*