GHSA-9xww-74xv-gjfp
Http4s: DigestAuth allows replay of captured requests
Packages
| Ecosystem | Package | Affected | Fixed in |
|---|---|---|---|
| Maven | org.http4s:http4s-ember-core_2.12 | < 0.23.35 | 0.23.35 |
| Maven | org.http4s:http4s-ember-core_2.13 | < 0.23.35 | 0.23.35 |
| Maven | org.http4s:http4s-ember-core_3 | < 0.23.35 | 0.23.35 |
| Maven | org.http4s:http4s-ember-core_2.13 | >= 1.0.0-M1, < 1.0.0-M47 | 1.0.0-M47 |
| Maven | org.http4s:http4s-ember-core_3 | >= 1.0.0-M1, < 1.0.0-M47 | 1.0.0-M47 |
Details
As written in the advisory (Markdown source, shown as plain text).
The `DigestAuth` replay defence stores `lastNc + 1` rather than the nonce-count (`nc`) value it just accepted. When a legitimate client sends non-contiguous `nc` values (parallel or retried requests, as browsers do), the server's counter lags behind the highest `nc` seen, and a captured `Authorization` header can be replayed multiple times.
## Impact
A passive observer can turn one captured Digest-authenticated request into several replayed authenticated (state-changing) requests, defeating the core
replay protection Digest provides over Basic.
## Preconditions
- Application uses `DigestAuth`.
- Attacker can passively observe at least one legitimate digest request.
- Legitimate client emits an `nc` more than one greater than the last, for instance from a parallel or retried request.
## Workarounds
- Deploy over TLS so requests cannot be captured.
References
External links from the advisory. They lead to third-party sites.