Release announcements, Security

Zulip 2.0.7 security release

Tim Abbott • 3 min read

We released Zulip Server 2.0.7 today. This is a security release, containing a handful of cherry-picked changes since Zulip 2.0.6.

What’s new

This release fixes an important security bug in previous versions of Zulip. Quoting from the commit fixing it:

CVE-2019-18933: Fix insecure account creation via social authentication.

A bug in Zulip's new user signup process meant that users who
registered their account using social authentication (e.g. GitHub or
Google SSO) in an organization that also allows password
authentication could have their personal API key stolen by an
unprivileged attacker, allowing nearly full access to the user's
account.

Zulip versions between 1.7.0 and 2.0.6 were affected.

This commit fixes the original bug and also contains a database
migration to fix any users with corrupt `password` fields in the
database as a result of the bug.

Out of an abundance of caution (and to protect the users of any
installations that delay applying this commit), the migration also
resets the API keys of any users where Zulip's logs cannot prove the
user's API key was not previously stolen via this bug.  Resetting
those API keys will be inconvenient for users:

* Users of the Zulip mobile and terminal apps whose API keys are reset
  will be logged out and need to login again.
* Users using their personal API keys for any other reason will need
  to re-fetch their personal API key.

We discovered this bug internally and don't believe it was disclosed
prior to our publishing it through this commit.  Because the algorithm
for determining which users might have been affected is very
conservative, many users who were never at risk will have their API
keys reset by this migration.

To avoid this on self-hosted installations that have always used
e.g. LDAP authentication, we skip resetting API keys on installations
that don't have password authentication enabled.  System
administrators on installations that used to have email authentication
enabled, but no longer do, should temporarily enable EmailAuthBackend
before applying this migration.

Installations with certain common configurations of AUTHENTICATION_BACKENDS (in /etc/zulip/settings.py) are not affected by this vulnerability. In particular, this issue does not affect installations where:

  • EmailAuthBackend is not enabled in AUTHENTICATION_BACKENDS.
  • EmailAuthBackend is the only backend enabled in AUTHENTICATION_BACKENDS.

Other installations should upgrade promptly.

This release also contains some hardening changes to help prevent bugs like this from being introduced in the future.

As a sidenote, we expect Zulip 2.1 to be released soon after Thanksgiving, with hundreds of new features and other changes.

Upgrading

All installations should upgrade promptly to secure their installations. See the upgrade instructions in the Zulip documentation.

If you’re upgrading from 2.0.x, then the code changes are small and there are no migrations or dependency changes, so the risk of unexpected disruption is low. If you’re upgrading from an older version, we recommend upgrading directly to this latest release.

If you’re running a fork of master, you will need to rebase your fork to get these fixes.

If you need help, best-effort support is available on chat.zulip.org, the Zulip community chat server.

Community

We love feedback from the Zulip user community. Here are a few ways you can connect: