Blogs & Stories

SpiderLabs Blog

Attracting more than a half-million annual readers, this is the security community's go-to destination for technical breakdowns of the latest threats, critical vulnerability disclosures and cutting-edge research.

Backward Compatibility Plays to Malware’s Hands

Maintaining backward compatibility in software products ishard. Technology evolves on a daily basis, and while it feels "right" to goahead and ditch the old technology in favor of the new, it sometimes mightcause issues, especially when a software platform which millions of developers developfor is in question. However, it turns out that the desire of software vendorsto keep backward compatibly is abused by malware authors.

Let's have a look at a piece of malware recently spotted inthe wild:


Most of you will find it familiar, since it is the latest MSXML Core Services vulnerability (CVE-2012-1889) along with the notoriousheaplib which became popular once more thanks to this vulnerability. But wait,something is weird about this snippet from heaplib… look at the if-elsestatement at the beginning of the screenshot – it was modified from theoriginal version and now has those semicolons. So why did the malware authorsput them there?

Let's have a look at a simpler case:


All modern browsers consider this code as an invalidJavaScript, and won't execute even a single line of it. IE, on the other hand,considers this as a perfectly legitimate JavaScript, and will execute the alertfunction with x=3.

So why did the malware author modify heaplib like this? Itshould be quite clear now that:

  1. It can be used as anevasion technique and avoid running unnecessary heap spraying on browsers thataren't relevant to this specific CVE.
  2. It can be used as a methodto trick various dynamic analysis engines such as Wepawet and JS-Unpack. Suchengines usually handle well only strict JavaScript, based on the RFC, withoutvendor quirks.

Great, so we know what the problem is, and what it is goodfor, but what about a solution?
We tried to get an answer from MS regarding why would IE allow such syntax forJavaScript, and were responded that it is supported in IE versions <9 and inthe compatibility mode of 9 and 10. Since the compatibility mode can be easilyrequested by the page (X-UA-Compatible), even users who use the most modernversion of Microsoft's browsers are still vulnerable to this trick.

We learn 2 things from this event:

  1. Straying too far away fromstandards and supporting all sorts of quirks not only can, but will, turn into asecurity risk.
  2. Malware authors continuewith their efforts to not only discover new vulnerabilities, but also to find interestingways to evade security engines.

Unfortunately, it is not possible to force IE to use thestandards mode for internet sites, so our best advice for IE users would be tokeep the system up-to-date with the latest security updates at all times.