FreshPorts - VuXML

The official ruby site reports:

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

gt 1.8.7,1 lt 1.8.7.371,1

gt 1.9.3,1 lt 1.9.3.286,1

The official ruby site reports:

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.

gt 1.9.3,1 lt 1.9.3.286,1

The official ruby site reports:

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

gt 1.8.7,1 lt 1.8.7.371,1

gt 1.9.3,1 lt 1.9.3.286,1

The official ruby site reports:

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.

gt 1.9.3,1 lt 1.9.3.286,1