Critical security release: Vanilla 2.3.1

Linc

This upgrade includes:

• A critical upgrade to the PHPMailer library to prevent remote code execution.
• Mitigation of a medium-level exploit of the HTTP_HOST header.
• Additional minor fixes I will detail in a comment.

BEFORE making this upgrade:

IF you run Vanilla in an environment where you explicitly declare HTTP_HOST, for example:

• Many nginx server setups
• Using Varnish
• Using a load balancer

READ the new documentation about how to modify your install to accommodate (quoted below).

FAILURE to heed this will result in a BROKEN upgrade to Vanilla 2.3.1 to the point of it being inaccessible via the web.

If you're using a default Apache setup, you are very likely unaffected by this, and in fact the security patch herein is for you most especially.

I apologize for this ungainly preamble, but the public publication of a medium-severity exploit has forced this half-baked workaround out the door immediately.

Download It Now

Use the standard upgrade steps

If upgrading from 2.2 or earlier, see the 2.3 release discussion.

If you have problems upgrading from 2.3, please report them immediately.

Note that neither of these vulnerabilities effected our cloud customers. I include this note because I know some cloud customers do follow this forum. I will explain further why that is in a comment.

Advanced Handling of Headers

To utilize advanced handling of request and networking headers, it is recommended you make the necessary modifications in a bootstrap.before.php file. You may need to create this file in your config folder, if it does not already exist. The contents of this file are executed at the very beginning of Vanilla's bootstrapping process.

If, for example, you wanted to use the Host header from an incoming request to set the host Vanilla sees, you would add the following into bootstrap.before.php:

    if (isset($_SERVER['HTTP_HOST'])) {
        $_SERVER['SERVER_NAME'] = $_SERVER['HTTP_HOST'];
    }

This will overwrite the host set by the server with the value of the Host header. It is crucial to verify the validity of any such data. If you cannot verify the hosts provided in these headers, do not attempt to use them.

Permanent link to these new docs is here: Advanced Handling of Headers

Linc

Just past noon (ET) we were contacted for comment about "vulnerabilities in Vanilla Forums that were apparently reported back in December" by a blog. We were linked to two vulnerabilities that were published sometime today on ExploitBox. We received no advanced warning of their publication. An article was published which falsely implied our cloud customers had open vulnerabilities and were at risk, which has since been amended.

After spending several hours tracking down the relevant communications and talking to folks internally, this was our statement regarding the issue that explains the nature of the issues reported, why there was a delay in releasing fixes, and why cloud was not effected:

You've forwarded two published security vulnerabilities. This is the first we've been made aware of their publication. They both effect our free and open source product. Neither is currently present in our cloud service at vanillaforums.com, nor were they at the time of their publication.

1. A HTTP_HOST vulnerability in Vanilla 2.3.
2. A vulnerability in the version of PHPMailer bundled in Vanilla 2.3.

Golunski contacted us December 22 regarding the HTTP_HOST vulnerability (but did not disclose the specific workflow detailed in the publicly published report - it was discussed only in the abstract). We thanked him for his discretion and investigated the issue. On January 6, we responded with our findings and cautioned that it would take us some time to release a fix due to the complexity of unwinding the use of this server variable without breaking the myriad scenarios it can be used for in open source environments. In the interim, Golunski had expressed a more simplistic view of the issue and was openly impatient with us. We received no further communication from the researcher after our explanation and request for time, nor prior to its publication.

While a developer was already assigned and working on a careful general-case fix, we are not ready to move forward with said fix and this publication has forced our hand. We will issue a new version that simply strips its use, making it inappropriate for some setups which will also likely confuse the messaging around its release. The HTTP_HOST vulnerability never effected our cloud service.

Golunski mentioned our PHPMailer library should be updated once in the middle of the communication chain about the HTTP_HOST vulnerability over the holidays. It was filed as a developer issue and patched, but a workflow error on our part caused us to miss following thru with a new public release (it remained conflated with the unresolved HTTP_HOST issue). We will expedite said release now, as we would have done had any followup been made by Golunski. Again, our cloud service was not vulnerable, having naturally received an update to PHPMailer last year as part of our transition to Composer-based dependencies.

We believe these publications were hostile to the users of our free and open source software. Both the updated version of PHPMailer and the potentially breaking change to the use of HTTP_HOST will shortly be made available in a new open source version, Vanilla 2.3.1. The same outcome could have been achieved with sufficient communication.

Linc

If you are using master branch from git, please note the HTTP_HOST patch is not included in it yet. This is because we are still working on a nicer fix and/or our own internal systems have not yet been amended per the documentation above (a final decision about this hasn't been made yet).

Anyone who is using these headers safely (as our cloud service is) can continue doing so without the patch included in 2.3.1. Anyone using master already had the remaining patches in this release.

In any case, the worst scenario the researcher could come up with for this vulnerability was sending a password reset email to a user with the incorrect domain set in the (text) link, which is why it was graded as only "medium".

Linc

Other fixes that were queued for release that are now in 2.3.1:

• Validate redirects during registration to prevent malicious redirection.
• Upgrade importer's use of mysql module to mysqli.
• Assign "Unconfirmed" role to new users if confirmation is required.
• Update links and calls to vanillaforums.org (now open.vanillaforums.com).
• Add xf12 password authentication method for XenForo imports.
• Add support for 'sso' parameter redirects.
• Remove dead link from writable config prompt during install.

Linc

The critical security flaw in PHPMailer was already not present in the 2.4 prerelease. If you are using 2.4a, you may continue doing so. To close the HTTP_HOST flaw if you're not sanitizing HTTP_HOST already (as described above), see this patch to make the fix yourself for now. We'll have an updated release soon.

Gillingham

There seems to be no upgrade script in this release, /index.php?p=/utility/upgrade returns a view not found error.
unzip -l 2ZCYQN977HZZ.zip | grep upgrade also results in nothing.

Looks like this is maybe an outstanding issue after seeing https://open.vanillaforums.com/discussion/33236/github-upgrading-instructions-are-incorrect#latest , the responses there seem regardless the documentation is wrong here.

Linc

The endpoint /utility/update is canonical.

I'm unclear why the /utility/upgrade alias is used in the docs and why it isn't functioning in 2.3, but the correct solution is always to use /utility/update. I've amended the README on master.

donovanb

Can we ignore copying over the 'plugins' and 'themes' directory for this fix?

Linc

@donovanb said:
Can we ignore copying over the 'plugins' and 'themes' directory for this fix?

Yes.

donovanb

Thx.. successful update. Just an FYI, make sure your file permissions are correct. I had to do:
chmod -R g-w *.php

donovanb

Maybe OT.. but could you briefly describe 'Add support for 'sso' parameter redirects.'? thanks!

JasonBarnabe

@Linc said:
IF you run Vanilla in an environment where you explicitly declare HTTP_HOST, for example:

• Many nginx server setups

Can you elaborate on this point? Do you mean if I'm doing something special in my nginx config that uses HTTP_HOST, or do you mean something that nginx may be doing without me having configured it?

Linc

@JasonBarnabe said:
Can you elaborate on this point? Do you mean if I'm doing something special in my nginx config that uses HTTP_HOST, or do you mean something that nginx may be doing without me having configured it?

If you are blindly accepting the HTTP_HOST header from the request and setting it as a server variable, you are susceptible.

If you are setting the HTTP_HOST server variable from a white list / manually to the correct value, you are not susceptible.

If you have a default nginx installation and are unsure which category you fall in, assume you are in the former category and need this patch.

Linc

@donovanb said:
Maybe OT.. but could you briefly describe 'Add support for 'sso' parameter redirects.'? thanks!

Yes, I am tracking down what the change was with the developer who made it and will update this Monday.

review

Does upgrading from 2.3 to 2.3.1 change the minimum php version from 5.4 to 5.6?

2.3 says it requires 5.4 here https://open.vanillaforums.com/discussion/32822/vanilla-2-3-is-now-available
but this page https://github.com/vanilla/vanilla#upgrading says 5.6

Linc

@review No, it does not. That is the requirement for the current master branch.

kopna

@Linc

This upgrade includes:

A critical upgrade to the PHPMailer library to prevent remote code execution.
Mitigation of a medium-level exploit of the HTTP_HOST header.
Additional minor fixes I will detail in a comment.

Is it possible to upgrade only that relating to the above? Or need a complete update of all files?
Thank you.

R_J

You can download both versions: 2.3 and 2.3.1 and do a file by file comparison (use a tool like WinMerge for that). Although it would be possible that way to only update the files that have changed, there should be no reason to do so.

The only reason would be that you have changed core files. If you did so, you should try your best to solve this problem as soon as possible.

kopna

@R_J написал:
You can download both versions: 2.3 and 2.3.1 and do a file by file comparison (use a tool like WinMerge for that). Although it would be possible that way to only update the files that have changed, there should be no reason to do so.

The only reason would be that you have changed core files. If you did so, you should try your best to solve this problem as soon as possible.

Indeed, some files are different. I use vanilla 2.3 Does this mean that I can change only those files that have been updated in vanilla 2.3.1?
Thank you

carol3

I have the same thing here...

toolsmythe

The Font/Background color chooser in the text editor doesn't actually do anything.

Oddly, I just noticed as I type this that there's not even a menu choice for that in this forum.