Live data from Hacker News

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

zdnet.com

21–30 of 71 posts

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

#21
post #4

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 tim…

> The Apache servers I tested with always had support for .htaccess enabled

For what it's worth, you'll find lots of people disable support for .htaccess for performance reasons.

It's probably less of an issue these days, but if you support .htaccess files, apache reads the .htaccess file for the current directory, and those for every parent directory, and it happens on every single access.

So for example someone accessing http://foo.bar.com/thing/goes/here would cause the webserver to check for and read /thing/goes/.htaccess, /thing/.htaccess and /.htaccess. If you imagine you've done the sensible thing and got your content nicely split out, you can probably see how that can hurt performance. *nix OSs will be smart and cache the content etc. but you're still wasting time on every access making sys calls.

If you put the access rules in the apache config file, everything is set-up at initialisation time and it never has to make further checks.

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

#22
post #14

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.

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.

It's almost like he had JQuery selectors deep within his DNA! He was BORN to find this bug. The prophecy is true!

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

#23
post #18
post #7

Earlier quoted context omitted.

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. Thi…

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 groundbreaki…

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...

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

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

#24
post #21
post #4

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 tim…

> The Apache servers I tested with always had support for .htaccess enabled For what it's worth, you'll find lots of people disable support for .htaccess for performance reasons. It's probably less of an issue these days, but if you support .htaccess files, apache reads the .htaccess file for the current directory, and those for every parent directory, and it happens on every single access. So for example someone acc…

Agreed - in addition to performance issues, there are also security issues if .htaccess support is enabled - because they can override security settings.

Originally the PHP example code didn't have a .htaccess file - I trusted developers that they would configure file uploads securely by themselves, e.g. via Apache configuration files.

The reason I added it was to support developers on shared hosting plans without access to the Apache configuration - something which was very common back then.

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

#25
post #4

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 tim…

Thank you for coming that clear.

Thanks for your comment.

I think in situations like this it's important to take responsibility and provide as much transparency as possible.

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

#26
post #23
post #18

Earlier quoted context omitted.

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 groundbreaki…

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 tr…

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

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

#27
post #14

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.

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.

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. ;)

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

#28

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?

For a breakdown on how this could happen, please see my comment here: https://news.ycombinator.com/item?id=18267309

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

#29
post #26
post #23

Earlier quoted context omitted.

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 tr…

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

Hehe, thanks! :)

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

#30
post #7
post #4

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 tim…

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. Thi…

[deleted]
Post reply on HN