EM-HTTP-Request 1.1.5 uses the library eventmachine in an insecure way that allows an attacker to perform a man-in-the-middle attack against users of the library. The hostname in a TLS server certificate is not verified.
Source RPM: ruby-em-http-request => ruby-em-http-request-1.1.5-5.mga8.src.rpmCVE: (none) => CVE-2020-13482
version 1.1.6 pushed in cauldron
Resolution: (none) => FIXEDStatus: NEW => RESOLVEDCC: (none) => mageia
Some of these bugs may apply to Mageia 7.
Resolution: FIXED => (none)Status comment: (none) => Fixed upstream in 1.1.6Status: RESOLVED => REOPENEDVersion: Cauldron => 7
Summary: ruby-em-http-request security issue CVE-2020-13482 => ruby-em-http-request new security issue CVE-2020-13482
As there is no maintainer for this package I added the committers in CC. (Please set the status to 'assigned' if you are working on it)
CC: (none) => ouaurelienAssignee: bugsquad => pkg-bugs
We should update Cauldron again to 1.1.7: https://bugzilla.redhat.com/show_bug.cgi?id=1911457#c8 https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/Z32PUJA6RGBZ3TKSOTGUXZ45662S3MVF/
Version: 7 => Cauldron
Freeze push asked
Whiteboard: (none) => MGA7TOO
available on cauldron
Whiteboard: MGA7TOO => (none)Version: Cauldron => 7
new version pushed in mga7: src: - ruby-em-http-request-1.1.7-1.mga7
Status comment: Fixed upstream in 1.1.6 => (none)Assignee: pkg-bugs => qa-bugs
Package list: ruby-em-http-request-1.1.7-1.mga7 ruby-em-http-request-doc-1.1.7-1.mga7
Advisory: ======================== Updated ruby-em-http-request packages fix security vulnerability: A flaw was found in rubygem-em-http-request. The eventmachine library does not verify the hostname in a TLS server certificate which can allow an attacker to perform a man-in-the-middle attack. The highest threat from this vulnerability is to data confidentiality and integrity (CVE-2020-13482). References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13482 https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/Z32PUJA6RGBZ3TKSOTGUXZ45662S3MVF/
mga7, x86_64 CVE-2020-13482 https://github.com/igrigorik/em-http-request/issues/339 $ gem list | grep eventmachine eventmachine (1.2.7) Installed the package, which pulled in the bundled eventmachine gem. Problems ahead? $ openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes Generating a RSA private key .... Copied the simple client script and found that it failed to run. $ ruby client.rb "https://test.coinbase.com" Traceback (most recent call last): 2: from client.rb:4:in `<main>' 1: from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:92:in `require' /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:92:in `require': cannot load such file -- em-http (LoadError) $ sudo updatedb $ locate em-http.rb $ locate em-http-request.rb Those turned up nothing. /usr/share/gems/gems/em-http-request-1.1.5/lib/em-http.rb exists so worth a shot. There is also an em-http-request.rb file in the same directory. Tried the full path name but same result. Any idea what I should try next? It does not look like permissions problems (dirs 755, files 644). Script header is: #!/usr/bin/ruby -W0 require 'rubygems' require 'eventmachine' require '/usr/share/gems/gems/em-http-request-1.1.5/lib/em-http'
CC: (none) => tarazed25
Keywords: (none) => feedback
Follow on from comment 10. Out of curiosity I tried out the procedure on Mageia 8 with the release 1.7 version and had no problem running the sample client, which worked as expected then threw an error on connection close. Probably to be expected as this is not a real case. No need to specify the full path either. Shall try another mga7 installation and make sure that eventmachine is not already installed. Some conflict between bundled and gem install is the only thing I can think of.
Created attachment 12556 [details] Sample client for the upstream reproducer CVE-2020-13482
Created attachment 12557 [details] Sample client for the upstream reproducer Fixed the error at CONNECTION CLOSED.
Attachment 12556 is obsolete: 0 => 1
(In reply to Len Lawrence from comment #10) > mga7, x86_64 > /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:92:in `require': > cannot load such file -- em-http (LoadError) > $ sudo updatedb > $ locate em-http.rb > $ locate em-http-request.rb > Those turned up nothing. # urpmf em-http.rb ruby-em-http-request:/usr/share/gems/gems/em-http-request-1.1.5/lib/em-http.rb ruby-em-http-request:/usr/share/gems/gems/em-http-request-1.1.7/lib/em-http.rb
Keywords: feedback => (none)CC: (none) => davidwhodgins
Thanks Dave. After clearing the decks and starting again I was able to run the sample client. However the server no longer runs, even after restarting the certificate generation process. New cert.pem and key.pem in place. $ openssl s_server -key key.pem -cert cert.pem -accept 443 Using default temp DH parameters ACCEPT 139860239832896:error:0200600D:system library:bind:Permission denied:crypto/bio/b_sock2.c:220: 139860239832896:error:2008B075:BIO routines:BIO_listen:unable to bind socket:crypto/bio/b_sock2.c:221: 0 items in the session cache 0 client connects (SSL_connect()) 0 client renegotiates (SSL_connect()) 0 client connects that finished 0 server accepts (SSL_accept()) 0 server renegotiates (SSL_accept()) 0 server accepts that finished 0 session cache hits 0 session cache misses 0 session cache timeouts 0 callback cache hits 0 cache full overflows (128 allowed) $ However, if run by root it works: # openssl s_server -key key.pem -cert cert.pem -accept 443 Using default temp DH parameters ACCEPT $ ruby client.rb "https://test.coinbase.com" https://test.coinbase.com Errno::ETIMEDOUT The server reports: -----BEGIN SSL SESSION PARAMETERS----- [...] -----END SSL SESSION PARAMETERS----- Shared ciphers:ECDHE-ECDSA-AES256-................... SHA256:AES128-SHA Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224 Shared Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224 Supported Elliptic Curve Point Formats: uncompressed:ansiX962_compressed_prime:ansiX962_compressed_char2 Supported Elliptic Curves: X25519:P-256:P-521:P-384 Shared Elliptic curves: X25519:P-256:P-521:P-384 CIPHER is ECDHE-RSA-AES256-GCM-SHA384 Secure Renegotiation IS supported GET / HTTP/1.1 Connection: close Host: test.coinbase.com User-Agent: EventMachine HttpClient Accept-Encoding: gzip, compressed ERROR shutting down SSL CONNECTION CLOSED ACCEPT So, it looks like it is working although I do not know what to expect at this stage. Shall see how it looks after the update.
After the update root restarted the openssl server and user ran the sample client, with the same result. $ ruby client.rb "https://test.coinbase.com" https://test.coinbase.com Errno::ETIMEDOUT From the server: ERROR shutting down SSL CONNECTION CLOSED ACCEPT If this is the expected result then this update can be sent on its way. Although this test is for a reproducer it does exercize the event machine and http request side of things. Awaiting further advice.
And, /etc/hosts does have the fake DNS entry: 127.0.0.1 test.coinbase.com
Closer inspection of the server output confirms that the before and after outputs are the same and match the upstream report as far as it goes, which seems to indicate that the vulnerability might have been fixed already in version 1.5. My understanding is that the server ERROR message shows that the host validation check succeeds in exposing the fake site.
Whiteboard: (none) => MGA7-64-OK
Your persistance is appreciated, Len. Validating. Advisory in Comment 9.
CC: (none) => andrewsfarm, sysadmin-bugsKeywords: (none) => validated_update
Keywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2021-0172.html
Resolution: (none) => FIXEDStatus: REOPENED => RESOLVED