Threats affecting pkg:brew/weaviate-cli

## Summary Authlib’s JWS verification accepts tokens that declare unknown critical header parameters (`crit`), violating RFC 7515 “must‑understand” semantics. An attacker can craft a signed token with a critical header (for example, `bork` or `cnf`) that strict verifiers reject but Authlib accepts. In mixed‑language fleets, this enables split‑brain verification and can lead to policy bypass, replay, or privilege escalation. ## Affected Component and Versions - Library: Authlib (JWS verification) - API: `authlib.jose.JsonWebSignature.deserialize_compact(...)` - Version tested: 1.6.3 - Configuration: Default; no allowlist or special handling for `crit` ## Details RFC 7515 (JWS) §4.1.11 defines `crit` as a “must‑understand” list: recipients MUST understand and enforce every header parameter listed in `crit`, otherwise they MUST reject the token. Security‑sensitive semantics such as token binding (e.g., `cnf` from RFC 7800) are often conveyed via `crit`. Observed behavior with Authlib 1.6.3: - When a compact JWS contains a protected header with `crit: ["cnf"]` and a `cnf` object, or `crit: ["bork"]` with an unknown parameter, Authlib verifies the signature and returns the payload without rejecting the token or enforcing semantics of the critical parameter. - By contrast, Java Nimbus JOSE+JWT (9.37.x) and Node `jose` v5 both reject such tokens by default when `crit` lists unknown names. Impact in heterogeneous fleets: - A strict ingress/gateway (Nimbus/Node) rejects a token, but a lenient Python microservice (Authlib) accepts the same token. This split‑brain acceptance bypasses intended security policies and can enable replay or privilege escalation if `crit` carries binding or policy information. ## Proof of Concept (PoC) This repository provides a multi‑runtime PoC demonstrating the issue across Python (Authlib), Node (`jose` v5), and Java (Nimbus). ### Prerequisites - Python 3.8+ - Node.js 18+ - Java 11+ with Maven ### Setup Enter the directory **authlib-crit-bypass-poc** & run following commands. ```bash make setup make tokens ``` ### Tokens minted - `tokens/unknown_crit.jwt` with protected header: `{ "alg": "HS256", "crit": ["bork"], "bork": "x" }` - `tokens/cnf_header.jwt` with protected header: `{ "alg": "HS256", "crit": ["cnf"], "cnf": {"jkt": "thumb-42"} }` ### Reproduction Run the cross‑runtime demo: ```bash make demo ``` Expected output for each token (strict verifiers reject; Authlib accepts): For `tokens/unknown_crit.jwt`: ``` Strict(Nimbus): REJECTED (unknown critical header: bork) Strict(Node jose): REJECTED (unrecognized crit) Lenient(Authlib): ACCEPTED -> payload={'sub': '123', 'role': 'user'} ``` For `tokens/cnf_header.jwt`: ``` Strict(Nimbus): REJECTED (unknown critical header: cnf) Strict(Node jose): REJECTED (unrecognized crit) Lenient(Authlib): ACCEPTED -> payload={'sub': '123', 'role': 'user'} ``` Environment notes: - Authlib version used: `1.6.3` (from PyPI) - Node `jose` version: `^5` - Nimbus JOSE+JWT version: `9.37.x` - HS256 secret is 32 bytes to satisfy strict verifiers: `0123456789abcdef0123456789abcdef` ## Impact - Class: Violation of JWS `crit` “must‑understand” semantics; specification non‑compliance leading to authentication/authorization policy bypass. - Who is impacted: Any service that relies on `crit` to carry mandatory security semantics (e.g., token binding via `cnf`) or operates in a heterogeneous fleet with strict verifiers elsewhere. - Consequences: Split‑brain acceptance (gateway rejects while a backend accepts), replay, or privilege escalation if critical semantics are ignored. ## References - RFC 7515: JSON Web Signature (JWS), §4.1.11 `crit` - RFC 7800: Proof‑of‑Possession Key Semantics for JWTs (`cnf`)

### Impact A leniency in h11's parsing of line terminators in chunked-coding message bodies can lead to request smuggling vulnerabilities under certain conditions. ### Details HTTP/1.1 Chunked-Encoding bodies are formatted as a sequence of "chunks", each of which consists of: - chunk length - `\r\n` - `length` bytes of content - `\r\n` In versions of h11 up to 0.14.0, h11 instead parsed them as: - chunk length - `\r\n` - `length` bytes of content - any two bytes i.e. it did not validate that the trailing `\r\n` bytes were correct, and if you put 2 bytes of garbage there it would be accepted, instead of correctly rejecting the body as malformed. By itself this is harmless. However, suppose you have a proxy or reverse-proxy that tries to analyze HTTP requests, and your proxy has a _different_ bug in parsing Chunked-Encoding, acting as if the format is: - chunk length - `\r\n` - `length` bytes of content - more bytes of content, as many as it takes until you find a `\r\n` For example, [pound](https://github.com/graygnuorg/pound/pull/43) had this bug -- it can happen if an implementer uses a generic "read until end of line" helper to consumes the trailing `\r\n`. In this case, h11 and your proxy may both accept the same stream of bytes, but interpret them differently. For example, consider the following HTTP request(s) (assume all line breaks are `\r\n`): ``` GET /one HTTP/1.1 Host: localhost Transfer-Encoding: chunked 5 AAAAAXX2 45 0 GET /two HTTP/1.1 Host: localhost Transfer-Encoding: chunked 0 ``` Here h11 will interpret it as two requests, one with body `AAAAA45` and one with an empty body, while our hypothetical buggy proxy will interpret it as a single request, with body `AAAAXX20\r\n\r\nGET /two ...`. And any time two HTTP processors both accept the same string of bytes but interpret them differently, you have the conditions for a "request smuggling" attack. For example, if `/two` is a dangerous endpoint and the job of the reverse proxy is to stop requests from getting there, then an attacker could use a bytestream like the above to circumvent this protection. Even worse, if our buggy reverse proxy receives two requests from different users: ``` GET /one HTTP/1.1 Host: localhost Transfer-Encoding: chunked 5 AAAAAXX999 0 ``` ``` GET /two HTTP/1.1 Host: localhost Cookie: SESSION_KEY=abcdef... ``` ...it will consider the first request to be complete and valid, and send both on to the h11-based web server over the same socket. The server will then see the two concatenated requests, and interpret them as _one_ request to `/one` whose body includes `/two`'s session key, potentially allowing one user to steal another's credentials. ### Patches Fixed in h11 0.15.0. ### Workarounds Since exploitation requires the combination of buggy h11 with a buggy (reverse) proxy, fixing either component is sufficient to mitigate this issue. ### Credits Reported by Jeppe Bonde Weikop on 2025-01-09.