<!--- Please read this! This template is for reporting a security vulnerability about GitLab or GitLab.com Strongly consider reporting via https://hackerone.com/gitlab, as HackerOne is our preferred disclosure platform. See also: - https://about.gitlab.com/security/disclosure/ - https://about.gitlab.com/handbook/engineering/security/#creating-new-security-issues - https://about.gitlab.com/handbook/engineering/security/#engaging-the-security-on-call ---> :warning: Please read the [process](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/security/engineer.md) on how to fix security issues before starting to work on the issue. Vulnerabilities must be fixed in a security mirror. ### Summary ActionCable websocket connections can trigger arbitrary public methods on `ApplicationCable::Channel` (including its included modules, `Gitlab::Auth::AuthFinders` and `ApplicationCable::Logging`) I wasn't able to find anything too nasty that someone could do by calling one of these methods, but I might not be creative enough, and an unsuspecting developer might change one in the future. ### Steps to reproduce Get a client websocket connection somehow. I applied this patch locally to make it easy, but of course anyone could inject arbitrary websocket messages: `<REDACTED>` Send a message on the websocket connection from your browser console: `window.__subscriptions[0].perform("find_user_from_warden")` for example, as it's the first public method in `AuthFinder`. Note that this method then gets called on the server :scream: (I verified with a breakpoint). It appears it's possible to call 0-argument methods, or 1-argument methods, and pass arbitrary de-serialized json to the 1-argument methods. <!--Describe how one can reproduce the issue - this is very important. Please use an ordered list.--> ### Example Project <!--If possible, please create an example project here on GitLab.com that exhibits the problematic behavior, and link to it here in the bug report. If you are using an older version of GitLab, this will also determine whether the bug is fixed in a more recent version.--> This works on any `ActionCable` websocket browsing any GitLab project. ### What is the current _bug_ behavior? <!--Describe what actually happens.--> ActionCable will `public_send` any of the following 48 methods (passing up to 1 user-supplied argument): <details> <summary>Method list (name - arity - source file)</summary> ``` unsubscribed - 0 - app/channels/graphql_channel.rb:34 subscribed - 0 - app/channels/graphql_channel.rb:8 authorization_scopes - 0 - ee/app/channels/ee/graphql_channel.rb:8 validate_user_authorization - 0 - app/channels/application_cable/channel.rb:11 find_user_from_job_token - 0 - ee/lib/ee/gitlab/auth/auth_finders.rb:53 find_user_from_geo_token - 0 - ee/lib/ee/gitlab/auth/auth_finders.rb:14 geo_api_request? - 0 - ee/lib/ee/gitlab/auth/auth_finders.rb:48 parse_geo_token - 1 - ee/lib/ee/gitlab/auth/auth_finders.rb:29 scim_request? - 0 - ee/lib/ee/gitlab/auth/auth_finders.rb:44 find_oauth_access_token - 0 - ee/lib/ee/gitlab/auth/auth_finders.rb:38 runner_controller_token_from_authorization_token - 0 - ee/lib/ee/gitlab/auth/auth_finders.rb:62 find_user_from_static_object_token - 1 - lib/gitlab/auth/auth_finders.rb:69 find_user_from_feed_token - 1 - lib/gitlab/auth/auth_finders.rb:78 find_user_from_access_token - 0 - lib/gitlab/auth/auth_finders.rb:146 validate_and_save_access_token! - -1 - lib/gitlab/auth/auth_finders.rb:207 find_user_from_basic_auth_password - 0 - lib/gitlab/auth/auth_finders.rb:103 find_user_from_lfs_token - 0 - lib/gitlab/auth/auth_finders.rb:112 find_user_from_personal_access_token - 0 - lib/gitlab/auth/auth_finders.rb:121 find_user_from_web_access_token - -2 - lib/gitlab/auth/auth_finders.rb:135 current_token= - 1 - lib/gitlab/auth/auth_finders.rb:62 cluster_agent_token_from_authorization_token - 0 - lib/gitlab/auth/auth_finders.rb:177 find_runner_from_token - 0 - lib/gitlab/auth/auth_finders.rb:187 find_job_from_job_token - 0 - lib/gitlab/auth/auth_finders.rb:196 authentication_token_present? - 0 - lib/gitlab/auth/auth_finders.rb:243 workspace_token_from_authorization_token - 0 - ee/lib/gitlab/auth/remote_development/auth_finders.rb:11 deploy_token_from_request - 0 - lib/gitlab/auth/auth_finders.rb:161 find_user_from_bearer_token - 0 - lib/gitlab/auth/auth_finders.rb:90 find_user_from_warden - 0 - lib/gitlab/auth/auth_finders.rb:65 current_token - 0 - lib/gitlab/auth/auth_finders.rb:62 load_balancer_stick_request - -4 - lib/gitlab/rack_load_balancing_helpers.rb:5 token_and_options - 1 - gem:actionpack-7.2.3/lib/action_controller/metal/http_authentication.rb:494 token_params_from - 1 - gem:actionpack-7.2.3/lib/action_controller/metal/http_authentication.rb:502 raw_params - 1 - gem:actionpack-7.2.3/lib/action_controller/metal/http_authentication.rb:519 params_array_from - 1 - gem:actionpack-7.2.3/lib/action_controller/metal/http_authentication.rb:507 rewrite_param_values - 1 - gem:actionpack-7.2.3/lib/action_controller/metal/http_authentication.rb:512 authentication_request - -3 - gem:actionpack-7.2.3/lib/action_controller/metal/http_authentication.rb:555 encode_credentials - -2 - gem:actionpack-7.2.3/lib/action_controller/metal/http_authentication.rb:539 authenticate - 1 - gem:actionpack-7.2.3/lib/action_controller/metal/http_authentication.rb:472 auth_scheme - 1 - gem:actionpack-7.2.3/lib/action_controller/metal/http_authentication.rb:126 has_basic_credentials? - 1 - gem:actionpack-7.2.3/lib/action_controller/metal/http_authentication.rb:114 user_name_and_password - 1 - gem:actionpack-7.2.3/lib/action_controller/metal/http_authentication.rb:118 decode_credentials - 1 - gem:actionpack-7.2.3/lib/action_controller/metal/http_authentication.rb:122 auth_param - 1 - gem:actionpack-7.2.3/lib/action_controller/metal/http_authentication.rb:130 strong_memoize_with - -2 - gems/gitlab-utils/lib/gitlab/utils/strong_memoize.rb:59 strong_memoized? - 1 - gems/gitlab-utils/lib/gitlab/utils/strong_memoize.rb:69 strong_memoize - 1 - gems/gitlab-utils/lib/gitlab/utils/strong_memoize.rb:28 strong_memoize_with_expiration - 2 - gems/gitlab-utils/lib/gitlab/utils/strong_memoize.rb:41 clear_memoization - 1 - gems/gitlab-utils/lib/gitlab/utils/strong_memoize.rb:74 ``` </details> <details> <summary>List generated with this script</summary> ```ruby FakeConnection = Struct.new(:identifiers) connection = FakeConnection.new(identifiers: []) gql_channel = GraphqlChannel.new(connection, "fake-identifier") action_methods = GraphqlChannel.action_methods current_dir = Dir.pwd + '/' action_methods.each do |method_name| method = gql_channel.method(method_name) (source_file, source_line) = method.source_location source_file = source_file.gsub("/Users/simon/.local/share/mise/installs/ruby/3.3.10/lib/ruby/gems/3.3.0/gems/", "gem:") source_file = source_file.gsub(current_dir, "") puts "#{method_name} - #{method.arity} - #{source_file}:#{source_line}" end ``` </details> This happens because `ActionCable` thinks the application is defining these methods as callable RPCs on the channel. For example https://guides.rubyonrails.org/action_cable_overview.html#example-1-user-appearances defines two RPC-callable methods - `AppearancesChannel#appear` and `AppearancesChannel#away`. The actual `ActionCable` implementation verifies that the requested method is in the allowlist `Channel#action_methods`, but `action_methods` includes all public methods on any superclass between the channel and `ActionCable::Channel::Base` - see https://github.com/rails/rails/blob/v7.2.3/actioncable/lib/action_cable/channel/base.rb#L129. In GitLab's case, that includes `ApplicationChannel`, which has all these methods defined on it. The method then gets called via `public_send` in https://github.com/rails/rails/blob/v7.2.3/actioncable/lib/action_cable/channel/base.rb#L287. ### What is the expected _correct_ behavior? We don't expose these methods as user-callable. ### Relevant logs and/or screenshots <!--Paste any relevant logs - please use code blocks (```) to format console output, logs, and code as it's tough to read otherwise.--> <details> <summary>Screenshot of debugger stacktrace showing arbitrary method call</summary> {width="439" height="600"} </details> ### Output of checks <!--If you are reporting a bug on GitLab.com, write: This bug happens on GitLab.com--> I haven't tested it, but I assume this happens on Gitlab.com (and anywhere else). #### Results of GitLab environment info <!--Input any relevant GitLab environment information if needed.--> <details> <summary>Expand for output related to GitLab environment info</summary> <pre> (For installations with omnibus-gitlab package run and paste the output of: \\\`sudo gitlab-rake gitlab:env:info\\\`) (For installations from source run and paste the output of: \\\`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production\\\`) </pre> </details> #### Results of GitLab application Check <!--Input any relevant GitLab application check information if needed.--> This is a logic error, I reproduced it with an up-to-date gdk. <details> <summary>Expand for output related to the GitLab application check</summary> <pre> (For installations with omnibus-gitlab package run and paste the output of: \`sudo gitlab-rake gitlab:check SANITIZE=true\`) (For installations from source run and paste the output of: \`sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true\`) (we will only investigate if the tests are passing) </pre> </details> ### Possible fixes <!--If you can, link to the line of code that might be responsible for the problem.--> **NOTE**: See proposal from Heinrich below https://gitlab.com/gitlab-org/gitlab/-/issues/588959#note_3076548097 ~~We could patch `action_methods` (~~~~https://github.com/rails/rails/blob/v7.2.3/actioncable/lib/action_cable/channel/base.rb#L129~~~~) to not include methods from superclasses, but that's a pretty brittle patch. Alternatively we could remove the includes from `ApplicationCable`.~~ --- <!--Do not edit past here unless you are certain of the impact--> cc @gitlab-com/gl-security/appsec cc @gitlab-com/gl-security/product-security/psirt-group