Hi,
Recently in some update, apparently the IP I guess is checked?
Basically, I try to open a shell with exec, so the backend server does request the websocket, the client directly connects to it but it ends up getting:
class: websocket
description: Executing command
err: Requestor mismatch
Any way to disable this?
Regards
For some reason, in the LTS branch this validation was added, which also affects, designated public endpoints, e.g:
wss://api.myapi.net/xxxxxxxxxxxxxxxxxxxxxxx/websocket?public&secret=mysecret
Seems to break websocket?public=
edit: Could the issue be triggered by requesting via https and connection to wss?
Any ideas?
I forgot to mention, that I am using the LTS version, 6.0.5.
I didn’t expect the LTS version to get features added such as this one.
Not a new feature, this is a security fix to avoid a privilege escalation scenario.
Unfortunately the CVE report for this hasn’t yet been made public by the reporter.
Good to know, thank you.
It seems to break basic features though, e.g you ask for websockets for a /console via https and the security check, blocks you from accessing it with websockets, which for /console you have to use websockets to access it interactively.
It forces you entirely to use websockets for this purpose.
It doesn’t block websocket access or the Incus CLI and web UI would be completely broken. What it does is it requires the same requestor be used for both the API request and subsequent connection to the websocket.
Specifically, it ensures that the same user and authentication protocol is used for both requests.
Yes, they are different protocols, exactly, that which breaks functionality.
e.g I request my /console via https, to get my websocket credentials, connect via wss => blocked due to security reasons.
Hence I need to use websockets to even ask /console to get my credentials.
At least its broken for me.
I said authentication protocol, so typically one of oidc or tls, both of which are supported for both HTTPS and WSS.
Most likely what’s going on here is that your websocket request isn’t using the client certificate (tls) or OIDC cookies (oidc) that you’re using to perform the REST API call.
Yes, I do not include the certificates for reason, they can’t be shared.
websocket?public&secret=mysecret used to work with only the secret before, now I consider it broken since it needs certificates, hence it can’t be accessed without them anymore in public.
Yes, that’s correct, the console and exec endpoints now require authentication and for the authenticated user to be the same that first made the API request to start the console or exec session.
As mentioned before, this is a security fix for a currently undisclosed CVE, it’s not a bug and not something we’re planning on changing as changing that logic would allow a privileged escalation attack.
Okay, I guess you want to give people more time to patch before you disclose it.
But can you tell me, if that’s just related to /console? or rather something that uses multiple endpoints to do the privilged escalation?
I have a fix in mind but I am unsure if it would undermine, the security patch.
The issue is basically with the fact that Incus can have multiple level of access to a project or even to a specific instance.
Access to the logging data doesn’t require much privilege (read-only is fine) but that logging data can contain the operation data which then provides the operation URL and the websocket secrets.
So that means that a user with limited API access may be able to listen for newly spawned operations and then race the actual API requestor, connecting to the endpoint before the legitimate user has a chance to.
That then gives them access to an exec or console session that they would normally not be allowed to start.
The extra check is there to ensure that whoever requested the exec or console session is the same user who then connects to it. Users with access to the operation list or to detailed logs can still see the details (which is commonly needed by auditing systems) but can’t use them themselves.
Okay, so when I do understand correctly, what you tell me.
If a user, has only limited access to the Incus REST API, e.g only access to /console and not to /operations/ or only to /console, its fine because he can’t even if he gets a operation in his hands, he could not ask the API for the websockets.
Yeah, the more common case is to have a user with read-only access as is used by logging systems and audit servers who can then see all events (equivalent of incus monitor) or even list the operations through /1.0/operations but then that user is supposed to be read-only, so they should not be allowed to use the credentials they see in the logs and access the resource with that.