[GHSA-6wpv-cj6x-v3jw] http vulnerable to Exposure of Sensitive Information to an Unauthorized Actor

[RainSignal]

Updates

• Affected products
• CWEs
• References
• Source code location

Comments
The current advisory is incomplete and partly inaccurate in three ways.

1. Affected range is too broad/inaccurate
   GitHub currently lists the affected versions as < 0.7.3, but RubySec’s published advisory and the Ruby Advisory DB both document two patched version lines:

   • >= 0.7.3
   • ~> 0.6.4

   This means versions in the 0.6.x line starting at 0.6.4 are already fixed and should not be included in the vulnerable range. The more accurate affected range is:

   • < 0.6.4
   • >= 0.7.0, < 0.7.3 :contentReference[oaicite:6]{index=6}

2. Patched versions are incomplete
   GitHub currently lists only 0.7.3 as patched, but RubySec also lists the patched maintenance line ~> 0.6.4. That backported fix should be included. :contentReference[oaicite:7]{index=7}

3. Title / weakness should reflect the actual root cause
   The issue is described by the upstream disclosure and RubySec as an HTTPS MitM vulnerability caused by failure to call OpenSSL::SSL::SSLSocket#post_connection_check for hostname verification. This is more precise than the current generic “Exposure of Sensitive Information to an Unauthorized Actor” wording. :contentReference[oaicite:8]{index=8}

Supporting references:

• Vendor disclosure: https://groups.google.com/g/httprb/c/jkb4oxwZjkU
• RubySec advisory: https://rubysec.com/advisories/CVE-2015-1828/
• Ruby Advisory DB entry: https://github.com/rubysec/ruby-advisory-db/blob/master/gems/http/CVE-2015-1828.yml
• Ruby OpenSSL discussion of the underlying hostname verification pitfall: Hostname verification should be required by default when OpenSSL::SSL::VERIFY_PEER is configured ruby/openssl#8
• https://security.snyk.io/vuln/SNYK-RUBY-HTTP-20210

[shelbyc]

Hi @tjuyuxinzhang, this is an interesting situation. I see version 0.6.4 mentioned as fixed in https://rubysec.com/advisories/CVE-2015-1828/ and https://github.com/rubysec/ruby-advisory-db/blob/master/gems/http/CVE-2015-1828.yml, but 0.6.4 isn't mentioned at all in the original vendor disclosure (https://groups.google.com/g/httprb/c/jkb4oxwZjkU) or in ruby/openssl#8. How did you determine that 0.6.4 contains a patch?

[RainSignal]

Hi @tjuyuxinzhang, this is an interesting situation. I see version 0.6.4 mentioned as fixed in https://rubysec.com/advisories/CVE-2015-1828/ and https://github.com/rubysec/ruby-advisory-db/blob/master/gems/http/CVE-2015-1828.yml, but 0.6.4 isn't mentioned at all in the original vendor disclosure (https://groups.google.com/g/httprb/c/jkb4oxwZjkU) or in ruby/openssl#8. How did you determine that 0.6.4 contains a patch?你好，这是个有趣的情况。我看到 0.6.4 版本在 https://rubysec.com/advisories/CVE-2015-1828/ 和 https://github.com/rubysec/ruby-advisory-db/blob/master/gems/http/CVE-2015-1828.yml 中被提及已修复，但在原始供应商披露（https://groups.google.com/g/httprb/c/jkb4oxwZjkU 年）或 ruby/openssl#8 0.6.4 中完全没有提及。你是怎么确定 0.6.4 包含补丁的？

Thanks for raising this — the reason I concluded that 0.6.4 contains the fix is not from the original disclosure email alone, but from the actual 0.6.3 -> 0.6.4 package diff and changelog for the http gem.

Specifically, the 0.6.4 release contains all of the indicators we would expect for a genuine backport of CVE-2015-1828:

1. The 0.6.4 changelog explicitly calls out CVE-2015-1828 as a security fix
   In the published gem diff, CHANGES.md for 0.6.4 includes a security entry stating that:

   • http.rb failed to call #post_connection_check
   • this made it vulnerable to MitM attacks
   • the issue was corrected by calling #post_connection_check
   • it references CVE-2015-1828
   • and it explicitly says the fix was backported by @nicoolas25

2. The actual TLS verification code was backported into the 0.6.x line
   In the 0.6.3 -> 0.6.4 diff for lib/http/client.rb, the code was changed to pass the hostname into the TLS setup and call:

   • socket.post_connection_check(host)
     when verify_mode == OpenSSL::SSL::VERIFY_PEER

   That is the exact remediation described in the original disclosure.

3. A regression test was added
   The 0.6.4 diff also adds a regression test in spec/http/client_spec.rb asserting that a hostname mismatch raises OpenSSL::SSL::SSLError, which is strong evidence that hostname verification was intentionally fixed in that release.

The best supporting source for this is the published gem diff here:

• https://my.diffend.io/gems/http/0.6.3/0.6.4

RubySec and the Ruby Advisory DB are consistent with that package-level evidence and list the patched version lines as:

• >= 0.7.3
• ~> 0.6.4

References:

• RubySec advisory: https://rubysec.com/advisories/CVE-2015-1828/
• Ruby Advisory DB: https://github.com/rubysec/ruby-advisory-db/blob/master/gems/http/CVE-2015-1828.yml

So to clarify the reasoning:

• the original vendor disclosure establishes the vulnerability and the mainline fix at 0.7.3
• the 0.6.3 -> 0.6.4 gem diff provides the evidence that the same fix was backported to the 0.6.x maintenance line
• RubySec then reflects that backport in its normalized advisory metadata

That is why I suggested the affected ranges should be modeled as:

• < 0.6.4
• >= 0.7.0, < 0.7.3

rather than simply < 0.7.3.

[advisory-database]

Hi @tjuyuxinzhang! Thank you so much for contributing to the GitHub Advisory Database. This database is free, open, and accessible to all, and it's people like you who make it great. Thanks for choosing to help others. We hope you send in more contributions in the future!