Hey Larry $$
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 and marked it off-topic.
Zero-day in jQuery plugin sample code exploited for at least three years
61–70 of 71 posts
Re: Zero-day in jQuery plugin sample code exploited for at least three years
#62Isn'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.
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.
Re: Zero-day in jQuery plugin sample code exploited for at least three years
#63Haven'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.
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.
Re: Zero-day in jQuery plugin sample code exploited for at least three years
#64Another 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.
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
Re: Zero-day in jQuery plugin sample code exploited for at least three years
#65What 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.
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
Re: Zero-day in jQuery plugin sample code exploited for at least three years
#66So this afect only apache? Anyone have any thoughts on nginx, IIS and other web servers like tomcat, websphere?
Please refer to the vulnerability documentation here to see if you are affected: https://github.com/blueimp/jQuery-File-Upload/blob/master/VU...
Re: Zero-day in jQuery plugin sample code exploited for at least three years
#67Author 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 tim…
are other web servers vulnerable ? for example, wildfly jboss server,??
If the upload directory is securely configured, no.
Please refer to the vulnerability documentation here to see if you are affected: https://github.com/blueimp/jQuery-File-Upload/blob/master/VU...
Re: Zero-day in jQuery plugin sample code exploited for at least three years
#68I'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.
Re: Zero-day in jQuery plugin sample code exploited for at least three years
#69Author 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 tim…
Another one rce: https://blog.vulnspy.com/2018/10/23/jQuery-File-Upload-9-x-R...
Re: Zero-day in jQuery plugin sample code exploited for at least three years
#70I'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.
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.