Release announcements, Security

Zulip Server 12.3 security release

Mateusz Mandera • 5 min read

We released Zulip Server 12.3 today! This is a security release, fixing a critical security issue (GHSA-42mq-rxcr-wj72) and three other security issues, as well as several bugs.

We have requested CVE IDs for these issues, but they have not yet been assigned. Each issue is instead referenced below by its GitHub security advisory.

Upgrading

We recommend that all installations upgrade to this new release. See the upgrade instructions in the Zulip documentation. Zulip Cloud has already been upgraded with the improvements in this release.

Commercial support for server upgrades is available for installations that purchase a Business or Enterprise plan. For community support, everyone is welcome to drop by the Zulip development community.

GHSA-42mq-rxcr-wj72: Sender forgery in group direct messages.

Zulip has long supported mirroring integrations, which relay messages from another chat system, such as IRC, into Zulip on behalf of the users who sent them. A client identifying itself as one of these mirroring clients is permitted to specify the sender of the messages it delivers.

A bug in the Zulip server meant that the access checks on this codepath were not applied to direct messages. Any organization member could use the undocumented API, presenting one of the mirroring client identifiers, to send a group direct message attributed to a different user. The fabricated message was stored and delivered as a normal direct message, displayed under the impersonated person’s name with no indication to recipients that it did not come from them. The same flaw allowed bypassing restrictions on who is permitted to send or initiate direct messages.

This bug affects all versions of the Zulip Server prior to 12.3. It was not possible to exploit through Zulip’s apps, and explicit manipulation of the API was needed. Exploiting it further required the organization to restrict sign-ups to a list of email domains, and only users whose email address is visible to everyone could be forged as the sender. Organizations whose hostname is itself one of those allowed domains are an exception to this email visibility rule: there, senders with restricted email visibility can also be spoofed.

The forged message could only be placed in a conversation that included the attacker, and the vulnerability gave no access to any messages, channels, or other data the attacker could not already see.

A possible mitigation is to explicitly remove the email domains configured for the aforementioned sign-up restriction. The vulnerable mirroring API only accepts a forged sender whose email domain is one of those configured, so with none configured it cannot be used. Note that simply disabling the sign-up restriction by itself is not enough: the configured domains remain in place. Removing the last domain turns the restriction off automatically. To compensate, organizations can require an invitation to join and use email invitations to control which email addresses users can register with.

This vulnerability was discovered by Ada Logics using Google’s security automation tooling. An analysis of Zulip Cloud data did not find any evidence that this vulnerability was exploited against Zulip Cloud customers.

Notable changes

  • GHSA-42mq-rxcr-wj72: Sender forgery in group direct messages.
  • GHSA-7w3h-65w5-m522: When messages were moved from a public channel to a private channel, users who had received those messages in the public channel, but were not subscribed to the private channel, continued to receive the content of later edits to them. Any topic such a user had muted or followed was also carried into the private channel, exposing its ID and the new topic name. The practical impact of this bug was limited by the fact that only a message’s sender can edit its content, and only within the organization’s time limit for doing so (10 minutes by default), so the content leak generally required the move and the edit to happen soon after the message was sent. This vulnerability was discovered in an internal audit and independently reported by @bruhdev1290.
  • GHSA-wj5v-8mqg-gvqw: The typing notifications endpoint did not check whether the sender is allowed to access the recipients, allowing a guest to gain access to the user ID and Zulip API email address of every user in the organization. This issue only impacted organizations that limit user visibility for guests, as otherwise that information is normally accessible. This vulnerability was reported by @JebeenLee.
  • GHSA-3x2r-gh27-7h4f: The CSP violation reporting endpoint logged several attacker-controlled fields verbatim. Since the endpoint is unauthenticated, anyone could forge log entries, inject terminal escape sequences into the server logs, or grow them without bound. This vulnerability was reported by bugwizard12 via our HackerOne program.
  • Added a startup check that the JITSI_SERVER_URL setting is a valid URL; previously, an invalid value caused the web app to fail to load, with no indication of the cause.
  • Fixed incorrect UTC offsets in the time zone picker in personal settings: the offsets did not account for daylight saving time, and were also wrong for time zones with negative fractional-hour offsets (e.g., America/St_Johns).
  • Restored the integration for self-hosted Bitbucket, removed in Zulip 12.0 when Bitbucket Server was discontinued; its successor, Bitbucket Data Center, sends identical webhook payloads, and thus the original integration works with it unchanged.
  • Fixed viewing a message’s edit history in organizations configured to show move history only.
  • Fixed the Mattermost import tool crashing when the export contains channels whose names differ only in capitalization.
  • Updated Python dependencies.

Community

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