10 ms·

Zero-day in jQuery plugin sample code exploited for at least three years

216 points by john37386 8y ago

based2 8y ago
https://www.bleepingcomputer.com/news/security/jquery-file-upload-plugin-vulnerable-for-8-years-and-only-hackers-knew/ https://www.bleepingcomputer.com/news/security/jquery-file-u...
based2 8y ago
https://github.com/blueimp/jQuery-File-Upload/commit/aeb47e51c67df8a504b7726595576c1c66b5dc2f https://github.com/blueimp/jQuery-File-Upload/commit/aeb47e5...
blueimp 8y ago
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/13931c7e4f7113c7b6832fe6d9abe0edf627ab3d#diff-4ea7e687ccf6a97c37a1a198b894aae1 https://github.com/blueimp/jQuery-File-Upload/commit/13931c7... - 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/41750323a464e848856dc4c5c940663498beb74a https://github.com/blueimp/jQuery-File-Upload/commit/4175032... The App Engine components had an open redirect vulnerability back in 2015: https://github.com/blueimp/jQuery-File-Upload/commit/f74d2a8c3e3b1e8e336678d2899facd5bcdb589f https://github.com/blueimp/jQuery-File-Upload/commit/f74d2a8...
- aw3c2 8y ago
  Don't beat yourself up. Your response shown here is insightful and reasonable. Well done!
  - blueimp 8y ago
    Thanks a lot!
- wolco 8y ago
  Relying on apache version specific defaults is always the wrong approach. But everything else can be avoided with a whitelist of acceptable types by default.
- willeh 8y ago
  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.
  - ChrisSD 8y ago
    I'm not going to throw stones either. But I would encourage developers to make their sample code robust. Especially as > many PHP users are hobbyists or come from a more traditional "webmaster" background I seem to remember a somewhat related problem with WordPress. The issue there was made worse by the fact the sample code was part of the default install and so available to anyone who knew the URL. Edit: A quick search shows I was thinking of an XSS attack. It was due to some bad example code in the default theme folder, which is by default publicly accessible even if not used. https://arstechnica.com/information-technology/2015/05/actively-exploited-wordpress-bug-puts-millions-of-sites-at-risk/ https://arstechnica.com/information-technology/2015/05/activ...
yebyen 8y ago
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 8y ago
  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.
  - subcosmos 8y ago
    It's almost like he had JQuery selectors deep within his DNA! He was BORN to find this bug. The prophecy is true!
  - blueimp 8y ago
    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. ;)
    - da_chicken 8y ago
      > Would definitely write another security vulnerability into my code again if I knew that Larry would report it. ;) Yet more proof that social media will bring the Internet down!
    - lcashdol 8y ago
      Thanks, :-)
- galori 8y ago
  https://news.ycombinator.com/item?id=18271880 https://news.ycombinator.com/item?id=18271880
galaxyLogic 8y ago
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?
- CharlesW 8y ago
  > If so then how can something on the client-side compromise the security of a server? This is answered in the plug-in author's thorough note, posted a couple hours before you posted this.
- blueimp 8y ago
  For a breakdown on how this could happen, please see my comment here: https://news.ycombinator.com/item?id=18267309 https://news.ycombinator.com/item?id=18267309
- runn1ng 8y ago
  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.
vel0city 8y ago
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?
- ccnafr 8y ago
  They disabled per-folder .httaccess files for performance reasons. Also for security, as it allowed server owners to control the entire server via global configs and prevent badly coded CMSs and plugins from opening security holes and bypassing stronger server-wide rules.
- __david__ 8y ago
  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.
john37386 8y ago
So this afect only apache? Anyone have any thoughts on nginx, IIS and other web servers like tomcat, websphere?
- danielhlockard 8y ago
  Does NGINX, IIS, Tomcat, etc support .htaccess? No.
- blueimp 8y ago
  Please refer to the vulnerability documentation here to see if you are affected: https://github.com/blueimp/jQuery-File-Upload/blob/master/VULNERABILITIES.md#remote-code-execution-vulnerability-in-the-php-component https://github.com/blueimp/jQuery-File-Upload/blob/master/VU...
lcashdol 8y ago
Larry Cashdollar here. I don’t blame the author either. None of the folks including my self knew .htaccess support was no longer default.
solidr53 8y ago
Hey Larry $$
- dang 8y ago
  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.
fulafel 8y ago
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 8y ago
  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 8y ago
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 8y ago
  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.
londons_explore 8y ago
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 8y ago
  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.
jpic 8y ago
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 8y ago
  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
paulie_a 8y ago
In 2018 Apache, phone and jQuery is a doormat saying "please hack my servers"
Assossa 8y ago
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 8y ago
  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.

216 points by john37386 8y ago

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

based2 8y ago

https://github.com/blueimp/jQuery-File-Upload/commit/aeb47e51c67df8a504b7726595576c1c66b5dc2f https://github.com/blueimp/jQuery-File-Upload/commit/aeb47e5...

blueimp 8y ago

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/13931c7e4f7113c7b6832fe6d9abe0edf627ab3d#diff-4ea7e687ccf6a97c37a1a198b894aae1 https://github.com/blueimp/jQuery-File-Upload/commit/13931c7... - 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/41750323a464e848856dc4c5c940663498beb74a https://github.com/blueimp/jQuery-File-Upload/commit/4175032... The App Engine components had an open redirect vulnerability back in 2015: https://github.com/blueimp/jQuery-File-Upload/commit/f74d2a8c3e3b1e8e336678d2899facd5bcdb589f https://github.com/blueimp/jQuery-File-Upload/commit/f74d2a8...

aw3c2 8y ago
Don't beat yourself up. Your response shown here is insightful and reasonable. Well done!
- blueimp 8y ago
  Thanks a lot!
wolco 8y ago
Relying on apache version specific defaults is always the wrong approach. But everything else can be avoided with a whitelist of acceptable types by default.
willeh 8y ago
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.
- ChrisSD 8y ago
  I'm not going to throw stones either. But I would encourage developers to make their sample code robust. Especially as > many PHP users are hobbyists or come from a more traditional "webmaster" background I seem to remember a somewhat related problem with WordPress. The issue there was made worse by the fact the sample code was part of the default install and so available to anyone who knew the URL. Edit: A quick search shows I was thinking of an XSS attack. It was due to some bad example code in the default theme folder, which is by default publicly accessible even if not used. https://arstechnica.com/information-technology/2015/05/actively-exploited-wordpress-bug-puts-millions-of-sites-at-risk/ https://arstechnica.com/information-technology/2015/05/activ...

yebyen 8y ago

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 8y ago
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.
- subcosmos 8y ago
  It's almost like he had JQuery selectors deep within his DNA! He was BORN to find this bug. The prophecy is true!
- blueimp 8y ago
  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. ;)
  - da_chicken 8y ago
    > Would definitely write another security vulnerability into my code again if I knew that Larry would report it. ;) Yet more proof that social media will bring the Internet down!
  - lcashdol 8y ago
    Thanks, :-)
galori 8y ago
https://news.ycombinator.com/item?id=18271880 https://news.ycombinator.com/item?id=18271880

galaxyLogic 8y ago

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?

CharlesW 8y ago
> If so then how can something on the client-side compromise the security of a server? This is answered in the plug-in author's thorough note, posted a couple hours before you posted this.
blueimp 8y ago
For a breakdown on how this could happen, please see my comment here: https://news.ycombinator.com/item?id=18267309 https://news.ycombinator.com/item?id=18267309
runn1ng 8y ago
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.

vel0city 8y ago

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?

ccnafr 8y ago
They disabled per-folder .httaccess files for performance reasons. Also for security, as it allowed server owners to control the entire server via global configs and prevent badly coded CMSs and plugins from opening security holes and bypassing stronger server-wide rules.
__david__ 8y ago
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.

john37386 8y ago

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

danielhlockard 8y ago
Does NGINX, IIS, Tomcat, etc support .htaccess? No.
blueimp 8y ago
Please refer to the vulnerability documentation here to see if you are affected: https://github.com/blueimp/jQuery-File-Upload/blob/master/VULNERABILITIES.md#remote-code-execution-vulnerability-in-the-php-component https://github.com/blueimp/jQuery-File-Upload/blob/master/VU...

lcashdol 8y ago

Larry Cashdollar here. I don’t blame the author either. None of the folks including my self knew .htaccess support was no longer default.

solidr53 8y ago

Hey Larry $$

dang 8y ago
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.

fulafel 8y ago

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 8y ago
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 8y ago

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 8y ago
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.

londons_explore 8y ago

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 8y ago
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.

jpic 8y ago

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 8y ago
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

paulie_a 8y ago

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

Assossa 8y ago

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 8y ago
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.