Zimbra Collaboration Suite warning: Patch this 0-day right now (by hand)!

Popular collaboration product Zimbra has warned customers to apply a software patch urgently to close a security hole that it says “could potentially impact the confidentiality and integrity of your data.”

The vulnerability is what’s known as an XSS bug, short for cross-site scripting, whereby performing an innocent-looking operation via site X, such as clicking through to site Y, gives the operator of site X a sneaky chance to implant rogue JavaScript code into the web pages that your browser receives back from Y.

This, in turn, means that X may end up with access to your account on site Y, by reading out and perhaps even modifying data that would otherwise be private to Y, such as your account details, login cookies, authentication tokens, transaction history, and so on.

The abbreviation XSS is a self-descriptive name, because the roguery essentially involves pushing untrusted scripts across from one site into the otherwise-trusted content of another site…

…all without needing to break into the other site in advance to hack its HTML files or JavaScript code directly.

Patched but not published

Although the bug has now been patched in Zimbra’s code, and the company says that “it has applied this fix to the July release”, it hasn’t yet published that version.

But the patch turns out to be urgent enough to be needed right away, because it was spotted in a real-life cyberattack by a security researcher at Google.

That makes it a dreaded zero-day exploit, the jargon term used for security holes that the Bad Guys find first and keep to themselves.

Zimbra has therefore warned its customers to apply the fix themselves by hand, which requires a single-line edit to a single data file in the product’s installation directory.

Zimbra didn’t quite use Naked Security’s very own rhyming reminder of Do not delay/Do it today, but the company’s techies said something with the same level of urgency in their own official security bulletin:

Take Action. Apply Fix Manually.

We understand that you may want to take action sooner rather than later to protect your data.

To maintain the highest level of security, we kindly request your cooperation to apply the fix manually on all of your mailbox nodes.

XSS explained

Simply put, XSS attacks usually involve tricking a server into generating a web page that trustingly includes data submitted from outside, without checking that the data is safe to send directly to the user’s browser.

As curious (or as unlikely) as this might sound at first, remember that repeating or reflecting input back into your browser is perfectly normal, for example when a site wants to to confirm data you’ve just entered or to report the results of a search.

If you were browsing a shopping site, for instance, and you wanted to see if they had any Holy Grails for sale, you’d expect to type Holy Grail into a search box, which might end up being submitted to the site in a URL like this:

https://example.com/search/?product=Holy%20Grail

(URLs can’t contain spaces, so the space character between the words is converted by your browser into %20, where 20 is the ASCII code for space in hexadecimal.)

And you wouldn’t be surprised to see the very same words repeated in the page that came back, for example like this:

You searched for:

     Holy Grail

Sorry. We don't have any in stock.

Now imagine that you tried searching for a bizarrely-named product called a Holy<br>Grail instead, just to see what happened.

If you got back a page something like this…

You searched for:

   Holy
Grail

Sorry. We don't have any in stock.

…instead of what you’d expect, namely…

You searched for:

   Holy<br>Grail

Sorry. We don't have any in stock.

…then you’d immediately know that the server at the other end was being careless with so-called “special” characters such as < (less-than sign) and > (greater-than sign), which are used to specify HTML commands, not merely HTML data.

The HTML sequence <br> doesn’t literally means “display the text less-than sign letter-b letter-r greater-than sign“, but is instead an HTML tag, or command, that means “insert a line break at this point”.

A server that wants to send your browser a less-than sign to print on the screen needs to use the special sequence < instead. (Greater-than signs, as you can imgaine, are encoded as >.)

Of course, this means that the ampersand character (&) has a special meaning, too, so ampersands-to-be-printed-out have to be encoded as &, along with double-quote marks (") and single-quotes or apostrophe marks (').

In real life, the problem with cross-site-scriptable output trickery is not “mostly harmless” HTML commands such as <br>, which disrupts the page layout, but dangerous HTML tags such as <script>, which allow you to embed JavaScript code right there, directly in the web page itself.

Once you’ve spotted that a site doesn’t handle searching for <br> properly, your next attempt might be to search for something like Holy<script>alert('Ooops')</script>Grail instead.

If that search term is returned precisely as you sent it over in the first place, the effect will be to run the JavaScript function alert() and to pop up a message in your browser saying Ooops.

As you can imagine, crooks who discover how to poison websites with trial alert() popups quickly switch to using their new-found XSS hole to perform much more devious operations.

These may include retrieving or modifying data relevant to your account, sending messages or authorising actions in your name, and perhaps grabbing hold of authentication cookies that will let the criminals themselves log directly back into your account later on.

Incidentally, the one-line patch you’re urged to apply in the Zimbra product directory involves changing an item in a built-in web form from this…

<input name="st" type="hidden" value="${param.st}"/>

…into a safer format, so that the value field (which will be sent to your browser as text but never shown, so you won’t even know it’s there while accessing the site) is constructed as follows:

<input name="st" type="hidden" value="${fn:escapeXml(param.st)}"/>

This new-look line tells the server (which is written in Java) to apply the security-conscious Java function escapeXml() to the value of the stfield first.

As you’ve probably guessed, escapeXml() ensures that any lefover <, >, &, " and ' characters in a text string are rewritten in their correct and XSS-resistant formats, using <, >, &, " and ' instead.

Safety first!

What to do?

Follow the hand-patching instructions on Zimbra’s website.

We’re assuming that companies that run their own Zimbra instances (or pay someone else to run them on their behalf) won’t find the patch technically complex to perform, and will quickly create a custom script or program to do it for them.

Just don’t forget that you need to repeat the patching process, as Zimbra reminds you, on all your mailbox nodes.