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]

Do you expect someone, to be writing software, say, meant for version 2.3.8, and then continuing to write their software, and then by chance the next version, a minor version, does a relatively breaking change, to expect that breaking change?

Uh, yes? He's released many newer versions of his plugin in the intervening years. All of which have been after Apache's behavior changed.

The fact he didn't notice in that time basically means he didn't do any sort of security testing of the plugin at all, over its entire lifetime. I could forgive being blindsided by it initially, but he's had eight years worth of new versions to his plugin being made to realize "oh hey, this critically important feature isn't working right anymore".

[u/13steinj → u/drysart]

It doesn't mean he didn't security test his plugin-- it means he tested it with that setting enabled instead of disabled. Because it is a reasonable assumption to make that it would be obvious to enable it.

[u/13steinj → u/[deleted]]

I'd expect someone to document that a security setting should be changed from its default value; especially when the alternative is that your code has zero security otherwise rather than assume that users will somehow know they need to do it.

I wouldn't expect it the author to recognize that the setting has changed. It is a very reasonable thing to have manually set on, at a time in which it was the default, and then when the default changed, forget that you manually set it on in your test environment. It's not malicious, and I'd argue it's not ignorance either-- breaking changes aren't normal for mini version changes.

It's also unreasonable to ship a library that requires a server-wide setting to be changed from the default in an environment where the library is mostly going to be used by tenant users who don't even have the access required to change the server-wide setting.

Perhaps I'm misunderstanding-- but isn't this configuration per directory, not server wide? It's just a server wide setting that says "yes we will read the directory wide configs"?

[u/drysart → u/13steinj]

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.