Zulip 2.0.7 security release
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.
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
/etc/zulip/settings.py) are not affected by this vulnerability. In
particular, this issue does not affect installations where:
EmailAuthBackendis not enabled in
EmailAuthBackendis the only backend enabled in
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.
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.
We love feedback from the Zulip user community. Here are a few ways you can connect: