As a part of the April's "Patch Tuesday", Microsoft released a fix for the MS12-024 / CVE-2012-0151 vulnerability.
This issue was discovered and researched by us; we have been in contact with Microsoft engineers for the past few months to fix this problem. The aim of this blog post is to explain the problem, the risks, and possible consequences of the fix.
The title of CVE-2012-0151 is "WinVerifyTrust Signature Validation Vulnerability". Now, what is this special "WinVerifyTrust" thing? It is a part of the operating system which is responsible for the verification of digital signatures. So, when somebody - be it the operating system itself, an application wanting to check its integrity, or the user manually checking a file’s integrity from the Properties tab - wants to validate a file, this is the piece of code that gets called to process the digital signature. The processing consists of two steps; the first step is to make sure that the file hasn't been tampered with. The code applies complex mathematical algorithms to verify that the file has not been modified in any way, and the file is exactly the same as it was at the moment it was signed. When this is confirmed, the second step is to check whether the particular signer is actually trusted by the system. The system’s certificate store is consulted and the chain of trust is verified.
However, as it turns out, there is a problem in the first step. A signed executable can be modified in such a way that it uses/executes a modified (and possibly malicious) part of the code, yet the file’s signature still remains valid. This destroys the key property of digital signatures - ensuring that a signed file has not been tampered with.
So, what are the consequences? Are digital signatures really that critical? Signing of executable files has become more and more important in the past years; many programs and services have gone online, the amount of malicious files on the Internet has grown vastly, and the social engineering techniques attempting to deliver those files to the victims have only improved. Digital signatures make it possible to distinguish between files coming from trusted sources and those faked by a malicious attacker. In 64bit editions of Windows operating systems, Microsoft has gone even further by enforcing special signing of driver files, with the goal of preventing installation of anonymous/unauthorized kernel code into new systems. (Note that we did not find any evidence that this discussed vulnerability also affects driver verification code - it seems to be safe.)
When you download a file from the Internet and try to run it, or when the UAC prompt appears announcing that a program needs to be run with administrator privileges, the digital signature is checked and the name of the signer is displayed. However, if you cannot be sure that the file is genuine, you can't really say “this file comes from the company I trust, it's OK to run it". Or, to reverse the situation, if a fake file is signed by a known company and you are presented with that information by the operating system itself, there is a very good chance that you will fall for that trap and run the file – a much higher probability than if the file was signed by somebody unknown or wasn't signed at all. So this vulnerability gives malware authors a chance to increase the perceived trustworthiness of their creations, and subsequently increase their distribution.
Another possible scenario is an Evilgrade-style attack. Many current applications (browsers, browser add-ons, PDF readers, Java, Windows itself) automatically check online for their updates - which is good, because it speeds up fixing of other vulnerabilities found in those programs. When an update is found, it's downloaded, verified, and finally installed. Why the verification step? First, to make sure there wasn't any corruption during the file download, and second to check that there wasn't any network redirection (either local, such as a HOSTS file hijack, or remote - by an evil ISP or hacked router) and if the file wasn't actually downloaded from a completely unrelated location.
How do they do such verification? Yes, checking the digital signature of the downloaded file is a natural choice. But, if it’s possible to fake the content of the file and keep the digital signature valid... we have a problem; imagine a rogue ISP serving fake browser updates to all the connected clients, installing arbitrary code on their machines. This rogue "ISP" might range from a simple WiFi hotspot placed in a public place to a whole country with the government controlling the Internet connectivity - and trying to get into the people's computers as well.
Even security products themselves might be affected. Checking the digital signature of a file and assigning that file a certain level of trust according to the outcome - that’s a fairly common practice. Applications signed by specific trusted vendors might get whitelisted - either for certain operations or completely. But of course, it's imperative that the file in question really originates from the expected vendor; if it was modified by a 3rd party, the trust is unjustified.
As we can see in the few examples above, not being able to trust digital signatures of executable files can be a serious problem. So, what now? The patch is released, everyone installs it and we are back in the world where all is fine again? Well... mostly. The thing is that there are multiple ways to modify signed executables. Some of them can be easily detected because the resulting files are so twisted that no one would ever create such a file without actually trying to exploit the vulnerability. Others are harder to avoid because they are not enabled by any bug in Windows code - they are partly a design flaw (and since we are talking about the format of executable files and digital signatures, it’s something that cannot be easily changed because it would invalidate millions of signed executables out there), and partly a bug in the modifiable executables themselves (i.e. a problem in those 3rd party applications susceptible to this kind of attack). And while the patch tries to do its best to prevent even those harder-to-detect methods, there likely are some applications out there that still can be tampered with while keeping their signature valid.
We have not found any malware using this vulnerability prior to the release of the patch (we have run multiple probes across our 150m+ strong user base to get some intelligence on that). However, we have discovered a few companies that use it in their legal (non-malicious) files - most likely to avoid repetitive signing. Those companies might be in for a little surprise - because their files won't be signed anymore after the patch is installed (i.e. the signature on these files won't be verified on systems where the patch is present). This is not to say that you shouldn't install the patch - you certainly should! The files in question are not "properly signed" anyway.
To conclude - you can never be too careful when it comes to downloading and installing programs. Even a digital signature by someone you trust doesn't give a 100% assurance that the file is safe. The reason doesn't even have to be the vulnerability discussed here - the signing certificate may have been stolen, the company computers may have been infected by a virus that embedded itself into the file before the signing, a certificate authority may have been hacked and a fake signing certificate created by the attacker; we have seen all of those. So, don't download files from suspicious sources, always double check where you download files from, keep your system up-to-date - and use a good antivirus that protects your computer from similar attacks.
