
Zero-day in jQuery plugin sample code exploited for at least three years - john37386
https://www.zdnet.com/article/zero-day-in-popular-jquery-plugin-actively-exploited-for-at-least-three-years/
======
lcashdol
Larry Cashdollar here. I don’t blame the author either. None of the folks
including my self knew .htaccess support was no longer default.

------
blueimp
Author of jQuery File Upload here.

The vulnerability is a combination of Apache v.2.3.9's default setting to not
read .htaccess files and my mistake of relying on .htaccess to enforce
security of the sample PHP upload component.

To give you some context on how this could happen:

\- As the project name implies, this started as a client-side jQuery plugin,
with a dummy PHP script to echo out the uploaded file

\- Over time, I added a couple of sample server-side upload components,
including two for Google App Engine (Python + Golang) - which I used for the
demo - and one for PHP, which I never used myself in production

\- I used the PHP component for local tests with various possible file
uploads, including very large files and chunked uploads, which required
enabling all file types for upload. My thinking was that allowing all file
types for upload is not critical as long as the handling of those files is
properly configured.

\- Prior to adding the .htaccess file, I mistakenly assumed developers would
configure their Apache server themselves so that no PHP scripts would be
executed in the uploads folder. It was only added in this commit:
[https://github.com/blueimp/jQuery-File-
Upload/commit/13931c7...](https://github.com/blueimp/jQuery-File-
Upload/commit/13931c7e4f7113c7b6832fe6d9abe0edf627ab3d#diff-4ea7e687ccf6a97c37a1a198b894aae1)

\- The Apache servers I tested with always had support for .htaccess enabled,
so I never bothered to check that the default Apache configuration since
version 2.3.9 actually disabled it

\- The original .htaccess configuration didn't even prevent script execution
in all Apache configurations and had to be fixed, see:
[https://github.com/blueimp/jQuery-File-
Upload/pull/3381](https://github.com/blueimp/jQuery-File-Upload/pull/3381)

Looking back, there are a couple of things that I should have done
differently:

\- Move out the server-side components into separate repositories

\- Inform users better about file upload security - see
[https://github.com/blueimp/jQuery-File-
Upload/wiki/Security](https://github.com/blueimp/jQuery-File-
Upload/wiki/Security)

\- Never assume people actually read information about security

\- Never rely on .htaccess for security configurations in Apache

\- Make sure that published code is secure in all default configurations

\- Never allow all file types for upload by default, even if it is secure in
your configuration

\- Recommend users to not upload files in the same root as their executable
web application

\- Always follow security best practices, even if it makes setup for users
more difficult

I wanted to make it really simple for users to install a generic and secure
file upload service with a great user interface. Unfortunately, security best
practices and ease-of-use are often at odds to each other.

Bonus info:

The client-side component had a cross-site scripting vulnerability in the
Iframe Transport HTML site back in 2012: [https://github.com/blueimp/jQuery-
File-Upload/commit/4175032...](https://github.com/blueimp/jQuery-File-
Upload/commit/41750323a464e848856dc4c5c940663498beb74a)

The App Engine components had an open redirect vulnerability back in 2015:
[https://github.com/blueimp/jQuery-File-
Upload/commit/f74d2a8...](https://github.com/blueimp/jQuery-File-
Upload/commit/f74d2a8c3e3b1e8e336678d2899facd5bcdb589f)

~~~
willeh
I really don't blame the author here, sure there was an issue with the sample
code - but come on it was sample code. If someone is implementing user uploads
they should really do the due diligence and understand what the sample code
does.

To be honest I'm not really that surprised that the vulnerability stayed
hidden for so long; many PHP users are hobbyists or come from a more
traditional "webmaster" background. This is not to say that there aren't good
PHP programmers, just that there is a large group of novices.

~~~
blihp
It wasn't exactly hidden seeing as how there was a YouTube video titled
'Exploit jQuery File Upload Vulnerability' available since 2015. I don't blame
the author (given the timing of the Apache change it probably would have been
easy for him to overlook[1]) and it is surprising that this took years for
anyone to make him aware of the issue since the exploit wasn't exactly
unknown. Apparently there's some groundbreaking work left to be done in
infosec searching on combinations of various library / application names and
'exploit'...

[1] I assume that like most of the rest of us he was lagging behind the latest
and greatest Apache release a bit. So when he was writing/testing this, it
probably wouldn't have been an issue.

~~~
blueimp
Unfortunately, I never tested it with an Apache configuration that had
.htaccess support disabled and so it simply did not occur to me that the
default was "off".

I think the bigger issue was that the PHP sample code allowed all file types
by default - this would not only affect Apache, but any Webserver that had
broad rules to execute PHP scripts found in a directory.

Originally I didn't see this as an issue as I trusted developers to securely
configure their server to make sure no uploaded files would be executed, which
is why the .htaccess security settings were only added later in this commit:
[https://github.com/blueimp/jQuery-File-
Upload/commit/13931c7...](https://github.com/blueimp/jQuery-File-
Upload/commit/13931c7e4f7113c7b6832fe6d9abe0edf627ab3d#diff-4ea7e687ccf6a97c37a1a198b894aae1)

But neither was the documentation informing developers clearly enough about
the security implications, nor should I have relied on people actually reading
security notices.

~~~
blihp
Fair enough... but I still don't blame you ;-)

~~~
blueimp
Hehe, thanks! :)

------
yebyen
OK. I'll be that guy. Is there nobody who is going to talk about Larry
Cashdollar, the person who discovered this vulnerability and first reported
it?

I'm honestly not sure how I'd be more impressed; if you told me this man
actually uses this as his real name in his daily life, or by finding out that
this is actually his birth name.

~~~
hlieberman
He's a former co-worker of mine, and is an awesome dude in many ways.

His name really is Larry Cashdollar, born and raised. Sometimes I wrote his
name as 'Larry $$' though.

~~~
blueimp
Larry was also super helpful in identifying the underlying issue and very
polite in his emails.

Would definitely write another security vulnerability into my code again if I
knew that Larry would report it. ;)

~~~
lcashdol
Thanks, :-)

------
galaxyLogic
Isn't a JQuery Plugin something that executes on the client-side? If so then
how can something on the client-side compromise the security of a server?
Isn't the fault on the server-side?

Or is this a PHP server-plugin which if installed on a PHP server makes them
insecure? But of course anything you install on server can make it insecure.
No?

~~~
runn1ng
There is an example PHP code in the same repo and people copy-pasted that into
production.

The issue is not in the front-end jQuery library, despite the title.

------
fulafel
What other vulnerabilities did this backwards-incompatible Apache change
cause? Probably many people rely on .htaccess, for example to disable access
to non-public files or disable php execution on a DIY CMS file sharing area.

Sounds like the risk from this is not widely known. Probably the correct
solution for Apache would have been to detect presence of now-ignored
.htaccess files and signal an error.

~~~
blueimp
That was my thought as well.

I think one of the reasons nobody reported this earlier was that people simply
assumed that .htaccess support was the default - Larry Cashdollar, the
security researcher, also confirmed this:
[https://news.ycombinator.com/item?id=18271880](https://news.ycombinator.com/item?id=18271880)

------
xab9
Isn't this a click-baitish title? I would say that this is a configuration
issue and not "exactly" a vulnerability and basically get off my lawn.

Reading blueimp's and larry's comments here I envy their constructivity, open
mindedness and professionalism.

~~~
blueimp
Thanks! Comments like yours are what keeps me motivated to continue
contributing to open source software.

But although the title is somewhat click-bait, I still think this counts as a
vulnerability in my project, since there is a possible combination of default
Apache setting and default project files that is exploitable.

------
jpic
Another apache disaster, blueimp's plugin has nothing to do with it: it's
common for script kiddies to try to upload php executables on php sites, and
sometimes it works.

~~~
blueimp
I do think that my project is responsible and not Apache, since I provided
sample code that was not secure by default when used in a default Apache
configuration as is.

However I wish Apache would have changed their default config in a way that
would have signalled an error if an .htaccess file is present but not applied.

Something that HA user fulafel also pointed out here:
[https://news.ycombinator.com/item?id=18272407](https://news.ycombinator.com/item?id=18272407)

------
based2
[https://github.com/blueimp/jQuery-File-
Upload/commit/aeb47e5...](https://github.com/blueimp/jQuery-File-
Upload/commit/aeb47e51c67df8a504b7726595576c1c66b5dc2f)

------
vel0city
Can someone share some information on the reasoning behind httpd's default
handling of htaccess files? How does ignoring a security feature that many
relied on improve security?

~~~
__david__
I suspect it's so that a user can't accidentally make security worse by
fiddling with security settings that they don't understand. That said, I
might've considered turning any page that had the disabled .htaccess settings
into a 500 response instead of just keeping on like everything is working
fine.

------
londons_explore
Haven't seen this sample code, but in general letting your users set the
filename of anything on your server is a bad plan.

If the upload script just generated a random filename (046359905445.bin), and
then stored the mime type, users filename, other metadata, etc. in a database,
that would be a much better design.

~~~
blueimp
I agree with you that this would be the safer route. For a production file
upload service, file uploads should ideally stored in a specialized blob
store, e.g. Amazon S3 or Google Cloud Storage.

However the PHP code was written as easy-to-use sample code and I did not want
to introduce a database as dependency and keeping the sanitized filename plus
extension keeps the meta information intact.

If I had provided better information about how to securely configure the
Webserver to allow all file types for upload, using the original - but
sanitized - filenames would not be an issue.

------
john37386
So this afect only apache? Anyone have any thoughts on nginx, IIS and other
web servers like tomcat, websphere?

~~~
blueimp
Please refer to the vulnerability documentation here to see if you are
affected: [https://github.com/blueimp/jQuery-File-
Upload/blob/master/VU...](https://github.com/blueimp/jQuery-File-
Upload/blob/master/VULNERABILITIES.md#remote-code-execution-vulnerability-in-
the-php-component)

------
Assossa
I'm curious as to how this could be a widely known exploit in the hacker
community, but no one reported it until 3 years after its publicity.

~~~
jpic
It's not 3 years old, we've been exploiting it when we were 14 yr old trying
to find server to host warez content, and has nothing to do with the plugin
itself: it's all about apache's mod_php configuration: does it allow execution
of php files that are in the directory where users upload their avatar ? If
yes, then they can try to upload a php script and execute it on the server.

------
paulie_a
In 2018 Apache, phone and jQuery is a doormat saying "please hack my servers"

------
based2
[https://www.bleepingcomputer.com/news/security/jquery-
file-u...](https://www.bleepingcomputer.com/news/security/jquery-file-upload-
plugin-vulnerable-for-8-years-and-only-hackers-knew/)

------
solidr53
Hey Larry $$

~~~
dang
Please don't post unsubstantive comments here.

Don't you think maybe he's heard this a few times already?

We detached this comment from
[https://news.ycombinator.com/item?id=18271880](https://news.ycombinator.com/item?id=18271880)
and marked it off-topic.

