Summary When verifying SSL certificates, jruby-openssl is not verifying that the hostname presented in the certificate matches the one we are trying to connect to, meaning a MITM could just present any valid cert for a completely different domain they own, and JRuby wouldn't complain.

Details n/a

PoC An example domain bad.substitutealert.com was created to present the a certificate for the domain s8a.me. The following script run in IRB in CRuby 3.4.3 will fail with certificate verify failed (hostname mismatch), but will work just fine in JRuby 10.0.0.0 and JRuby 9.4.2.0, both of which use jruby-openssl version 0.15.3

ruby require "net/http" require "openssl"

uri = URI("https://bad.substitutealert.com/") https = Net::HTTP.new(uri.host, uri.port) https.usessl = true https.verifymode = OpenSSL::SSL::VERIFYPEER

body = https.start { https.get(uri.requesturi).body } puts body

Impact Anybody using JRuby to make requests of external APIs, or scraping the web, that depends on https to connect securely

A security problem involving peer certificate verification was found where failed verification silently did nothing, making affected applications vulnerable to attackers. Attackers could lead a client application to believe that a secure connection to a rogue SSL server is legitimate. Attackers could also penetrate client-validated SSL server applications with a dummy certificate.

A denial of service flaw was found in the JRuby's Murmur hash function implementation. A specially-crafted set of keys could trigger Murmur hash function collisions, which degrade hash table items insert performance by changing hash table operations complexity from an expected/average O(n) to the worst case O(n^2). Reporters were able to find colliding strings efficiently using equivalent substrings.

As various web application frameworks for Ruby automatically pre-fill certain arrays with data from the HTTP request (such as GET or POST parameters) for Ruby web applications, a remote attacker could use this flaw to make the Ruby interpreter use an excessive amount of CPU time by sending a POST request with a large number parameters which hash to the same value.

A different vulnerability than CVE-2011-4838.

References: [1] http://www.openwall.com/lists/oss-security/2012/11/23/4 [2] http://www.ocert.org/advisories/ocert-2012-001.html [3] http://2012.appsec-forum.ch/conferences/#c17 [4] https://www.131002.net/data/talks/appsec12slides.pdf [5] http://asfws12.files.wordpress.com/2012/11/asfws2012-jeanphilippeaumasson-martinbosslet-hashfloodingdosreloaded.pdf

Julian Wälde and Alexander Klink reported a flaw in the hash function used in the implementation of the JRuby arrays implemented using the hash table.

A specially-crafted set of keys could trigger hash function collisions, which degrade hash table performance by changing hash table operations complexity from an expected/average O(1) to the worst case O(n). Reporters were able to find colliding strings efficiently using equivalent substrings or meet in the middle techniques.

As various web application frameworks for Ruby automatically pre-fill certain arrays with data from the HTTP request (such as GET or POST parameters) for Ruby web applications, a remote attacker could use this flaw to make the Ruby interpreter use an excessive amount of CPU time by sending a POST request with a large number parameters which hash to the same value.

This problem is similar to the issue that was previously reported for and fixed in e.g. perl: http://www.cs.rice.edu/~scrosby/hash/CrosbyWallachUsenixSec2003.pdf

Note: This issue have been fixed in version 1.6.5.1 of JRuby http://www.jruby.org/2011/12/27/jruby-1-6-5-1.html

JRuby before 1.6.5.1 computes hash values without restricting the ability to trigger hash collisions predictably, which allows context-dependent attackers to cause a denial of service (CPU consumption) via crafted input to an application that maintains a hash table.

A cross-site scripting (XSS) flaw was found in the way the regular expression engine of the JRuby, Java implementation of the Ruby programming language, processed certain invalid UTF-8 byte sequences. A remote attacker could use this flaw to execute arbitrary HTML or web script via specially-crafted input provided to an JRuby application.

References: [1] http://www.jruby.org/2010/04/26/jruby-1-4-1-xss-vulnerability.html [2] https://bugs.gentoo.org/showbug.cgi?id=317435

Proposed upstream solution (is to upgrage to jcodings-v1.0.3): [3] http://repo1.maven.org/maven2/org/jruby/jcodings/jcodings/1.0.3/jcodings-1.0.3.jar

A cross-site scripting (XSS) flaw was found in the way the regular expression engine of the JRuby, Java implementation of the Ruby programming language, processed certain invalid UTF-8 byte sequences. A remote attacker could use this flaw to execute arbitrary HTML or web script via specially-crafted input provided to an JRuby application.

References: [1] http://www.jruby.org/2010/04/26/jruby-1-4-1-xss-vulnerability.html [2] https://bugs.gentoo.org/showbug.cgi?id=317435

Proposed upstream solution (is to upgrage to jcodings-v1.0.3): [3] http://repo1.maven.org/maven2/org/jruby/jcodings/jcodings/1.0.3/jcodings-1.0.3.jar