Further details on Critical Security Update in Synapse affecting all versions prior to 0.34.1 (CVE-2019-5885)

On Thursday Jan 10th we released a Critical Security Update (Synapse 0.34.0.1/0.34.1.1), which fixes a serious security bug in Synapse 0.34.0 and earlier.  Many deployments have now upgraded to 0.34.0.1 or 0.34.1.1, and we now consider it appropriate to disclose more information about the issue, to provide context and encourage the remaining affected servers to upgrade as soon as possible.

In Synapse 0.11 (Nov 2015) we added a configuration parameter called “macaroon_secret_key” which relates to our use of macaroons in authentication. Macaroons are authentication tokens which must be signed by the server which generates them, to prevent them being forged by attackers. “macaroon_secret_key” defines the key which is used for this signature, and it must therefore be kept secret to preserve the security of the server.

If the option is not set, Synapse will attempt to derive a secret key from other secrets specified in the configuration file. However, in all versions of Synapse up to and including 0.34.0, this process was faulty and a predictable value was used instead.

So if, your homeserver.yaml does not contain a macaroon_secret_key, you need to upgrade to 0.34.1.1 or 0.34.0.1 or Debian 0.34.0-3~bpo9+2 immediately to prevent the risk of account hijacking.

The vulnerability affects any Synapse installation which does not have a macaroon_secret_key setting. For example, the Debian and Ubuntu packages from Matrix.org, Debian and Ubuntu include a configuration file without an explicit macaroon_secret_key and must upgrade. Anyone who hasn’t updated their config since Nov 2015 or who grandfathered their config from the Debian/Ubuntu packages will likely also be affected.

We are not aware of this vulnerability being exploited in the wild, but if you are running an affected server it may still be wise to check your synapse’s user_ips database table for any unexpected access to your server’s accounts. You could also check your accounts’ device lists (shown under Settings in Riot) for unexpected devices, although this is not as reliable as an attacker could cover their tracks to remove unexpected devices.

We’ll publish a full post-mortem of the issue once we are confident that most affected servers have been upgraded.

We’d like to apologise for the inconvenience caused by this – especially to folks who upgraded since Friday who were in practice not affected.  Due to the nature of the issue we wanted to minimise details about the issue until people had a chance to upgrade. We also did not follow a planned disclosure procedure because Synapse 0.34.1 already unintentionally disclosed the existence of the bug by fixing it (causing the logout bug for affected users which led us to pull the original Synapse 0.34.1 release).

On the plus side, we are approaching the end of beta for Synapse, and going forwards hope to see much better stability and security across the board.

Thanks again for your patience,

The Matrix.org Team

 

Critical Security Update: Synapse 0.34.0.1/Synapse 0.34.1.1

After releasing Synapse v0.34.1, we have become aware of a security vulnerability affecting all previous versions (CVE-2019-5885). v0.34.1 closed the vulnerability but, in some cases, caused users to be logged out of their clients, so we do not recommend 0.34.1 for production use.

Today we release two mitigating versions v0.34.0.1 and v0.34.1.1. Both versions close the vulnerability and will not cause users to be logged out. All installations should be upgraded to one or other immediately.

  • Admins who would otherwise upgrade to v0.34.1 (or those that have already done so) should upgrade to v0.34.1.1.
  • Admins on v0.34.0, who do not wish to bring in new non-security related behaviour, should upgrade to v0.34.0.1.

You can get the new updates for v0.34.0.1 and v0.34.1.1 here or any of the sources mentioned at https://github.com/matrix-org/synapse. Note, Synapse is now available from PyPI, pick it up here. See also our Synapse installation guide page.

We will publish more details of the vulnerability once admins have had a chance to upgrade. To our knowledge the vulnerability has not been exploited in the wild.

Many thanks for your patience, we are moving ever closer to Synapse reaching v1.0, and fixes like this one edge us ever closer.

Thanks also to the package maintainers who have coordinated with us to ensure distro packages are available for a speedy upgrade!

 

Porting Synapse to Python 3

Matrix’s reference homeserver, Synapse, is written in Python and uses the Twisted networking framework to power its bitslinging across the Internet. The Python version used has been strictly Python 2.7, the last supported version of Python 2, but as of this week that changes! Since Twisted and our other upstream dependencies now support the newest version of Python, Python 3, we are now able to finish the jump and port Synapse to use it by default. The port has been done in a backwards compatible way, written in a subset of Python that is usable in both Python 2 and Python 3, meaning your existing Synapse installs still work on Python 2, while preparing us for a Python 3 future.

Why port?

Porting Synapse to Python 3 prepares Synapse for a post-Python 2 world, currently scheduled for 2020. After the 1st of January in 2020, Python 2 will no longer be supported by the core Python developers and no bugfixes (even critical security ones) will be issued. As the security of software depends very much on the runtime and libraries it is running on top of, this means that by then all Python 2 software in use should have moved to Python 3 or other runtimes.

The Python 3 port has benefits other than just preparing for the End of Life of Python 2.7. Successive versions of Python 3 have improved the standard library, provided newer and clearer syntax for asynchronous code, added opt-in static typing to reduce bugs, and contained incremental performance and memory management improvements. These features, once Synapse stops supporting Python 2, can then be fully utilised to make Synapse’s codebase clearer and more performant. One bonus that we get immediately, though, is Python 3’s memory compaction of Unicode strings. Rather than storing as UCS-2/UTF-16 or UCS-4/UTF-32, it will instead store it in the smallest possible representation giving a 50%-75% memory improvement for strings only containing Latin-1 characters, such as nearly all dictionary keys, hashes, IDs, and a large proportion of messages being processed from English speaking countries. Non-English text will also see a memory improvement, as it can be commonly stored in only two bytes instead of the four in a UCS-4 “wide” Python 2 build.

Editor’s note: If you were wondering how this fits in with Dendrite (the next-gen golang homeserver): our plan is to use Synapse as the reference homeserver for all the current work going on with landing a 1.0 release of the Matrix spec: it makes no sense to try to iterate and converge on 1.0 on both Synapse and Dendrite in parallel. In order to prove that the 1.0 spec is indeed fit for purpose we then also need Synapse to exit beta and hit a 1.0 too, hence the investment to get it there. It’s worth noting that over the last year we’ve been plugging away solidly improving Synapse in general (especially given the increasing number of high-profile deployments out there), so we’re committed to getting Synapse to a formal production grade release and supporting it in the long term. Meanwhile, Dendrite development is still progressing – currently acting as a place to experiment with more radical blue-sky architectural changes, especially in low-footprint or even clientside homeservers. We expect it to catch up with Synapse once 1.0 is out the door; and meanwhile Synapse is increasingly benefiting from performance work inspired by Dendrite.

When will the port be released?

The port is has been released in a “production ready” form in Synapse 0.34.0, supporting Python 3.5, 3.6, and 3.7. This will work on installations with and without workers.

What’s it like in the real world?

Beta testers of the Python 3 port have reported lower memory usage, including lower memory “spikes” and slower memory growth. You can see this demonstrated on matrix.org:

See 10/15, ~20:00 for the Python 3 migration. This is on some of the Synchrotrons on matrix.org.

See ~11/8 for the Python 3 migration. This is on the Synapse master on matrix.org.

We have also noticed some better CPU utilisation:


See 21:30 for the migration of federation reader 1, and 21:55 for the others. The federation reader is a particular pathological case, where the replacement of lists with iterators internally on Python 3 has given us some big boosts.

See 10/15, 4:00.The CPU utilisation has gone down on synchrotron 1 after the Python 3 migration, but not as dramatically as the federation reader. Synchrotron 3 was migrated a few days later.

As some extra data-points, my personal HS consumes about 300MB now at initial start, and grows to approximately 800MB — under Python 2 the growth would be near-immediate to roughly 1.4GB.

Where to from here?

Python 2 is still a supported platform for running Synapse for the time being. We plan on ending mainstream support on 1st April 2019, where upon Python 3.5+ will be the only officially supported platform. Additionally, we will give notice ahead of time once we are ready to remove Python 2.7 compatibility from the codebase (which will be no sooner than 1st April). Although slightly inconvenient, we hope that this gives our users and integrators adequate time to migrate, whilst giving us the flexibility to use modern Python features and make Synapse a better piece of software to help power the Matrix community.

How can I try it?

The port is compatible with existing homeservers and configurations, so if you install Synapse inside a Python 3 virtualenv, you can run it from there. Of course, this differs based on your installation method, operating system, and what version of Python 3 you wish to use. Full upgrade notes live here but if you’re having problems or want to discuss specific packagings of Synapse please come ask in #synapse:matrix.org.

Thanks

Many thanks go to fellow Synapse developers Erik and Rich for code review, as well as community contributors such as notafile and krombel for laying the foundations many months ago allowing this port to happen. Without them, this wouldn’t have happened.

Happy Matrixing,

Amber Brown (hawkowl)

Synapse 0.34.0 released!

Folks this is a big day for us at Matrix Towers, because today we release 0.34.0.

The big news for 0.34.0 is that we now recommend Python 3 for production use and have been running matrix.org under Python 3 for the past month.

Performance improvements have been marked, in some contexts we have seen 50% reductions in RAM and CPU usage. Here are some illustrative graphs to get you going but look out for a dedicated post delving into much more detail on the port. You can also see a Matrix Live interview with the project lead Amber (hawkowl) here.

Matrix.org federation reader workers, the big drops signify roll over to python 3

Synapse master on matrix.org, again the drop in RAM signifies the roll over to python 3

Many thanks to Amber for leading the effort, Rich and Erik for providing support as well as Notafile and Krombel from the community for pushing this effort right from the early days of the project.

If that wasn’t enough, 0.34.0 also all the usual bug fixes and perf improvements. In particular the media repository now no longer fails to decode UTF-8 filenames when downloading remote media and auto joining rooms now work on servers with consent requirements enabled.

As ever, you can get the new update here or any of the sources mentioned at https://github.com/matrix-org/synapse. Note, Synapse is now available from PyPI, pick it up here. Also, check out our new Synapse installation guide page.

In particular, if you want to run Synapse 0.34.0 on Python 3 take a look at the upgrade notes.

 

Synapse 0.34.0 changelog

Synapse 0.34.0 is the first release to fully support Python 3. Synapse will now run on Python versions 3.5 or 3.6 (as well as 2.7). Support for Python 3.7 remains experimental.

We recommend upgrading to Python 3, but make sure to read the upgrade notes when doing so.

Features

  • Add ‘sandbox’ to CSP for media reprository (#4284)
  • Make the new landing page prettier. (#4294)
  • Fix deleting E2E room keys when using old SQLite versions. (#4295)
  • Add a welcome page for the client API port. Credit to @krombel! (#4289)
  • Remove Matrix console from the default distribution (#4290)
  • Add option to track MAU stats (but not limit people) (#3830)
  • Add an option to enable recording IPs for appservice users (#3831)
  • Rename login type m.login.cas to m.login.sso (#4220)
  • Add an option to disable search for homeservers that may not be interested in it. (#4230)

Bugfixes

  • Pushrules can now again be made with non-ASCII rule IDs. (#4165)
  • The media repository now no longer fails to decode UTF-8 filenames when downloading remote media. (#4176)
  • URL previews now correctly decode non-UTF-8 text if the header contains a <meta http-equiv="Content-Type" header. (#4183)
  • Fix an issue where public consent URLs had two slashes. (#4192)
  • Fallback auth now accepts the session parameter on Python 3. (#4197)
  • Remove riot.im from the list of trusted Identity Servers in the default configuration (#4207)
  • fix start up failure when mau_limit_reserved_threepids set and db is postgres (#4211)
  • Fix auto join failures for servers that require user consent (#4223)
  • Fix exception caused by non-ascii event IDs (#4241)
  • Pushers can now be unsubscribed from on Python 3. (#4250)
  • Fix UnicodeDecodeError when postgres is configured to give non-English errors (#4253)

Internal Changes

  • Debian packages utilising a virtualenv with bundled dependencies can now be built. (#4212)
  • Disable pager when running git-show in CI (#4291)
  • A coveragerc file has been added. (#4180)
  • Add a GitHub pull request template and add multiple issue templates (#4182)
  • Update README to reflect the fact that #1491 is fixed (#4188)
  • Run the AS senders as background processes to fix warnings (#4189)
  • Add some diagnostics to the tests to detect logcontext problems (#4190)
  • Add missing jpeg package prerequisite for OpenBSD in README. (#4193)
  • Add a note saying you need to manually reclaim disk space after using the Purge History API (#4200)
  • More logcontext checking in unittests (#4205)
  • Ignore __pycache__ directories in the database schema folder (#4214)
  • Add note to UPGRADE.rst about removing riot.im from list of trusted identity servers (#4224)
  • Added automated coverage reporting to CI. (#4225)
  • Garbage-collect after each unit test to fix logcontext leaks (#4227)
  • add more detail to logging regarding “More than one row matched” error (#4234)
  • Drop sent_transactions table (#4244)
  • Add a basic .editorconfig (#4257)
  • Update README.rst and UPGRADE.rst for Python 3. (#4260)
  • Remove obsolete verbose and log_file settings from homeserver.yaml for Docker image. (#4261)

Synapse 0.33.9 is here!

Well here you are then, the 9th episode in the Synapse 0.33.x series.

Features wise, 0.33.9 contains a change to the way that GDPR consent works under the hood. It is now plumbed in to the login flow (rather than following immediately afterwards) such that it does not inadvertently break on-boarding. This is part of a broader set of changes that span Synapse and Riot to improve initial first impressions of using matrix.

Separately we now have support for room version upgrades which is pre-requisite for rolling out the new state resolution algorithm, come and join us in #teststateresv2:jki.re if you would like to help us test.

Finally we’ve spent a bunch of time further improving perf especially in and around reducing device ids federation traffic.

I know I say it every time, but full python 3 support is really really close now, matrix.org is now running entirely on py3 and seeing some amazing perf improvements – the remaining blocker is getting py3 deb packages ready and then we’ll ship an official python 3 release. There will also be a blog post to explain what we’ve been up to and what to expect perf wise.

As ever, you can get the new update here or any of the sources mentioned at https://github.com/matrix-org/synapse. Note, Synapse is now available from PyPI, pick it up here. Also, check out our new Synapse installation guide page.
 

Synapse 0.33.9 changelog

Features

  • Include flags to optionally add m.login.terms to the registration flow when consent tracking is enabled. (#4004#4133#4142#4184)
  • Support for replacing rooms with new ones (#4091#4099#4100#4101)

Bugfixes

  • Fix exceptions when using the email mailer on Python 3. (#4095)
  • Fix e2e key backup with more than 9 backup versions (#4113)
  • Searches that request profile info now no longer fail with a 500. (#4122)
  • fix return code of empty key backups (#4123)
  • If the typing stream ID goes backwards (as on a worker when the master restarts), the worker’s typing handler will no longer erroneously report rooms containing new typing events. (#4127)
  • Fix table lock of device_lists_remote_cache which could freeze the application (#4132)
  • Fix exception when using state res v2 algorithm (#4135)
  • Generating the user consent URI no longer fails on Python 3. (#4140#4163)
  • Loading URL previews from the DB cache on Postgres will no longer cause Unicode type errors when responding to the request, and URL previews will no longer fail if the remote server returns a Content-Type header with the chartype in quotes. (#4157)
  • The hash_password script now works on Python 3. (#4161)
  • Fix noop checks when updating device keys, reducing spurious device list update notifications. (#4164)

Deprecations and Removals

  • The disused and un-specced identicon generator has been removed. (#4106)
  • The obsolete and non-functional /pull federation endpoint has been removed. (#4118)
  • The deprecated v1 key exchange endpoints have been removed. (#4119)
  • Synapse will no longer fetch keys using the fallback deprecated v1 key exchange method and will now always use v2. (#4120)

Internal Changes

  • Fix build of Docker image with docker-compose (#3778)
  • Delete unreferenced state groups during history purge (#4006)
  • The “Received rdata” log messages on workers is now logged at DEBUG, not INFO. (#4108)
  • Reduce replication traffic for device lists (#4109)
  • Fix synapse_replication_tcp_protocol_*_commands metric label to be full command name, rather than just the first character (#4110)
  • Log some bits about room creation (#4121)
  • Fix tox failure on old systems (#4124)
  • Add STATE_V2_TEST room version (#4128)
  • Clean up event accesses and tests (#4137)
  • The default logging config will now set an explicit log file encoding of UTF-8. (#4138)
  • Add helpers functions for getting prev and auth events of an event (#4139)
  • Add some tests for the HTTP pusher. (#4149)
  • add purge_history.sh and purge_remote_media.sh scripts to contrib/ (#4155)
  • HTTP tests have been refactored to contain less boilerplate. (#4156)
  • Drop incoming events from federation for unknown rooms (#4165)

Synapse v0.33.8 is here!

Wowzers – our 8th dot release for v0.33!

This time we have a bunch of bug fixes and db performance improvements as well as better support for auto-join rooms and the ability for admins to limit who can create rooms aliases.

v0.33.8 also contains more python 3 fixes: we are running most of matrix.org on python 3 as of right now and seeing some pretty impressive performance improvements. Look out for Hawkowl’s write up coming soon.

For those interested in what we are working on right now, take a look at our task board.

As ever, you can get the new update here or any of the sources mentioned at https://github.com/matrix-org/synapse. Note, Synapse is now available from PyPI, pick it up here.

 

Synapse 0.33.8 changelog

Features

  • Servers with auto-join rooms will now automatically create those rooms when the first user registers (#3975)
  • Add config option to control alias creation (#4051)
  • The register_new_matrix_user script is now ported to Python 3. (#4085)
  • Configure Docker image to listen on both ipv4 and ipv6. (#4089)

Bugfixes

  • Fix HTTP error response codes for federated group requests. (#3969)
  • Fix issue where Python 3 users couldn’t paginate /publicRooms (#4046)
  • Fix URL previewing to work in Python 3.7 (#4050)
  • synctl will use the right python executable to run worker processes (#4057)
  • Manhole now works again on Python 3, instead of failing with a “couldn’t match all kex parts” when connecting. (#4060#4067)
  • Fix some metrics being racy and causing exceptions when polled by Prometheus. (#4061)
  • Fix bug which prevented email notifications from being sent unless an absolute path was given for email_templates. (#4068)
  • Correctly account for cpu usage by background threads (#4074)
  • Fix race condition where config defined reserved users were not being added to
    the monthly active user list prior to the homeserver reactor firing up (#4081)
  • Fix bug which prevented backslashes being used in event field filters (#4083)

Internal Changes

  • Add information about the matrix-docker-ansible-deploy playbook (#3698)
  • Add initial implementation of new state resolution algorithm (#3786)
  • Reduce database load when fetching state groups (#4011)
  • Various cleanups in the federation client code (#4031)
  • Run the CircleCI builds in docker containers (#4041)
  • Only colourise synctl output when attached to tty (#4049)
  • Refactor room alias creation code (#4063)
  • Make the Python scripts in the top-level scripts folders meet pep8 and pass flake8. (#4068)
  • The README now contains example for the Caddy web server. Contributed by steamp0rt. (#4072)
  • Add psutil as an explicit dependency (#4073)
  • Clean up threading and logcontexts in pushers (#4075)
  • Correctly manage logcontexts during startup to fix some “Unexpected logging context” warnings (#4076)
  • Give some more things logcontexts (#4077)
  • Clean up some bits of code which were flagged by the linter (#4082)