Threats affecting pkg:brew/mikutter

### Summary `Addressable::URI.normalize_path` resolves some paths containing `..` segments to a different path than RFC 3986 does. When a path climbs above the root before any other `..` is resolved, the segments that later `..` segments should remove are instead kept: `/../../public/x/../../secret` normalizes to `/public/x/secret` instead of `/secret`. `URI#normalize`, `URI#join`, `URI#==` and `URI#===` all use this normalization. An application that checks a normalized Addressable path against an allowlist, but sends the original URI to something that resolves it according to RFC 3986, can be made to allow a request for a path outside the allowlist. ### Details `normalize_path` in 2.9.0 (`lib/addressable/uri.rb`) removes dot segments by repeating a set of rewrites until nothing changes. On each pass it finds the first `/segment/../` pair with `RULE_2B_2C`, then replaces every textual copy of that pair in the path with `/`: ```ruby pair = normalized_path.match(RULE_2B_2C) ... regexp = "/#{Regexp.escape(parent.to_s)}/\\.\\./|" regexp += "(/#{Regexp.escape(current.to_s)}/\\.\\.$)" ... mod ||= normalized_path.gsub!(Regexp.new(regexp), SLASH) ``` When the first pair found is `/../../`, where the "segment" is itself `..`, every `/../../` in the path is replaced with `/`. That includes copies later in the path, where each `..` should have removed the segment before it. For `/../../public/x/../../secret`: - RFC 3986 §5.2.4 drops the two leading `..` segments, which can't go above the root, then removes `x` and `public`, giving `/secret`. - 2.9.0 replaces both copies of `/../../` with `/` in one step, giving `/public/x/secret`. Paths where an ordinary `/segment/../` pair comes first, such as `/a/../../b/c/../../d`, are resolved correctly. This was introduced in 2.2.5. Versions 2.0.0 through 2.2.4 and earlier versions resolve these paths correctly. It is fixed in 2.9.1, which replaces the rewrite loop with a single pass that correctly follows RFC 3986 §5.2.4. ### Proof of concept ```ruby require "addressable/uri" require "uri" url = "http://example.com/../../public/x/../../secret" # Addressable's normalized path, compared with RFC 3986 resolution by Ruby's URI library puts Addressable::URI.parse(url).normalize.path puts URI.join("http://example.com/", "../../public/x/../../secret").path # join and == use the same normalization puts Addressable::URI.join("http://example.com/", "../../public/x/../../secret").path puts Addressable::URI.parse(url) == Addressable::URI.parse("http://example.com/public/x/secret") # An allowlist check on the normalized path passes, but the request reaches /secret def allowed?(url) = Addressable::URI.parse(url).normalize.path.start_with?("/public/") puts allowed?(url) ``` Output with Addressable 2.9.0: ``` /public/x/secret /secret /public/x/secret true true ``` Output with Addressable 2.9.1: ``` /secret /secret /secret false false ``` ### Impact This is an interpretation conflict (CWE-436) between Addressable and other RFC 3986 resolvers, which could lead to path traversal past an allowlist (CWE-22). An application is affected when it does both of these: - makes an access decision on a path normalized or joined by Addressable, such as "only paths under `/public/` may be proxied" or "only these redirect targets are allowed"; - sends the original, unnormalized URI to a component that resolves dot segments itself, such as an HTTP client, a proxy, a web server or a browser. An attacker may be able to bypass a check by exploiting behavioral differences between URI parsers. Impact from this is application-dependent. Applications that use Addressable's normalized form for both the check and the request are unaffected, as are applications that reject paths containing `..` segments. As a work-around for unpatched versions, before making access decisions on a path, either reject any containing `..` segments, including percent-encoded forms such as `%2e%2e`, or use the same normalized value for both the check and the request.

### Impact `Addressable::URI.normalize_path` takes time quadratic in the number of nested dot segments in a path (e.g., `"/" + "a/" * n + "../" * n`, which for n = 3 is `/a/a/a/../../../`), because it removes one dot segment per pass over the whole path. `URI#normalize`, `URI#normalized_path`, `URI#==`, `URI#===` and `URI#join` all call it. Normalizing, comparing or joining a URI taken from user input can result in uncontrolled resource consumption, leading to denial of service. On 2.9.0, normalizing a 34 KB path takes about 3.5 seconds on MRI Ruby 4.0, and the cost grows with the square of the path length. This affects every Ruby implementation, including MRI Ruby 3.2 and later. `URI.parse` by itself is unaffected, as is code that never normalizes, compares, or joins URIs from untrusted sources. ### Affected Versions This vulnerability affects all versions of Addressable prior to 2.9.1. It is fixed in 2.9.1. ### Workarounds - Limit the length of URIs taken from user input before calling `normalize`, `==` or `join` on them. Web servers often limit request lines to about 8 KB, which keeps the cost to about 150 milliseconds per call on typical hardware, but URIs from other sources (request bodies, headers such as `Location`, stored data) may not be limited. - Reject paths with many dot segments before normalizing them. ### Credits Reported by Matthew Mongeau (@halogenandtoast), Ruby Central Gem Security, who also suggested the single-pass approach used in the fix. ### For more information If there are any questions or comments about this advisory: * [Open an issue](https://github.com/sporkmonger/addressable/issues)

### Impact `Addressable::IDNA.to_unicode` decodes Punycode labels (labels beginning with `xn--`) that contain characters which change how text is displayed without being visible themselves. These include bidirectional controls such as U+202E RIGHT-TO-LEFT OVERRIDE and U+2066–U+2069, zero-width characters, and other invisible format characters. `Addressable::URI#display_uri` uses `to_unicode`, so it can display a host whose characters appear reordered or which looks identical to a different host. For example, the host of `http://xn--abcmoc-dm0c.com/` is displayed as `abc`, U+202E, `moc.com`, and the override makes everything after `abc` render right to left. Parsing, `host`, `normalized_host` and any connection made from the URI are not affected. Only the displayed form is. Applications that show `display_uri` to users (link previews, chat and email clients, admin interfaces) can be used to make a malicious domain look like a trusted one. - In the pure-Ruby IDNA implementation, all such characters are decoded, including those that IDNA's nameprep profile prohibits. - In the native IDNA implementation, used when libidn and the `idn-ruby` gem are installed, libidn rejects most of them, but not characters added to Unicode after version 3.2, such as U+061C and U+2066–U+2069. ### Affected Versions The pure-Ruby IDNA implementation is affected in Addressable >= 2.0.0. The native IDNA implementation is affected in Addressable >= 2.5.2, when `to_unicode` began accepting characters unassigned in Unicode 3.2. It is fixed in 2.9.1 for both implementations, where such labels are returned unchanged. ### Workarounds - Install libidn and the `idn-ruby` gem, so that Addressable uses the native IDNA implementation. This reduces the affected characters to those added since Unicode 3.2. - Check displayed hosts for bidirectional and invisible characters (e.g., `/[\p{Cc}\p{Cf}\p{Default_Ignorable_Code_Point}]/`) and fall back to `normalized_host` when one is present. ### Credits Reported by @andrewstellman. ### For more information If there are any questions or comments about this advisory: * [Open an issue](https://github.com/sporkmonger/addressable/issues)

### Impact `Addressable::IDNA.to_unicode`, in the pure-Ruby IDNA implementation, decodes Punycode labels (labels beginning with `xn--`) that are not valid A-labels. Those labels are returned in decoded form, when they should be returned unchanged. That includes: - labels that decode to only ASCII characters, e.g. `xn--google-` decodes to `google`; - labels that decode to text that doesn't convert back to the same label (RFC 3490 §4.2), e.g. text that isn't in normalized form. `Addressable::URI#display_uri` uses `to_unicode`, so for `https://xn--google-.example.org/` it displays the host `google.example.org`, while `#host`, `#normalized_host` and any connection made from the URI use `xn--google-.example.org`. An attacker who controls a domain can therefore have a URI displayed as a host they don't control. Applications that compare the result of `to_unicode` against a list of trusted names can likewise treat two different hosts as the same. The native IDNA implementation, used when libidn and the `idn-ruby` gem are installed, is not affected. `to_ascii` and `normalized_host` are not affected. ### Affected Versions This vulnerability affects Addressable >= 2.0.0, the first version with the pure-Ruby IDNA implementation, when that implementation is in use. It is fixed in 2.9.1, where such labels are returned unchanged, as with libidn. ### Workarounds - Install libidn and the `idn-ruby` gem, so that Addressable uses the native IDNA implementation. - Don't make security decisions on `display_uri` or `to_unicode` output. Compare hosts using `normalized_host`. ### Credits Reported by @tonghuaroot. ### For more information If there are any questions or comments about this advisory: * [Open an issue](https://github.com/sporkmonger/addressable/issues)

Addressable versions from 2.3.0 (earliest installable 2.3.2) through 2.9.0 contain a Regular Expression Denial of Service (ReDoS) vulnerability in URI template matching. Templates with multiple variables in one expression or several adjacent expressions generate regular expressions vulnerable to excessive backtracking, causing high CPU usage and denial of service when matching crafted URIs. The issue affects Ruby implementations with backtracking regex engines such as MRI Ruby < 3.3, JRuby, and TruffleRuby 40.0. The vulnerability is fixed in Addressable 2.9.1 and mitigated in MRI Ruby 3.3 and later.

Addressable versions from 2.3.0 (excluding yanked 2.3.0 and 2.3.1) through 2.9.0 contain a Regular Expression Denial of Service (ReDoS) vulnerability in URI template matching when using the explode (*) modifier with certain operators. This flaw causes catastrophic backtracking in regex matching, leading to exponential processing time and denial of service when matching maliciously crafted URIs. The issue affects Ruby implementations with non-memoizing regex engines such as MRI Ruby versions before 3.2 and JRuby. It is fixed in Addressable 2.9.1 and in MRI Ruby 3.2 and later. Users only expanding templates or using URI parsing without template matching are not impacted.