GHSA-7fc5-f82f-cx69: Possible DoS by memory exhaustion in net-imap
SummaryThere is a possibility for denial of service by memory exhaustion in `net-imap`'s response parser.  At any time while the client is connected, a malicious server can send  can send highly compressed `uid-set` data which is automatically read by the client's receiver thread.  The response parser uses `Range#to_a` to convert the `uid-set` data into arrays of integers, with no limitation on the expanded size of the ranges.DetailsIMAP's `uid-set` and `sequence-set` formats can compress ranges of numbers, for example: `"1,2,3,4,5"` and `"1:5"` both represent the same set.  When `Net::IMAP::ResponseParser` receives `APPENDUID` or `COPYUID` response codes, it expands each `uid-set` into an array of integers.  On a 64 bit system, these arrays will expand to 8 bytes for each number in the set.  A malicious IMAP server may send specially crafted `APPENDUID` or `COPYUID` responses with very large `uid-set` ranges.The `Net::IMAP` client parses each server response in a separate thread, as soon as each responses is received from the server.  This attack works even when the client does not handle the `APPENDUID` or `COPYUID` responses.Malicious inputs:Simple way to test this:FixesPreferred Fix, minor API changesUpgrade to v0.4.19, v0.5.6, or higher, and configure:This replaces `UIDPlusData` with `AppendUIDData` and `CopyUIDData`.  These classes store their UIDs as `Net::IMAP::SequenceSet` objects (_not_ expanded into arrays of integers).  Code that does not handle `APPENDUID` or `COPYUID` responses will not notice any difference.  Code that does handle these responses _may_ need to be updated.  See the documentation for [UIDPlusData](https://ruby.github.io/net-imap/Net/IMAP/UIDPlusData.html), [AppendUIDData](https://ruby.github.io/net-imap/Net/IMAP/AppendUIDData.html) and [CopyUIDData](https://ruby.github.io/net-imap/Net/IMAP/CopyUIDData.html).For v0.3.8, this option is not available.
For v0.4.19, the default value is `true`.
For v0.5.6, the default value is `:up_to_max_size`.
For v0.6.0, the only allowed value will be `false`  _(`UIDPlusData` will be removed from v0.6)_.Mitigation, backward compatible APIUpgrade to v0.3.8, v0.4.19, v0.5.6, or higher.For backward compatibility, `uid-set` can still be expanded into an array, but a maximum limit will be applied.Assign `config.parser_max_deprecated_uidplus_data_size` to set the maximum `UIDPlusData` UID set size.
When `config.parser_use_deprecated_uidplus_data == true`, larger sets will raise `Net::IMAP::ResponseParseError`.
When  `config.parser_use_deprecated_uidplus_data == :up_to_max_size`, larger sets will use `AppendUIDData` or `CopyUIDData`.For v0.3,8, this limit is _hard-coded_ to 10,000, and larger sets will always raise `Net::IMAP::ResponseParseError`.
For v0.4.19, the limit defaults to 1000.
For v0.5.6, the limit defaults to 100.
For v0.6.0, the limit will be ignored  _(`UIDPlusData` will be removed from v0.6)_.Please Note: unhandled responsesIf the client does not add response handlers to prune unhandled responses, a malicious server can still eventually exhaust all client memory, by repeatedly sending malicious responses.  However, `net-imap` has always retained unhandled responses, and it has always been necessary for long-lived connections to prune these responses.  _This is not significantly different from connecting to a trusted server with a long-lived connection._  To limit the maximum number of retained responses, a simple handler might look something like the following:Proof of conceptSave the following to a ruby file (e.g: `poc.rb`) and make it executable:Use `ulimit` to limit the process's virtual memory.  The following example limits virtual memory to 1GB:
CVSS v4.0: 6
CVSS v3.1: 6.5