Not using the result of NODE_NEGATE leads to incorrect code generation which could possibly result in arbitrary bytecode generation. Currently it is possible to produce a crash through a SIGABRT via an assert failure.
Proof of concept
assert_failure.rb
-0E00;0
Run either:
a. mruby assert_failure.rb
b. sandbox assert_failure.rb
The problem is that codegen is called recursively on the argument of NODE_NEGATE without checking whether it is a valid node. This is problematic because codegen assumes that its tree argument is a valid node (i.e. that the node's type is stored under the car member, further nodes or data under the cdr member and that filename_index and lineno are set properly). This creates an opportunity for the attacker to control further code generation, though it might not be possible to place a valid node type in car with the current codebase. Nevertheless, filename_indexcan be controlled and this is what allows the POC to make the assertion on line 135 of debug.c fail:
The following report was submitted by https://hackerone.com/dkasak:
Introduction
Not using the result of
NODE_NEGATE
leads to incorrect code generation which could possibly result in arbitrary bytecode generation. Currently it is possible to produce a crash through a SIGABRT via anassert
failure.Proof of concept
assert_failure.rb
Run either:
a.
mruby assert_failure.rb
b.
sandbox assert_failure.rb
Both cause a crash via an
assert
failure.Discussion
The flaw was introduced in commit d56a19c.
The problem is that
codegen
is called recursively on the argument ofNODE_NEGATE
without checking whether it is a valid node. This is problematic becausecodegen
assumes that itstree
argument is a valid node (i.e. that the node's type is stored under thecar
member, further nodes or data under thecdr
member and thatfilename_index
andlineno
are set properly). This creates an opportunity for the attacker to control further code generation, though it might not be possible to place a valid node type incar
with the current codebase. Nevertheless,filename_index
can be controlled and this is what allows the POC to make the assertion on line 135 ofdebug.c
fail:Running mruby with the following input in gdb:
And breaking on
parse.y:2885
, we can see thatfilename_index
is set to 13621 (which is two '5' characters interpreted as an integer):Then, breaking
codegen.c:1230
, we see thattree->filename_index
is indeed set to 13621:This eventually leads to
assert
to fail.Solution
To fix the problem, we should ensure
tree->car
is a valid node before callingcodegen
ontree
in the case ofNODE_NEGATE
.negate_node.patch
--
Denis Kasak
The text was updated successfully, but these errors were encountered: