element-hq
Synapse allows invalid usernames over federation
Description
Synapse server implementations do not parse usernames and allow arbitrary Unicode characters to be inserted into the username field.
As per the Matrix spec v1.11, usernames need to be restricted to the characters a-z, 0-9, ., _, =, -, /, and +. However, over federation, servers also need to support historical users, whose character set is defined as all ASCII printing chars except :, or specifically 0x21 to 0x7E with the exception of 0x3A.
Nevertheless, Synapse servers doesn't reject user IDs that break the spec's rules, with examples such as:
- An empty localpart username
- Unicode or emoji characters in their localparts
- Invalid ASCII characters such as spaces in the localpart
Steps to reproduce
Invite users such as @s p a c e:maunium.net or @:maunium.net to a room, and the Synapse server will simply follow along.
Homeserver
matrix.directory
Synapse Version
1.93.0
Installation Method
Docker (matrixdotorg/synapse)
Database
Not relevant.
Workers
Single process
Platform
Not relevant. These usernames are widely known across the ecosystem.
Configuration
No response
Relevant log output
Not relevant. These usernames are widely known across the ecosystem - and the whole point is that this issue DOESN'T raise any problems.
Anything else that would be useful to know?
No response
Well, empty user names could be considered a nogo even in historical usernames?
As an aside: 1.93.0 is a seriously old Synapse server.
Well, empty user names could be considered a nogo even in historical usernames?
They do exist though.
MSC4044 aims to improve this.
Historical usernames aren't allowed to use spaces. The space ASCII code is 0x20, and the "lowest" permitted character for historical users is 0x21.
When interviewing people who created invalid usernames, my personal experience is that many users were pentesters who wanted to verify what Synapse permits over federation.
I personally believe that it's a misguided thought to accept that such usernames exist and hence allow them. Synapse doesn't reject servers that break auth rules simply because of their existence. Unvalidated usernames leave room for security issues in the long run, and it breaks clients (source: the Elm SDK, which I develop) that wish to abide by spec.
(The server in question has since been updated.)
Afraid the spec has been updated to reflect the fact that the 'historical user ID' definition was wrong at the time it was introduced, and to accept the wider definition.
https://spec.matrix.org/v1.14/changelog/v1.14/
Clarify that arbitrary unicode is allowed in user/room IDs and room aliases. (#1506)
