Skip to content

🥅 Validate non-synchronizing literals support#701

Merged
nevans merged 3 commits into
v0.6.4-patchesfrom
security/validate-non_sync_literal-support
Jun 9, 2026
Merged

🥅 Validate non-synchronizing literals support#701
nevans merged 3 commits into
v0.6.4-patchesfrom
security/validate-non_sync_literal-support

Conversation

@nevans

@nevans nevans commented Jun 9, 2026

Copy link
Copy Markdown
Collaborator

It's bad behavior to send a non-synchronizing literal that's too large. This forces the server to choose between reading but ignoring the bytes or closing the connection.

But, for servers that don't support non-synchronizing literals, this could be another CRLF/command injection attack vector. If a server sees the }\r\n but can't parse the literal bytesize, it may decide to close the connection, and all is fine. But, a server might respond to any unparseable command line (ending in CRLF) with BAD, then interpret the literal as the next command. In that case, a CRLF/command injection could succeed.

Fortunately, LITERAL- is supported by most modern IMAP servers. So this is not expected to be widely exploitable.

nevans added 2 commits June 8, 2026 11:33
It's bad behavior to send a non-synchronizing literal that's too large.
This forces the server to choose between reading but ignoring the bytes
or closing the connection.

But, for servers that _don't_ support non-synchronizing literals, this
could be another CRLF/command injection attack vector.  If a server sees
the `}\r\n` but can't parse the literal bytesize, it may decide to close
the connection, and all is fine.  But, a server _might_ respond to any
unparseable command line (ending in `CRLF`) with `BAD`, then interpret
the literal as the next command.  In that case, a CRLF/command injection
could succeed.

Fortunately, `LITERAL-` is supported by most IMAP servers.  So this
is not expected to be widely exploitable.
@nevans nevans added bug Something isn't working security vulnerability patch Pull requests that address security vulnerabilities labels Jun 9, 2026
These tests can raise `Errno::ECONNREST, "Connection reset"` in the
server thread.  I've only seen it in TruffleRuby (semi-reliably) and
MacOS (flaky), but probably it's a timing issue and can happen elsewhere
too?
@nevans nevans force-pushed the security/validate-non_sync_literal-support branch from 97e8d5d to 0ea9eba Compare June 9, 2026 15:21
@nevans nevans merged commit e066b83 into v0.6.4-patches Jun 9, 2026
39 checks passed
@nevans nevans deleted the security/validate-non_sync_literal-support branch June 9, 2026 15:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

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