Skip to content

🔒 Fix STARTTLS stripping vulnerability (backports #664)#665

Merged
nevans merged 3 commits intov0.5-stablefrom
backport/v0.5/STARTTLS-stripping
Apr 23, 2026
Merged

🔒 Fix STARTTLS stripping vulnerability (backports #664)#665
nevans merged 3 commits intov0.5-stablefrom
backport/v0.5/STARTTLS-stripping

Conversation

@nevans
Copy link
Copy Markdown
Collaborator

@nevans nevans commented Apr 23, 2026

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#starttls to return "successfully", without starting TLS.

This ensures that #starttls either succeeds or raises an exception.

The following cases will raise an exception and close the connection:

  • For #starttls, when another error wasn't raised (e.g: the response errors for NO or BAD) but the handler did not run. (Any handler errors are re-raised, since 🥅 Re-raise #starttls error from receiver thread #395.)
  • For any command, if the server sends a tagged OK response 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.

nevans added 3 commits April 23, 2026 13:46
…664]

I'm putting this in its own commit to simplify testing across backports.
Also, I'm taking a "belt-and-suspenders" approach, and I'm going to test
that either of the two fixes passes the tests.
…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 sending the command has completed.
@nevans nevans added bug Something isn't working backport This issue or PR is for a stable release branch security vulnerability patch Pull requests that address security vulnerabilities labels Apr 23, 2026
@nevans nevans merged commit f79d35b into v0.5-stable Apr 23, 2026
46 checks passed
@nevans nevans deleted the backport/v0.5/STARTTLS-stripping branch April 23, 2026 17:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport This issue or PR is for a stable release branch bug Something isn't working security vulnerability patch Pull requests that address security vulnerabilities

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant