GHSA-vcgp-9326-pqcp net-imap vulnerable to STARTTLS stripping via invalid response timing

• RubyGems net-imap: >= 0.6.0, < 0.6.4 → fixed in 0.6.4 • RubyGems net-imap: >= 0.5.0, < 0.5.14 → fixed in 0.5.14 • RubyGems net-imap: >= 0.4.0, < 0.4.24 → fixed in 0.4.24 • RubyGems net-imap: < 0.3.10 → fixed in 0.3.10

Summary A man-in-the-middle attacker can cause `Net::IMAP#starttls` to return "successfully", without starting TLS. Details When using `Net::IMAP#starttls` to upgrade a plaintext connection to use TLS, a man-in-the-middle attacker can inject a tagged `OK` response with an easily predictable tag. By sending the response before the client finishes sending the command, the command completes "successfully" before the response handler is registered. This allows `#starttls` to return without error, but the response handler is never invoked, the TLS connection is never established, and the socket remains unencrypted. This allows man-in-the-middle attackers to perform a STARTTLS stripping attack, unless the client code explicitly checks `Net::IMAP#tls_verified?`. Impact TLS bypass, leading to cleartext transmission of sensitive information. Mitigation • Upgrade to a patched version of net-imap that raises an exception whenever `#starttls` does not establish TLS. • Connect to an implicit TLS port, rather than use `STARTTLS` with a cleartext port. This is strongly recommended anyway: • RFC 8314: Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access • NO STARTTLS: Why TLS is better without STARTTLS, A Security Analysis of STARTTLS in the Email Context • Explicitly verify `Net::IMAP#tls_verified?` is `true`, before using the connection after `#starttls`.