So what is it – ya do here? Allow myself to introduce . . . myself (again).
Okay – if you are still subscribed to this feed – then you probably remember me from back in the day when I was an incident response guy for PSS Security doing detective work helping our customers figure out how they got hacked and offering sage advice on how not to get hacked (again) going forward. I hope that I was able to paint a pretty good picture of what a day in the life of a PSS Security engineer looks like with my previous blog posts and the types of threats facing our customers.
But now for something completely different - I’d like to give you a glimpse into my new life as a member of the SWI Defense team.
SWI or Secure Windows Initiative is a large team made up of various sub-teams within the Security Engineering and Communications division here at Microsoft.
One of SWI’s core responsibilities is developing and enforcing the SDL – Security Development Lifecycle which is our fundamental approach to writing better, more secure software. But in addition to that, members of SWI do everything from helping developers create and use threat models early on in the development life cycle, to performing code reviews, to conducting penetration testing against un-released products, to creating security tools to help us do our jobs better (think fuzzing etc.).
In addition to that proactive work – certain members of SWI work reactively with the MSRC to triage and repro incoming privately reported and publicly disclosed vulnerabilities that they pick up either through the secure@ inbox or via the various lists that the MSRC monitors 24x7. After issues are triaged by SWI and bugs are opened and assigned to the developers responsible for fixing them, my team (SWI Defense) sets out to find ways to mitigate or workaround the reported vulnerability with the interest of protecting customers in the absence of or inability to deploy a security update. On the SWI Defense team we start our investigation very early in the process – sometimes even before the developers have started coding the fix!
What are we ‘investigating’?
We’re looking for ‘mitigating factors’ (i.e. things that may make the vulnerability less severe or non-applicable) and workarounds to help protect you from the reported vulnerability in case it gets exploited or exploit code is released.
How do we do it? There are a variety of things we do. First and foremost we attempt to reproduce the problem (on every supported platform) by creating our own internal repro that we can use for testing. For example, if the problem is with a malformed document or file – we use a hex editor and create a malformed document or file. If the problem requires playing back network traffic – we use internal tools for playing back the required network traffic. Sometimes we are required to abuse an API locally by calling it directly so we may create a local repro tool that can be used to demonstrate the vulnerability. Fully patched undoable Virtual PC images come in quite handy here. After we’ve got our repro sorted out – we start debugging to see what’s going on underneath the covers. Next, after we’ve identified the vulnerable function we start looking for ways we can avoid calling that vulnerable function via source code inspection. For example – suppose the vulnerable function was responsible for logging data – would turning off logging or changing log parameters or formats help avoid the vulnerable code path while allowing the system to remain on-line?
After looking at the code we also look for any configuration changes that can be made to workaround the issue such as stopping services, un-registering COM objects, ACL’ing files, using Software Restriction Policies, filtering ports and a myriad of other techniques that can be applied to given classes of vulnerabilities.
Once we have come up with a list of recommended workarounds and mitigations we provide this data to the MSRC for consideration. Things we come up with may eventually be placed in a Security Advisory or a Security Bulletin (or both) (or neither if deemed too risky).
Have we had any success? Absolutely. J Take a look at most of the security bulletins released this year and you will find a non-empty ‘workarounds’ section under ‘Vulnerability Details’ in the bulletin.
It’s important to note that some security updates contain fixes for multiple issues. These issues are assigned CVE identifiers and are noted in the bulletin. We attempt to provide workarounds and mitigations for *each* critical or important CVE listed in the bulletin (in other words workarounds are per-important/critical vulnerability – not per-bulletin).
Let’s have a look at some of the security bulletins released in 2005
Here’s an issue I worked on shortly after starting the job:
This was a privately reported vulnerability whereby an attacker could send you a file and if you attempted to open it, the Windows shell could be tricked into running MSHTA.EXE which would then process some malicious script embedded in the file to run code of an attacker’s choice in the context of you.
We discovered a fairly easy and safe workaround for this one.
You can see the workaround by drilling down to ‘Vulnerability Details à Windows Shell Vulnerability à Workarounds for Windows Shell vulnerability’ section of the bulletin.
It was as simple as temporarily un-registering MSHTA.EXE (until the update can be applied, and then re-registering it after the update is applied) using a single command line. Oh and the workaround was easy to undo - just re-register MSHTA using a similar command. J
In our testing we also discovered an interesting ‘mitigating factor’ for this vulnerability. You could only exploit the vulnerability by sending a user a document that wasn’t already a registered file type (i.e. a .DOC file would not work since .DOC is registered by default to either WordPad or Word, but a .ROB file would probably work since there is no .ROB file association by default). This information also made it into the mitigating factors part of the bulletin to help administrators understand the threat a bit better.
Another great example is http://www.microsoft.com/technet/security/Bulletin/MS05-025.mspx
There were two vulnerabilities addressed in this bulletin – one was rated critical (the PNG issue) and one was rated ‘moderate’ (the XML info disclosure issue).
When investigating the PNG issue we discovered that the root cause of the vulnerability was in a COM object shipped with IE used for processing PNG files so we tested un-registering the DLL (temporarily) and we also tested putting a Software Restriction Policy on it to prevent it from being loaded and sure enough either of these workarounds allow you to workaround the vulnerability in the absence of the security update.
More recently we also provided the MSRC with numerous workarounds for the vulnerability having to do with the JView Profiler COM object and Internet Explorer. These workarounds were listed in both the security advisory (initially) and then in the security bulletin when it was released:
There are 6 workarounds documented in the bulletin for this issue.
As a customer – would you rather be told ‘install the security update’ or ‘well you can install the security update – or you can evaluate any of the 6 workarounds we came up with and tested to see if they are appropriate for your environment while you test the security update in a non-production environment’? I think I know the answer. Recently I noticed that there are not a lot of vendors providing this level of detail in their security bulletins. Some vendors are providing workarounds and mitigations in their security alerts/advisories/bulletins while others still are not. For a more thorough look at how our security bulletins compare to some of our competitors check out the ‘Security in Operation’ series of articles from Jeff Jones – you can find part 1 here.
So do we test the workarounds we come up with? Absolutely.
We do functional testing to ensure the workaround actually works but we can only perform very limited if any application compatibility testing. We try to document known app-compat issues where possible but there are likely issues we cannot foresee.
Are workarounds as safe to deploy as the eventual security update? Probably not.
Security updates undergo considerably more testing (of all kinds) than the workarounds we come up with and as such workarounds should be carefully considered before deployment. Workarounds should never be used indefinitely in place of the security update.
That’s it for now . . .