minibf: the pool metadata fetcher does not restrict the target or the response size

[michalrus]

Related:

• feat(minibf): add /governance/proposals/*/metadata routes #1295
• minibf: offchain metadata storage layer #1247
• fix: Improve pools and rewards endpoints #784
• chore(minibf): Add /pools/pool_id/metadata endpoint #975

Summary

The pool metadata fetcher in crates/minibf sends an HTTP request to a URL from on-chain pool metadata. The fetcher does not restrict the target address. The fetcher does not limit the response size.

#1295 added the governance proposal metadata routes. The PR also added a restricted fetch path for those routes. The pinned implementation rejects non-public targets and filters DNS results. It also applies the same restriction to redirect targets. The body reader limits each response to 3000000 bytes. The pool fetcher does not use this path.

Affected code

• pool_offchain_metadata builds an HTTP client and reads the complete body.
• fetch_pool_metadata_with_error builds a second HTTP client with the same problems.
• The pool list route starts one fetch for each pool at the same time.

Problem 1: the fetcher does not restrict the target

The client sends the request to any URL in the pool metadata. The URL can point to a private address. The URL can point to a loopback address. The URL can point to a link-local address. The URL can point to a cloud metadata service.

The hash check does not help here. The client reaches the target and reads the body before the hash check. The redirect policy permits three redirects. The policy does not restrict the redirect target.

The client uses the default DNS resolution. A hostname can resolve to a private address. A hostname can return a different address for a second request. This behavior makes a DNS rebinding attack possible.

Problem 2: the fetcher does not limit the response size

The client calls bytes() to read the full body. The client does not set a size limit. The client does not reject a large Content-Length value. A large body uses a large amount of memory.

The pool list route starts one fetch for each pool. The route runs the fetches at the same time. Many large bodies increase the total memory use.

Impact

An attacker can publish pool metadata with a hostile URL. A request to the pool endpoints can then reach an internal service. A large response can use too much memory.

Suggested fix

Use the restricted fetch path from #1295. Reuse its target restrictions. Reuse its bounded body reader. Make the path reusable for pool metadata and governance metadata.

1. Reject a URL that is not HTTP or HTTPS.
2. Reject a URL whose host is a private or special IP address.
3. Resolve each hostname through a DNS filter that removes non-public addresses.
4. Apply the same address restriction to every redirect.
5. Do not use a configured proxy for these requests.
6. If the Content-Length is more than the limit, reject the response.
7. Read the body in chunks and stop at the limit.
8. Use a limit of 3000000 bytes, which is the cardano-db-sync limit for vote metadata.

References

• pool_offchain_metadata builds an unrestricted client and reads an unbounded body.
• fetch_pool_metadata_with_error builds a second unrestricted client.
• fetch_pool_metadata_with_error sends the unchecked request and reads an unbounded body.
• The pool list route starts all metadata fetches at the same time.
• PR #1295 filters DNS results.
• PR #1295 rejects non-public URL targets.
• PR #1295 disables proxies and restricts redirect targets.
• PR #1295 restricts the initial request target.
• PR #1295 limits the declared size and the streamed body size.
• cardano-db-sync restricts connections to private and special addresses.
• cardano-db-sync reads a bounded body and rejects a body that exceeds the limit.