🔒 Fix STARTTLS stripping vulnerability (backports #664, #395, #198)#667
Merged
nevans merged 6 commits intov0.3-stablefrom Apr 23, 2026
Merged
🔒 Fix STARTTLS stripping vulnerability (backports #664, #395, #198)#667nevans merged 6 commits intov0.3-stablefrom
nevans merged 6 commits intov0.3-stablefrom
Conversation
…ckports #395] Backports #395 to `v0.3-stable`. The tests required an additional rescue-and-ignore for the server thread in `starttls_test`, which was already present in all later branches. --------- When `start_tls_session` raises an exception, that's caught in the receiver thread, but not re-raised. Fortunately, `@sock` will now be a permanently broken SSLSocket, so I don't think this can lead to accidentally using an insecure connection. Even so, `#starttls` should disconnect the socket and re-raise the error immediately. Failing test case was provided by @rhenium in #394. Co-authored-by: Kazuki Yamaguchi <k@rhe.jp>
…ort #664] Taking a "belt-and-suspenders" approach to a STARTTLS stripping attack: This handles `STARTTLS` as a special-case: if the `STARTTLS` handler did not run, for _whatever_ reason, an exception _must_ be raised and the connection dropped. _No_ command should ever receive a tagged `OK` prior to completely sending the command. But `STARTTLS` is security-sensitive enough to warrant this special-case handler.
…664] Taking a "belt-and-suspenders" approach: This is a potential problem for any command which registers a response handler: a malicious server can easily guess what the next tag will be, and send an `OK` response _before_ the client the response handler is attached. `STARTTLS` is an extreme example of this issue: if the `STARTTLS` handler does not run, then `#starttls` will not start the TLS session, and the connection is not secured, _but no error is raised._ We should _also_ attach the response handler before sending the `CRLF`, but that is neither necessary (the response handler will added before the `synchronize` mutex is unlocked) nor sufficient (the fake `OK` can be sent _much_ earlier). On the other hand, it _is_ okay for the server to send an error tagged response (`NO` or `BAD`), before the sending the command has completed.
rdoc 7.2.0 lists >=2.6 as it's required ruby version, but it isn't tested in CI, and it is broken. See ruby/rdoc#1683.
nevans
added
bug
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Also backports #395 to
v0.3-stable. This ensuresSTARTTLShandler errors in the receiver thread are re-raised in the client thread.Partially backports #198 to
v0.3-stable: This copies InvalidResponseError (and an rdoc update to UnknownResponseError). The behavioral changes from that PR have not been copied.Backports #664 to
v0.5-stable. A couple of irrelevant commits were excluded.Warning
Without this patch, a man-in-the-middle attacker can cause
Net::IMAP#starttlsto return "successfully", without starting TLS.This ensures that
#starttlseither succeeds or raises an exception.The following cases will raise an exception and close the connection:
#starttls, when another error wasn't raised (e.g: the response errors forNOorBAD) but the handler did not run.OKresponse for that command before the command has been fully sent (before the command's own response handlers are added), an exception is raised and the connection is closed.