archetech / archon / 32876748443

87%

push

github

fix(keymaster): Check the target of remote name lookups, on every path (#943)

* fix(keymaster): Check the target of remote name lookups, on every path

Remote name lookup fetches https://<domain>/.well-known/names from a
domain the caller supplies, so the target check is the only thing between
the API and the host's own network. There were two faults, and either one
alone leaves the door open.

The check ran on one path of three. isPrivateHostname was defined once
and called once, in resolveRemoteName, which is private. importAddress
and checkAddress are public, reachable over REST and as `import-address`
and `check-address` on the CLI, and neither consulted it. The guard now
lives in normalizeAddressDomain, which all three already funnel through,
so covering them is one check rather than three that can drift apart.

And the check read the start of the string rather than the address:

    /^(localhost|127\.|10\.|172\.(1[6-9]|2\d|3[01])\.|192\.168\.)/

169.254.169.254 -- the cloud metadata address, the first risk the issue
names -- walked straight past it, as did every IPv6 literal, and the
inet_aton spellings of loopback that the resolver honours but a
dotted-decimal reading does not see: 2130706433, 0177.0.0.1, 0x7f000001,
127.1. Replaced with real address parsing. It is written out by hand
because this package runs in browser wallets, where node:net does not
exist.

Redirects are re-checked rather than followed. fetch follows them by
default, so a public host answering 302 with a Location of
http://169.254.169.254/ reaches the address the check just rejected. Each
hop is now validated for scheme and target, the way the Lightning LUD-16
path already walks hops for the scheme alone.

The Python port had the same two surfaces and no check whatsoever, not
even the weak one, while httpx followed redirects. Fixed alongside, with
the cases kept in step: a hostname either port accepts is one both have
to account for. Only 100.64.0.0/10 needed stating expli... (continued)

3856 of 4438 branches covered (86.89%)

Branch coverage included in aggregate %.

8 of 122 new or added lines in 2 files covered. (6.56%)

8485 of 8909 relevant lines covered (95.24%)

686.61 hits per line