Cut-and-paste component vulnerabilities - A short study of how a handlebars.js vulnerability has spread

Today, we are going to explore a cross-site scripting vulnerability in the popular handlebars library. The handlebars library provides a logicless templating language that enables you to separate the view and the rest of your code. This library is based off of the popular mustache templating language modified by Yehuda Katz, also known as wycats on GitHub. Over 9,000 people have starred handlebars on GitHub but most installations happen via Bower (something we are actively working on supporting in our product).

I will also examine the security impact vulnerability when developers cut-and-paste source code across projects.

This issue at the time of writing like most component security issues does not have a CVE assigned.

Back in August 2015, handlebars was alerted to a security issue in its codebase. The problem was with the escaping of characters and was fixed in this commit.

As you can see above, handlebars was missing the = character.

Handlebars has been downloaded nearly 3.5 million times this month and is used in many applications. In fact, it is also used in our Open community site. We were alerted by Soo Lead Re about this vulnerability. After further investigation, we found that this library is actually used by the underlying framework of open.srcclr.com, Discourse. We privately disclosed the vulnerability to the Discourse team who dealt with it quickly and released a new version, 1.4.3 which contains a backported fix for the issue. Hats off to Discourse who did a great job and another reason we love open-source. We would of course recommend that everybody upgrade to the latest version of Discourse.

If you are a SourceClear user, you are already protected against this issue. You can use our agent or terminal application to detect this vulnerability in your projects. The vulnerability details are available in our catalog.

Given that this issue was fixed in the handlebars codebase in September but was not widely known about, we decided to do further digging into the issue, and find out if there are any other projects which may also be affected by it.

The Problem

My thesis was that it is common practice in JavaScript projects to directly cut-and-paste a library's code into a project rather than using a package manager to organize your dependencies and their versions and as a result, there would be many projects and other libraries which are relying on old versions of files not knowing that it may be vulnerable.

The Investigation

We are constantly examining and researching the latest vulnerabilities in open-source components and have developed back-end tools and process to do that at scale. We will be talking more about that work in the new year but armed with this capability and some good intuition about where to look I set off a research job. When I got results back in this particular case I manually validated that the libraries we flagged as vulnerable were in fact missing the escape characters added by the recent fix but we are working on automating this validation and expect to ship it in the new year. With the experience of our team and tools and our increasing dataset, we are able to ask interesting questions that allow us to find hidden and novel vulnerabilities so you will see more posts like this. Actually, it's working well enough that the problem so far hasn't been in finding vulnerabilities, but in coordinating with developers to patch and disclose them at scale.

Results

I found 39 libraries that were using a vulnerable hard-coded (cut-and-paste) version of handlebars. In looking at the problem I also noted that the mustache package that handlebars was based off recently committed a similar fix.

The characters that Mustache was missing included the backtick ( ` ). Although the backtick might not be immediately seen as a potential security threat, as described in the GitHub Issue the backtick is considered a quoting character in Internet Explorer up until at least version 10, meaning that an attacker could target victims using that specific version of the browser. So not only does this issue affect JavaScript packages, but we have identified this vulnerability in 2 other libraries: a Ruby Gem, and a Java library on Maven Central.

In the spirit of doing the right thing and helping the open-source community we are in the process of privately disclosing these issues to the library owners and we will publish signatures to our vulnerability catalog when they have been patched.

This study is of course only a very small part of a bigger picture that we have seen emerge. Just as using open-source became the new normal, copying slices of vulnerable code or using vulnerable libraries has also become the new normal. The ray of light is that most people aren't actually using the vulnerable parts of the vulnerable libraries and we'll talk more about that this week.