A Lesson in Why “Security by Press Release” Is Detrimental
Last week “news” broke about a 3-year old jQuery vulnerability that was just discovered, and had just been patched. On the surface, it sounded like a big (and new) deal — and, if you were just reading through reports and articles, it might have felt like there was an immediate threat to your systems, if you were using this jQuery plugin.
The reality is quite different. While we acknowledge the popularity of this plugin in GitHub and that there are number of code forks involved, this potential vulnerability has been known for some time — and for those properly managing their supply chains, has been fix-able for some time.
This is why security by press release can be so detrimental. Often, only the more ubiquitous vulnerabilities with higher severity scores make the news — or get passed around more broadly — around their initial discovery. If you’re following this mentality of only looking at high profile vulnerabilities — then yes, you may have missed CVE-2018–9206.
That said, as this vulnerability was identified so long ago, even those organizations who are slower to follow some of the public CVE disclosures — likely knew about this. Which brings us to the second reason this is so detrimental to highlight and over-hype now — it’s causing a false sense of urgency and taking security and developers away from “fighting” emerging vulnerabilities.
With all of this in mind, looking at this particular jQuery vulnerability (CVE-2018–9206), it’s also important to understand the complexity of the elements necessary for a bad actor to execute an attack.
It is a misconception that allowing the upload of arbitrary files by themselves results in a security vulnerability. How you allow servers to handle the execution of those files is just as important. This particular attack requires two vectors.
In this case, executing an attack is a combination of using a version of Apache that allows for a default override of a previously more secure configuration, combined with a server misconfiguration that currently relies or previously relied on that more secure Apache configuration. The potential to attack requires both the Apache default configuration and a server misconfiguration in order to make this attack possible.
In other words, it’s more complicated than just having a vulnerable component or allowing an upload of arbitrary files. Another fact that articles didn’t share completely.
Moreover, the PHP code lacking the checks for file types and the server configurations (
.htaccess) was sample code bundled with the component, as a mere example. The component’s source code itself is not vulnerable. It is prudent to note that even for the component versions deemed “vulnerable” by the advisory, not all of these versions provided in npm downloads contain the vulnerable sample code.
That said, successful execution of this attack could result in backdoors and other programs that allow hackers access to sensitive data and the ability to execute and run malicious files on the server.
What is the best remediation path if you are vulnerable?
First and foremost, proper configuration is essential.
Apache v.2.3.9 changed a security setting (
AllowOverridewas set to
None by default) that removed the more secure default configuration of
.htaccess. Since the jQuery File Upload PHP implementation relied on that
.htaccess support, it opened up a vulnerability.
- Upgrade to the latest version of jQuery File Upload v 9.24.2*
- Configure your web server so it will not execute files in the upload directory and make sure it has
- If you are running Apache v 2.3.9, don’t allow it to run with
None, and ensure that an
.htaccessfile is present in the “uploads” directory preventing file execution.
*Upgrading alone will not solve the problem for the npm versions of this component. According to Sonatype’s Advisory Deviation it is clear that the vulnerable Sample Code is not even provided with the versions starting 9.14.0 in npm downloads. Server configuration and any additional restrictions enforced by the server-side code (e.g. to verify uploaded file extensions, preventing execution of the uploaded files, etc.) would be the remediation.
DevOps-native organizations with the ability to continuously deploy software releases have an automation advantage that allows them to stay one step ahead of the hackers. Customers of Sonatype, if impacted by this vulnerability, were alerted within days.
If you’re not a Sonatype customer, and want to quickly find out if you’re using the vulnerable version of Apache in a specific application, you can use Sonatype’s free Nexus Vulnerability Scanner to quickly find out.