dns: fix EDNS0ClientSubnet address truncation for non-octet-aligned prefix lengths#4960
Open
T3pp31 wants to merge 2 commits intosecdev:masterfrom
Open
dns: fix EDNS0ClientSubnet address truncation for non-octet-aligned prefix lengths#4960T3pp31 wants to merge 2 commits intosecdev:masterfrom
T3pp31 wants to merge 2 commits intosecdev:masterfrom
Conversation
…refix lengths When source_plen is set to a value whose ceil(plen/8) byte count exceeds the number of non-zero bytes in the address (e.g. source_plen=23 for 101.132.0.0), _pack_subnet incorrectly stripped the trailing zero byte, producing a 2-byte address instead of the required 3 bytes. Per RFC 7871, the ADDRESS field MUST be truncated to ceil(source_plen/8) bytes. Fix _pack_subnet to accept an optional plen parameter and apply RFC-compliant truncation when it is provided. i2m and i2len now pass pkt.source_plen so the correct byte count is used during packet building. Fixes: secdev#4942
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #4960 +/- ##
==========================================
- Coverage 80.30% 80.30% -0.01%
==========================================
Files 379 379
Lines 93164 93173 +9
==========================================
- Hits 74820 74818 -2
- Misses 18344 18355 +11
🚀 New features to boost your workflow:
|
RFC 7871 requires that the ADDRESS field be padded with 0 bits to the end of the last octet. The previous fix correctly computed the number of bytes (ceil(plen/8)) but left host bits set in the final partial byte when plen is not a multiple of 8. For example, source_plen=23 on 101.132.255.0 should produce 0xfe as the third byte, not 0xff. Apply a bitmask to the last byte when plen % 8 != 0, and add regression tests for IPv4 and IPv6 cases where the input address has host bits set.
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
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.
Summary
Fixes #4942.
EDNS0ClientSubnet._pack_subnethad two related bugs whensource_plenis set explicitly:ceil(source_plen / 8), sosource_plen=23on101.132.0.0produced a 2-byte address instead of 3.source_plen=23on101.132.255.0must produce0xfeas the third byte, not0xff.Per RFC 7871 §6:
Changes
_pack_subnetnow accepts an optionalplenparameter. When provided it truncates to exactlyceil(plen / 8)bytes and masks off host bits in the last partial byte whenplen % 8 != 0.i2mandi2lenpasspkt.source_plenso explicit prefix lengths are respected during packet building.plenisNone(auto-detect mode) the original trailing-zero-stripping behaviour is preserved.Reproduction
Tests
Five regression tests added to
test/scapy/layers/dns_edns0.uts:source_plen=23with trailing-zero last byte (original report)source_plen=24octet-aligned sanity checksource_plen=0produces empty address fieldsource_plen=23with host bits set in last byte (IPv4)source_plen=33with host bits set in last byte (IPv6)