Repository navigation
Conversation
oscap_expand_ipv6() counted one group too many when an address ended in "::", so fd19:c33d:98bc:: and "::" expanded to seven groups and the ARF failed the Asset Identification ip-v6 pattern. The parser also wrote into a fixed 40-byte buffer without bounds checks and read past the NUL when the input ended in a single ':'. Parse with inet_pton and print eight lowercase groups without leading zeros, which the pattern accepts. Input that is not an IPv6 address or carries a %zone is returned unchanged, since macOS inet_pton accepts zones and writes the interface index into link-local addresses. Signed-off-by: Josephine Pfeiffer <josie@redhat.com>
No test exercised this function directly, so the "::" miscount only showed up as ARF validation failures on hosts with such an address. Pin the eight-group output for compressed, uppercase, zero-padded and IPv4-embedded input, including one longer than the old 40-byte buffer, and the pass-through of zoned and malformed strings. Global addresses come from the documentation ranges in RFC 3849 and RFC 5737. Signed-off-by: Josephine Pfeiffer <josie@redhat.com>
433e0ae to
b190571
Compare
|
|
I tried this end to end, since the unit test doesn't go through a real scan. Fedora 44 arm64 container, main at 099cd84 against this branch at b190571, with On main, On this branch both are For the Windows build, |
oscap_expand_ipv6() counts one group too many when an address ends in "::", so a host with e.g. fd19:c33d:98bc:: (whonix's ipv6 setup puts that on its libvirt bridge) writes ARF that fails the asset identification ip-v6 pattern.
the parser also writes into a fixed 40-byte buffer without bounds checks and reads past the NUL when the input ends in a single ':'. both callers get target-address strings, which can come from input documents
this swaps it for inet_pton and prints eight lowercase groups. anything that isn't an IPv6 address, or has a %zone, comes back unchanged. the '%' check is there because macos inet_pton drops the zone and writes the interface index into link-local addresses, while glibc rejects it
on open question I have: zoned addresses still fail the ip-v6 pattern, same as before. afaict from wine's conformance tests, WSAAddressToStringW appends %scope on windows. stripping the zone before parsing would fix that but also drops it from xccdf:target-address. i can do that here or in a follow-up if you'd rather have it that way