Skip to content

Conversation

@renovate
Copy link
Contributor

@renovate renovate bot commented May 6, 2025

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
net-imap (changelog) 0.5.6 -> 0.5.7 age adoption passing confidence

GitHub Vulnerability Alerts

CVE-2025-43857

Summary

There is a possibility for denial of service by memory exhaustion when net-imap reads server responses. At any time while the client is connected, a malicious server can send can send a "literal" byte count, which is automatically read by the client's receiver thread. The response reader immediately allocates memory for the number of bytes indicated by the server response.

This should not be an issue when securely connecting to trusted IMAP servers that are well-behaved. It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname).

Details

The IMAP protocol allows "literal" strings to be sent in responses, prefixed with their size in curly braces (e.g. {1234567890}\r\n). When Net::IMAP receives a response containing a literal string, it calls IO#read with that size. When called with a size, IO#read immediately allocates memory to buffer the entire string before processing continues. The server does not need to send any more data. There is no limit on the size of literals that will be accepted.

Fix

Upgrade

Users should upgrade to net-imap 0.5.7 or later. A configurable max_response_size limit has been added to Net::IMAP's response reader. The max_response_size limit has also been backported to net-imap 0.2.5, 0.3.9, and 0.4.20.

To set a global value for max_response_size, users must upgrade to net-imap ~> 0.4.20, or > 0.5.7.

Configuration

To avoid backward compatibility issues for secure connections to trusted well-behaved servers, the default max_response_size for net-imap 0.5.7 is very high (512MiB), and the default max_response_size for net-imap ~> 0.4.20, ~> 0.3.9, and 0.2.5 is nil (unlimited).

When connecting to untrusted servers or using insecure connections, a much lower max_response_size should be used.

# Set the global max_response_size (only ~> v0.4.20, > 0.5.7)
Net::IMAP.config.max_response_size = 256 << 10 # 256 KiB

# Set when creating the connection
imap = Net::IMAP.new(hostname, ssl: true,
                     max_response_size: 16 << 10) # 16 KiB

# Set after creating the connection
imap.max_response_size = 256 << 20 # 256 KiB

# flush currently waiting read, to ensure the new setting is loaded
imap.noop

Please Note: max_response_size only limits the size per response. It does not prevent a flood of individual responses and it does not limit how many unhandled responses may be stored on the responses hash. Users are responsible for adding response handlers to prune excessive unhandled responses.

Compatibility with lower max_response_size

A lower max_response_size may cause a few commands which legitimately return very large responses to raise an exception and close the connection. The max_response_size could be temporarily set to a higher value, but paginated or limited versions of commands should be used whenever possible. For example, to fetch message bodies:

imap.max_response_size = 256 << 20 # 256 KiB
imap.noop # flush currently waiting read

# fetch a message in 252KiB chunks
size = imap.uid_fetch(uid, "RFC822.SIZE").first.rfc822_size
limit = 252 << 10
message = ((0..size) % limit).each_with_object("") {|offset, str|
  str << imap.uid_fetch(uid, "BODY.PEEK[]<#{offset}.#{limit}>").first.message(offset:)
}

imap.max_response_size = 16 << 20 # 16 KiB
imap.noop # flush currently waiting read

References


Release Notes

ruby/net-imap (net-imap)

v0.5.7

Compare Source

What's Changed

🔒 Security

This release adds two features to prevent unbounded memory use: the response_handlers keyword argument to Net::IMAP.new (https://github.com/ruby/net-imap/pull/419) so response handlers can be added before the server can send any responses, and the max_response_size config attribute (https://github.com/ruby/net-imap/pull/444, GHSA-j3g3-5qv5-52mj, CVE-2025-43857, reported by @​Masamuneee).

[!NOTE]
The default max_response_size is extremely high, to avoid issues with secure connections to trusted servers that are well-behaved. It can be configured more conservatively to guard against untrusted servers (for example, connecting to user-provided hostnames). It is the responsibility of net-imap users to configure their client appropriately for the server they are connecting to.

Added
Documentation
Other Changes
Miscellaneous

Full Changelog: ruby/net-imap@v0.5.6...v0.5.7


Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate bot added the security label May 6, 2025
@mitlib mitlib temporarily deployed to mit-bento-pr-1449 May 6, 2025 19:00 Inactive
@coveralls
Copy link

Coverage Status

coverage: 99.07%. remained the same
when pulling 98855de on renovate/rubygems-net-imap-vulnerability
into 3425143 on main.

@JPrevost JPrevost merged commit 80a9bee into main May 6, 2025
3 checks passed
@renovate renovate bot deleted the renovate/rubygems-net-imap-vulnerability branch May 6, 2025 19:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants