A vulnerability was found that file creation routines can create
unintended files by strategically inserting NUL(s) in file paths.
This vulnerability has been reported as CVE-2012-4522.

Ruby can handle arbitrary binary patterns as Strings, including
NUL chars. On the other hand OSes and other libraries tend not.
They usually treat a NUL as an End of String mark. So to interface
them with Ruby, NUL chars should properly be avoided.

However methods like IO#open did not check the filename passed to
them, and just passed those strings to lower layer routines. This
led to create unintentional files.

Vulnerabilities found for Exception#to_s, NameError#to_s, and
name_err_mesg_to_s() which is Ruby interpreter-internal API. A
malicious user code can bypass $SAFE check by utilizing one of
those security holes.

Ruby's $SAFE mechanism enables untrusted user codes to run in
$SAFE >= 4 mode. This is a kind of sandboxing so some operations
are restricted in that mode to protect other data outside the
sandbox.

The problem found was around this mechanism. Exception#to_s,
NameError#to_s, and name_err_mesg_to_s() interpreter-internal API
was not correctly handling the $SAFE bits so a String object which
is not tainted can destructively be marked as tainted using them.
By using this an untrusted code in a sandbox can modify a
formerly-untainted string destructively.

Ruby 1.8 once had a similar security issue. It fixed
Exception#to_s and NameError#to_s, but name_err_mesg_to_str() issue
survived previous security fix

Vulnerabilities found for Exception#to_s, NameError#to_s, and
name_err_mesg_to_s() which is Ruby interpreter-internal API. A
malicious user code can bypass $SAFE check by utilizing one of
those security holes.

Ruby's $SAFE mechanism enables untrusted user codes to run in
$SAFE >= 4 mode. This is a kind of sandboxing so some operations
are restricted in that mode to protect other data outside the
sandbox.

The problem found was around this mechanism. Exception#to_s,
NameError#to_s, and name_err_mesg_to_s() interpreter-internal API
was not correctly handling the $SAFE bits so a String object which
is not tainted can destructively be marked as tainted using them.
By using this an untrusted code in a sandbox can modify a
formerly-untainted string destructively.

Ruby 1.8 once had a similar security issue. It fixed
Exception#to_s and NameError#to_s, but name_err_mesg_to_str() issue
survived previous security fix

A vulnerability was found that file creation routines can create
unintended files by strategically inserting NUL(s) in file paths.
This vulnerability has been reported as CVE-2012-4522.

Ruby can handle arbitrary binary patterns as Strings, including
NUL chars. On the other hand OSes and other libraries tend not.
They usually treat a NUL as an End of String mark. So to interface
them with Ruby, NUL chars should properly be avoided.

However methods like IO#open did not check the filename passed to
them, and just passed those strings to lower layer routines. This
led to create unintentional files.