fix(tools): stop reading scope operators as leaked IPv6 addresses - #63
Merged
Conversation
IPV6_RE allows empty hex groups, so a C++ or Rust scope operator preceded by a hex letter matches: TbsCertificate::signature_alg yields "e::", which ipaddress parses as a valid address in the all-zero reserved block. #60 fails share-safety on exactly that line. _safe_ipv6 now also accepts an address in an IETF-reserved block. Those are not assignable to a host, so they cannot be the leak this rule exists to catch, while global unicast, link-local and unique-local stay flagged and cover every real case. Tightening the regex instead would drop link-local addresses, which are the ones that leak out of captures.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
check_share_safety.pyreads a C++ or Rust scope operator as a leaked IPv6 address and fails the build.Surfaced on #60, where the line
reports
NON_DOCUMENTATION_IPV6.IPV6_REallows empty hex groups, so it matchese::out of...ficate::signature, andipaddressparses that as a valid address in the all-zero reserved block. Any scope operator preceded by a hex letter does it.The fix
_safe_ipv6now also accepts an address in an IETF-reserved block. Such an address is not assignable to a host, so it cannot be the leak the rule exists to catch. Global unicast, link-local and unique-local all sit outside the reserved set and stay flagged, which is the whole population of real leaks: a device on somebody's LAN has one of those three.Tightening the regex was the alternative and it is worse. The obvious tightening, requiring a substantial first group, drops link-local addresses, which are exactly what leaks out of a capture.
Residual gap
A NAT64-prefixed address written entirely in hex now passes. The dotted-tail form of the same address is still caught by
IPV4_REon the same line. Contriving the hex form as an exfiltration route seems less likely than the false positive it costs.Tests
Two added: scope operators in the shapes that appear in these docs produce no findings, and link-local, unique-local and global unicast each still report
NON_DOCUMENTATION_IPV6. Both follow the file's existing convention of splitting literals so the test file does not trip the checker scanning it.405 pass, and the checker scans its own source and tests clean. #60's document scans clean with no change to it.