Update: jQuery UI and CKEditor to Fix Vulnerabilities

[williamrolison]

Hi,

Looks like these forums running on old jQuery UI and CKEditor.

Should upgrade both to Fix Vulnerabilities.

jQuery UI: https://vulners.com/nodejs/NODEJS:127

CKEditor: https://vulners.com/cve/CVE-2018-17960

If not already patched manually.

Forums version: jQuery UI 1.11.4 and CKEditor 4.5.7

Fixed version: jQuery UI 1.12 and CKEditor 4.11.0

Also noticed using old jQuery 2.1.4. Really should update to 2.2.4 to fix bugs.

Thanks,

Will

[number6]

Hi,

Looks like these forums running on old jQuery UI and CKEditor.

Should upgrade both to Fix Vulnerabilities.

jQuery UI: https://vulners.com/nodejs/NODEJS:127

CKEditor: https://vulners.com/cve/CVE-2018-17960

If not already patched manually.

Forums version: jQuery UI 1.11.4 and CKEditor 4.5.7

Fixed version: jQuery UI 1.12 and CKEditor 4.11.0

Also noticed using old jQuery 2.1.4. Really should update to 2.2.4 to fix bugs.

Thanks,

Will

FIRST: Thanks you for the report! We appreciate notices like this! It is also great to have this public so users can see issues like this, and understand we are not interested in hiding them.

There is great value in finding and reporting issues like this. We appreciate the time you took to find and report this.

Next, some details on what we have, where we are, for open discussion, to allow you and users to consider what we are doing, what we have done, and see if anyone has suggestions to a "best" path. (What is "best" really depends on the qualifications and desired goals; use of quotes is meant to illustrate how this word is subjective, and not objective.)

The forum software is provided by a vendor. For JQuery, we have a few options.
We can always serve the "latest" version of JQuery if we rely on external providers. The choices we have are:
* Google
* JQuery
* Microsoft
However, if we do this, then we have at least 2 security risks:
* Anyone at any of these sites as an employee following manager orders, as legally required by government entity, insider at these establishments accidentally or intentionally taking malicious action can all create custom content to be consumed by forums for users, and allow for execution of code by end-users. With sufficiently advanced filtering, it is possible to limit which hosts actually get malicious code, by IP address. All of the same issues presented with "Drive-by-download" attacks become available.
# Mitigation: if we rely on the latest version of jquery as provided by the forum vendor (on disk, served by our server), we have an audit-able, non-changing version of code for reference. It may be older than the latest that can be provided by one of the other 3 vendors, but by providing this ourselves, it denies the above issues from external providers.
* Data-Leakage, Data-Mining, identification of users of DEF CON forums: all of these become possible by relying on external providers
# By serving these by the forums, we risk not having the latest version of code, but avoid leaking to any of these providers the IP addresses of our users.
* The existing "Certificate Authority" (CA) issue is exposed when using external providers. When limiting content to be locally served, it is possible to rely on DNSSEC and cert validation for host and intermediates in chain, and decrease risks associated with "CA" issues. We then make it possible for users that are interested in addressing the "CA" issue to have a much smaller overhead when using these forums if we do not rely on external providers.
* Internal checks for vendor-installed software will report that the OOB upgraded code no longer matches internal checks for vendor-provided files.

Modern web browsers support security enhancement to avoid many XSS issues when web servers provide direction to them on how data is allowed to be passed, considering where a link (FQDN in URL, for example) is allowed to POST/GET content on a user's behalf. We transmit these for browsers to help users of wbe browsers avoid XSS issues. Security-minded users that care about security will have browsers which support these extension.

Functionality:
The vendor provided versions of these are what were used to validate and test forum functions. We have asked for validation tools the vendor uses to validate forum software, but they have declined to provide these to us. With validation tools they use, we could create an internal only test instance, and test the upgrade of things like jquery on our server with their tools, and see if normal forum use or tools are broken as a result of these changes. We can also enable more security extensions and see if we break normal use of the forum software by users. Without these tools, we can only validate the features we can think of testing.

There is always risk of upgrading things like these outside of the vendor dev/testing, that we will expose other fringe bugs not seen anywhere else which impact forum use by users, or expose new security issues.

Considering all of the above, what would you decide?
* Risk using the external providers and all issues included?
* Risk installing upgrades of these outside of vendor dev/test cycle, and possible exposure of new security issues, or bugs which break forum function during DEF CON?
* Rely on existing browser-supported XSS protections for non-local XSS attempts until vendor provides an update they have tested and validated?

These kinds of decision do cause me worry. There is no single correct answer, and often, the only really choice is the "least harmful" when considering many criteria including: security, privacy, function.

Side notes:
We know that the forums include content on served pages, which ask clients to request JS from some other providers, which the software does not support disabling, without altering the vendor provided code. Some examples:
* I think there is a call--out to instant-messenger (IM) services, if you view information about a user which has registered an IM service which supports reporting their status with that IM service as being logged-in or not, so an image/icon can change to inform "you" on their availability through that IM service.
In these cases, a user could block access (such as through 404 in proxy, or host unreachable) to those sites from the forums without breaking "normal" forum function (status for user being logged into those IM services may not work, but blocking access to those won't break forum posting or reading.)

Comment on attacker vs. Defender:
* Attackers have the ground of total certainty in their argument : They claim a site has not upgraded or is vulnerable. This is 100% objective. It can be tested, and confirmed true, or invalidated to be false. This is a great position to be in when arguing. A thing is true or it is not. The world is high-contrast, binary, black-or-white, yes or no, on or off. Those that try to claim a true statement about a vulnerability as false harm their users and reputation. Those that try to use the legal system to silence reporters, demonstrate no care for their users.
* Defenders have almost no certainty in argument : There are almost always some security risk, known or unknown. They usually have to consider service and function with any updates. They often have to run with known issues which have no way to make everyone happy (users to use with features they expect and desire without stuff being broken, CTO and CFO to eliminate liabilities, etc.) Working Defense is not as pretty or certain as offense. Defense is ugly, and subjective, and filled with always worrying the gamble you make is going to be the best for your employer and users. The world is gray, with all shades, it is Real-number, non-boolean values from 0 to 1 with unlimited, precision.