404 during UI authentication with matrix-synapse-shared-secret-auth

[waclaw66]

element-hq/element-web#20292 (comment) describes a custom user-interactive auth flow which a client did not understand. The client tried to request a HTML fallback to show to its user. The response from synapse was an error:

Start authentication link https://my_homeserver/_matrix/client/r0/auth/com.devture.shared_secret_auth/fallback/web?session=TpDJpMZAnnTXJHRGDQuQPlvs returns {"errcode":"M_UNKNOWN","error":"Unknown auth stage type"}

Judging by Synapse's source code, this probably came with a 404 status code. However, the spec says:

If a client does not know how to handle a given login type, it can direct the user to a web browser with the URL of a fallback page which will allow the user to complete that login step out-of-band in their web browser. The URL it should open is:

/_matrix/client/v3/auth/<auth type>/fallback/web?session=<session ID>

Where auth type is the type name of the stage it is attempting and session ID is the ID of the session given by the homeserver.

This MUST return an HTML page which can perform this authentication stage.

The JSON blob returned does not constitute an HTML page, so we are not spec compliant.

The report in that issue claimed to be running on Synapse 1.49 and using an unspecified version of devture/matrix-synapse-shared-secret-auth.

Original Description

Flows provided by _get_available_ui_auth_types are unordered, it causes element-hq/element-web#19605 and devture/matrix-synapse-shared-secret-auth#12.

[DMRobertson]

I'm pretty sure this is a client bug---clients need to be able to reject login methods they don't know how to handle.

The spec makes no promises about the order flows are listed in AFAICS. I don't think there's even a meaningful way to order them anyway?

[waclaw66]

Element Web developers see that differently...
element-hq/element-web#20292 (comment)
element-hq/element-web#20292 (comment)

[DMRobertson]

Thanks for the pointers. Reading through Michael K's comments and the spec, I agree that there isn't a bug in the client. However: those comments describe a different problem: Synapse not serving an HTTP response in the /fallback/ for com.devture.shared_secret_auth. That's not the same as "the order of flows isn't consistent".

I'm not sure who is responsible for not serving the /fallback/ response. It could be a bug in Synapse, or it could also be a bug in whatever is providing com.devture.shared_secret_auth login flow; I'm not sure which.

[DMRobertson]

@waclaw66 Do you have any server logs corresponding to step 4 in your element-web issue here? Can you also please confirm which version of synapse and matrix-synapse-shared-secret-auth you were running to get that error?

[clokep]

I retitled this to what I think is a more accurate title, please shout if I'm wrong!

[DMRobertson]

I edited the description to also try and provide more context.

I retitled this to what I think is a more accurate title, please shout if I'm wrong!

The error message "Unknown auth stage type" seems to be associated with 404s, judging by a quick grep of the source tree.

[waclaw66]

@DMRobertson: I have that log of Synapse 1.55.0 and shared_secret_authenticator-2.0.2.
Is it safe to post it here on debug level?

bře 24 20:13:18 synapse[1231049]: synapse.access.http.8008: [GET-541] 2001:470:redacted - 8008 - Received request: GET /_matrix/client/r0/auth/com.devture.shared_secret_auth/fallback/web?session=lGzReClshXUgtJILcAkxlDNk
bře 24 20:13:18 synapse[1231049]: synapse.http.server: [GET-541] <XForwardedForRequest at 0x7f7b7c82c820 method='GET' uri='/_matrix/client/r0/auth/com.devture.shared_secret_auth/fallback/web?session=lGzReClshXUgtJILcAkxlDNk' clientproto='HTTP/1.0' site='8008'> SynapseError: 404 - Unknown auth stage type
bře 24 20:13:18 synapse[1231049]: synapse.access.http.8008: [GET-541] 2001:470:redacted - 8008 - {None} Processed request: 0.002sec/0.001sec (0.002sec, 0.000sec) (0.000sec/0.000sec/0) 57B 404 "GET /_matrix/client/r0/auth/com.devture.shared_secret_auth/fallback/web?session=lGzReClshXUgtJILcAkxlDNk HTTP/1.0" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:99.0) Gecko/20100101 Firefox/99.0" [0 dbevts]

is that sufficient?

[DMRobertson]

To summarise what's going on here:

• Element web tries to UI Auth using the first flow it sees.
• If Element web doesn't understand a particular step in that flow, it asks for an HTML fallback rather than trying other auth flows.
  • This is guaranteed to exist by the spec.
  • The spec doesn't require clients to try other flows.
  • The spec doesn't prescribe any significance to the order of flows.
• Synapse doesn't serve a fallback for unknown flows. (Nor for some known flows too, like m.login.password.)
• Synapse doesn't have any way for "password" auth providers to provide this fallback.
  • EDIT 2023-04-27: it is especially unfortunate that we have created an API which cannot be used without exposing this footgun.

I don't know if the spec needs a rethink here?

In the medium term, the module api should provide some way for plugins to provide a fallback.

In the longer term, we'd be better served by using replacing our bespoke UIAuth with OAuth2.

[53c70r]

Any news?

[53c70r]

This Bug is compromising security I would like to get some proper response like now.

[dadada]

As a workaround for those who have to be able to log out of sessions (e.g. when an account is compromised), some clients still allow you to log out. What worked for me was using Fractal 5alpha1

[dadada]

For some context: This is an issue when trying to log out of existing sessions via All Settings -> Security and Privacy in Element Desktop and Element Web. It is not possible to sign out of sessions you do not (or no longer) have access to.

[DMRobertson]

@53c70r

This Bug is compromising security

If you have a specific security concern, please report it; see https://github.com/matrix-org/synapse/security/policy.

I would like to get some proper response like now.

As far as I can see, the summary in #12282 (comment) is still an accurate representation of the status quo.
I have left a note there to emphasise that Synapse is at fault for exposing a poor API for auth providers.

@dadada

This is an issue when trying to log out of existing sessions via All Settings -> Security and Privacy in Element Desktop and Element Web. It is not possible to sign out of sessions you do not (or no longer) have access to.

Thanks, that context is very helpful; this makes for a particularly painful failure mode.

Short of Element web providing better handling for a range of login types (element-hq/element-web#19605), the only other workaround that springs to mind is to delete a specific device using the Admin API (or delete a batch of multiple devices_).

[dadada]

Thanks, that context is very helpful; this makes for a particularly painful failure mode.

It's the same failure mode that was already reported in 2021 in the issue you linked to element-hq/element-web#19605 . I should have noticed this earlier. I'll ask our admin about which custom provider modules are installed. So there is no reason to believe this is an issue if no custom provider modules are installed. @53c70r do you have custom password provider modules installed like mentioned in element-hq/element-web#19605 ?