Summary

Insecure session handling opened room for a privilege escalation scenario in whichprebuilt workspaces could be compromised by abusing a shared system identity.

Details

Coder automatically generates a session token for a user when a workspace is started. It is automatically exposed viacoder_workspace_owner.session_token. Prebuilt workspaces are initially owned by a built-inprebuilds system user.

When a prebuilt workspace is claimed, a new session token is generated for the user that claimed the workspace, but the previous session token for theprebuilds user was not expired. Any Coder workspace templates that persist this automatically generated session token are potentially impacted.

For example, thecoder-login module allows template authors to automatically configure the coder CLI to be authenticated with the Coder deployment.

This causes a script to be run on workspace startup that runs the commandcoder login using the automatically generated user session token c.f.https://github.com/coder/registry/blob/8677e7d52b374b025c4820d09049dc6b008beee8/registry/coder/modules/coder-login/main.tf#L23

This module was originally written before the inception of theprebuilds feature in Coder, which essentially creates a "pre-warmed" pool of workspaces owned by a particularprebuilds system user.

When this module is invoked on a prebuilt workspace, it causes the Coder CLI inside the workspace to persist the session token for theprebuilds user to disk. Because thecoder-login module checks if the CLI is authenticated, the script exits early before updating the session token, leaving the Coder CLI authenticated as theprebuildsuser upon claim:

Impact

Important:Deployments that have never utilized theprebuilds feature are not affected by this vulnerability.

This vulnerability requires a previously authenticated user to claim a prebuilt workspace from a template configured to store the prebuilds user session token as described above.

Theprebuilds user has no specific roles, so its credential has the same level of access as a regular member user, meaning a user with theprebuilds user's credential can move laterally to any other prebuilt workspace, or create new workspaces as theprebuilds user.

This means that a malicious authenticated actor can potentially execute code on other workspaces owned by theprebuilds user and potentially access information of other users once they claim a previously poisoned workspace.

Remediation

Fixed in#19667

Note that prebuilt workspaces claimed previous to the fix may have been affected by this vulnerability. It is recommended that users re-create their workspace if it was created from a prebuild.

To identify potentially affected workspaces, run the following SQL query against the Coder database:

SELECTw.id,w.name,w.owner_id,u.emailFROM workspaces wLEFT JOIN users uONu.id=w.owner_idWHEREw.owner_id<>'c42fdf75-3097-471c-8c33-fb52454d81c0'::uuidAND NOTw.deletedAND EXISTS (SELECT1FROM workspace_buildsAS wbWHEREwb.workspace_id=w.idANDwb.initiator_id='c42fdf75-3097-471c-8c33-fb52454d81c0'::uuid  );

Previous manually created tokens for the prebuilds user are left as-is. You may wish to review these viacoder tokens list --all

Premium license customers can also take advantage of theaudit logs feature to query actions performed by theprebuilds user.

Followingfilter can be used to verify if noAPI keys were created by theprebuilds user

would indicate a potentially malicious action aimed at achievingpersistence

username:prebuilds resource_type:api_key

Followingfilter can be used to list allwrite operations performed by theprebuilds user (including failed attempts to update various settings)

username:prebuilds action:write

Patched versions

• 2.24.4
• 2.25.2
• 2.26.0