3.2 KiB
+++ date = "2023-08-04T10:30:00Z" title = "Disclosure: Bridges security issues"
[taxonomies] author = ["Integrations Team", "Matrix Security Team"] category = ["Bridges", "Security"] +++
Hi folks. As previously mentioned on Monday, we’re now disclosing the vulnerabilities patched for the IRC, Slack and Hookshot bridges. If you have not already done so, please ensure you are running the patched versions.
Today we are disclosing the 3 vulnerabilities.
matrix-appservice-bridge doesn't verify the sub parameter of an openId token exchange (CVE-2023-38691)
GHSA-vc7j-h8xg-fv5x / CVE-2023-38691
The POST /v1/exchange_openid endpoint did not check that the servername part of the sub parameter (containing the user's claimed MXID) is the same as the servername we are talking to. This could allow a malicious actor to spin up a server on any given domain, respond with a sub parameter according to the user they want to act as and use the resulting token to perform provisioning requests.
This is now patched so that the server part of the sub / user ID is checked against the server used to make the request.
Discovered and reported by a community member.
IRC command injection via admin commands containing newlines (CVE-2023-38690)
GHSA-3pmj-jqqp-2mj3 / CVE-2023-38690
When the IRC bridge attempted to parse an admin command from a Matrix user, it would only split arguments by a literal space. For example, sending “!join #matrix\nfoobar” would treat the channel name as “#matrix\nfoobar”. This could then be exploited to inject any IRC command into the bridge to be run. Since the !join command first joins via the bridge bot user, it could be used to execute commands as the bridge bot.
This is now patched so that both the command handler is more strict about its arguments, as well as channel names being explicitly validated when provided by users.
Discovered and reported by Val Lorentz.
Events can be crafted to leak parts of targeted messages from other bridged rooms (CVE-2023-38700)
GHSA-c7hh-3v6c-fj4q / CVE-2023-38700
The IRC bridge caches recent timeline messages in memory, so that when a reply is seen for a message it doesn’t need to request the event content from the homeserver. However the room ID was not validated when accessing this cache, so a malicious actor could craft a reply event in another room referencing any event ID (so long as it was still in the bridge cache) to trick the bridge into posting the message content into a bridged reply.
Discovered and reported by Val Lorentz.
If you have further questions, please reach out on security@matrix.org