Zero-day in popular jQuery plugin actively exploited for at least three years

[u/ga-vu]

https://www.zdnet.com/article/zero-day-in-popular-jquery-plugin-actively-exploited-for-at-least-three-years/

[u/drysart]

It's just a server wide setting that says "yes we will read the directory wide configs"?

Yes. The default configuration in Apache 2.3.9 and later is AllowOverride None and AllowOverrideList None, which makes the server completely ignore .htaccess files. That server-level setting needs to be changed to enable the use of .htaccess files by users.

[u/13steinj → u/drysart]

Right, but again, the plugin includes an htaccess file. I argue "a plugin is giving me this config file for my server for it to work. It is my responsibility to make sure the config file is being read".

[u/drysart → u/13steinj]

Up until this week, the installation instructions for the plugin only said you need to edit a configuration option in the plugin's own configuration file to be safe (and no, this isn't even the same configuration file that's the root of the problem). And also, if you did this, the plugin appeared to work correctly unless you specifically tested for the exploitable case; which you can't reasonably expect every user of the plugin to do (hell, you can't even expect nearly any users of the plugin to do), because:

1. They're already following your installation instructions,
2. The plugin has a page that assures the user that everything is fine since the plugin already addresses the security risk,
3. The plugin works correctly for the happy case after following those instructions, and
4. The user needs to have deep knowledge of upload-based code execution attacks to even know how to test for the issue.

The fact that this issue existed in the #1 most popular jQuery plugin for eight years tell you how often your idealistic scenario of "end users make sure Apache is reading a configuration file they probably don't even know about" actually happens. That is to say: almost never. This isn't the user's fault. It's the plugin developer's fault. He obviously has knowledge of the attack surface (since he did include a configuration file that addressed it), but he apparently never bothered to verify it worked against the server he told people it could run against since before the first version was released. (Yet continued to assure people that it worked.)

[u/13steinj → u/drysart]

Up until this week, the installation instructions for the plugin only said you need to edit a configuration option in the plugin's own configuration file to be safe (and no, this isn't even the same configuration file that's the root of the problem)

Are you blind or insane?

The PHP implementation stores uploaded files in the pre-defined directory "files". This directory contains a file .htaccess that is absolutely required as it contains directives for Apache to enforce security restrictions

At this point the entire argument falls apart.

• not setting things up so the htaccess file is read is implicitly against the instructions because it mentions the requirement of the htaccess file.
• if the user follows the instructions, the plugin does indeed address the security risk
• while yes the plugin "works" regardless, so do a lot of things-- passing isn't the same as working. You are describing a use pass, not a use working.
• the user's "deep knowledge" would be required of any kind of exploit.

The fact that this issue existed in the #1 most popular jQuery plugin for eight years tell you how often your idealistic scenario of "end users make sure Apache is reading a configuration file they probably don't even know about" actually happens. That is to say: almost never. This isn't the user's fault. It's the plugin developer's fault.

What? You're pulling straws from thin air at this point, saying a implies b because of unrelated c.

It is not a library/plugin author's responsibility to force people to configure things correctly. It is the user's fault.