22 Oct

Security Issues Related to jQuery File Upload Not Unknown To InfoSec Community As Security Journalists Claim

We generally avoid following news coverage of web security since it is of such poor quality and when we do have to look at examples of it due to a news alert we have to keep track of vulnerabilities in WordPress that view is reinforced. Take this post on ZDNet’s Zero Day blog, “Zero-day in popular jQuery plugin actively exploited for at least three years“, by Catalin Cimpanu, which makes this claim:

It is pretty clear from the videos that the vulnerability was widely known to hackers, even if it remained a mystery for the infosec community.

That would news to us since we were aware that there are security issues related to how others implement usage of the software jQuery File Upload for years. One such example of was with the WordPress plugin Creative Contact Form, which was disclosed in October of 2014.

The post goes on to claim it was a secret:

The vulnerability was one of the worst kept secrets of the hacker scene and appears to have been actively exploited, even before 2016.

Again this isn’t a secret, it has been well known, it just wasn’t known to the source of the post, Larry Cashdollar. That is someone that we have seen disclosing real vulnerabilities, but also doesn’t always provide accurate information. Just last month after he incorrectly claimed that vulnerabilities in a WordPress plugin had been fixed, we brought that to his attention on Twitter, but we never got a response, which isn’t a great indication of his concern for accuracy and seems like a good reason he shouldn’t be a sole source for a journalist, as he was here.

The Zero Day blog isn’t the only source spreading this false information, Ionut Ilascu at the Bleeping Computer wrote “jQuery File Upload Plugin Vulnerable for 8 Years and Only Hackers Knew“, which makes this false claim:

Of the thousands of plugins for the jQuery framework, one of the most popular of them harbored for at least three years an oversight in code that eluded the security community, despite public availability of tutorials that explained how it could be exploited.

.htaccess Files Haven’t Been Disabled

Making it seem worse to rely solely on Larry Cashdollar, based on what wrote on the blog of his employer Akamai, you can see he doesn’t have a great understanding of how web servers are normally configured and therefore why what he is claiming is at issue with that library isn’t all that accurate, as he writes this:

After comparing our test configurations over email we soon realized that the Apache maintainers disabled support for .htaccess since Apache version 2.3.9.  It appears they’ve done this to improve performance as the server doesn’t have to check for this file everytime it accesses a directory. Moreover, the change was made to prevent users from overriding security features that were configured on the server.

So Apache had good reasons to disable .htaccess, but their changes left some developers and their projects open to attack, especially if they relied on .htaccess as a security function.

.htaccess files having been disabling would be news to almost anyone running WordPress website, considering that many of them would no longer be function if that were true. It looks like Larry doesn’t have a good understanding of web hosting and just assumed that it being stated in the Apache documentation,  “This prevents the use of .htaccess files in all directories apart from those specifically enabled.” and “Note that this setting is the default since Apache 2.3.9.”, somehow meant that generally these files are disabled instead of stock configuration limiting where they can be used, which doesn’t apply to how things are normally configured in the real world. That would have been a good reason for journalists to have a second source for their stories on this, something that is true with so many stories where they simply repeat inaccurate claims by security companies or researchers and the end up acting more as stenographer than a journalist.

Instead they repeat this incorrect information, as Michael Heller at TechTarget did:

After Cashdollar reported the jQuery plugin vulnerability to its creator, Sebastian Tschan, the German developer who goes by the nym “Blueimp,” the two worked together and discovered the issue was caused by a change in the Apache HTTPD server. The change was made in Apache version 2.3.9 — made five days before release of the first version of jQuery File Upload in 2010 — and it disabled support for .htaccess web server configuration in order to prevent security features from being overridden. Unfortunately, Tschan’s plugin relied on .htaccess to implement security controls.

The Real Issue

The real issue here, which again has been known, has to do with what types of files can be uploaded, which is a common issue with file upload functionality. That would be something someone implementing the library would want to do, as the types of files they would want to be uploaded would vary. What has been changed though is to limit that to certain types of images by default.

4 thoughts on “Security Issues Related to jQuery File Upload Not Unknown To InfoSec Community As Security Journalists Claim

    • The start of the last paragraph of our post starts “The real issue here” and then goes on to explain what that is, so if someone is saying there isn’t a real issue here, it isn’t us.

  1. Also, if you knew about this vulnerability and didn’t report it as a security company are you being negligent and possibly profiting off of it? If it has been abused for years that seems to obviously indicate there is a problem. One you ignored. I’ve tested what Cashdollar said when I install Apache I need to manually configure .htaccess for it to work. So, it seems the point was that was unknown to the community.

    • You really should pull back from a conspiracy theorizing here. As was mentioned in the post, the issue is with how the library is implemented, so the vulnerability would be in implementation, not the library itself. If there was a vulnerability in a WordPress plugin that we had run across we would have dealt with that, since that is what our service is focused on. For example, back in April of 2016 we looked a situation with a WordPress plugin where there was false claim that there was vulnerability due to this library.

      Also, as was mentioned in the post here is instance from October of 2014 of a vulnerability based on implementation of this library in a WordPress plugin, so it actually was known to the community.

      As to the .htaccess files, again this was explained in the post, but here it is again:

      .htaccess files having been disabling would be news to almost anyone running WordPress website, considering that many of them would no longer be function if that were true. It looks like Larry doesn’t have a good understanding of web hosting and just assumed that it being stated in the Apache documentation, “This prevents the use of .htaccess files in all directories apart from those specifically enabled.” and “Note that this setting is the default since Apache 2.3.9.”, somehow meant that generally these files are disabled instead of stock configuration limiting where they can be used, which doesn’t apply to how things are normally configured in the real world.

      In the future it would help you and others if you read what you are responding to before responding to it.

Leave a Reply

Your email address will not be published. Required fields are marked *