Skip to content

🚨 [security] Update net-imap 0.5.6 → 0.5.7 (minor) #1443

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

🚨 [security] Update net-imap 0.5.6 → 0.5.7 (minor) #1443

wants to merge 1 commit into from

Conversation

depfu[bot]
Copy link
Contributor

@depfu depfu bot commented Apr 23, 2025 •
edited
Loading

🚨 Your current dependencies have known security vulnerabilities 🚨

This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!

Here is everything you need to know about this update. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ net-imap (0.5.6 → 0.5.7) · Repo

Security Advisories 🚨

🚨 net-imap rubygem vulnerable to possible DoS by memory exhaustion

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

0.5.7

What's Changed

This release adds two features to prevent unbounded memory use: the response_handlers keyword argument to Net::IMAP.new (#419) so response handlers can be added before the server can send any responses, and the max_response_size config attribute (#444). Please note that 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 or buggy servers.

Please note: It is the responsibility of net-imap users to configure their client appropriately for the server they are connecting to.

Added

  • ✨ Track IMAP connection state by @nevans in #416
  • ✨ Add response_handlers kwarg to Net::IMAP.new by @nevans in #419
  • ✨ Customize SequenceSet YAML serialization by @nevans in #432
  • ✨ Limit max_response_size by @nevans in #444

Documentation

  • 📚 Improve docs for unbounded memory use and thread safety by @nevans in #418
  • 📚 Impove SequenceSet docs by @nevans in #420
  • 📚 Doc improvements for open_timeout, etc by @nevans in #424

Other Changes

  • ♻️ Reorganize Config.version_defaults creation by @nevans in #412
  • ♻️ Refactor Config attr type coercion by @nevans in #417
  • ♻️ Refactor Net::IMAP#get_response (internal) by @nevans in #422
  • ♻️ Rational config versions by @nevans in #429
  • ♻️ Extract ResponseReader from get_response by @nevans in #433
  • ♻️ Refactor ResponseReader by @nevans in #435

Miscellaneous

  • Bump step-security/harden-runner from 2.10.4 to 2.11.0 by @dependabot in #409
  • ✅ Make FakeServer more robust against disconnect by @nevans in #414
  • ✅ Improvements to FakeServer (tests only) by @nevans in #415
  • ✅ Ignore more IO errors in some FakeServer tests by @nevans in #421
  • ⬆️ Bump step-security/harden-runner from 2.11.0 to 2.11.1 by @dependabot in #423

Full Changelog: v0.5.6...v0.5.7

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 45 commits:

Depfu Status

Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.

All Depfu comment commands
@​depfu rebase
Rebases against your default branch and redoes this update
@​depfu recreate
Recreates this PR, overwriting any edits that you've made to it
@​depfu merge
Merges this PR once your tests are passing and conflicts are resolved
@​depfu cancel merge
Cancels automatic merging of this PR
@​depfu close
Closes this PR and deletes the branch
@​depfu reopen
Restores the branch and reopens this PR (if it's closed)
@​depfu pause
Ignores all future updates for this dependency and closes this PR
@​depfu pause [minor|major]
Ignores all future minor/major updates for this dependency and closes this PR
@​depfu resume
Future versions of this dependency will create PRs again (leaves this PR as is)

@depfu depfu bot added the depfu label Apr 23, 2025
@mitlib mitlib temporarily deployed to mit-bento-pr-1443 April 23, 2025 04:18 Inactive
@coveralls
Copy link

Coverage Status

coverage: 99.07%. remained the same
when pulling 8a90430 on depfu/update/net-imap-0.5.7
into 04fcd3a on main.

@depfu depfu bot changed the title Update net-imap 0.5.6 → 0.5.7 (minor) 🚨 [security] Update net-imap 0.5.6 → 0.5.7 (minor) Apr 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
depfu
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@coveralls @mitlib