DHCP: implement RFC 3396 encoding of long options (fixes #4642)#4950
Open
StrugglingKeyboard wants to merge 1 commit intosecdev:masterfrom
Open
DHCP: implement RFC 3396 encoding of long options (fixes #4642)#4950StrugglingKeyboard wants to merge 1 commit intosecdev:masterfrom
StrugglingKeyboard wants to merge 1 commit intosecdev:masterfrom
Conversation
Split DHCP options longer than 255 bytes into multiple consecutive TLV entries during serialization (i2m), and concatenate consecutive options with the same code during dissection (m2i), as specified by RFC 3396. Also add support for option overload (code 52) in getfield, building the aggregate option buffer from the options, file and sname fields as described in RFC 3396 section 5.
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.
Description
Implements RFC 3396 (Encoding Long Options in DHCPv4) in Scapy's DHCP layer.
Fixes #4642
Problem
raw(DHCP(options=[('captive-portal', 'a'*256)]))was raisingstruct.error: ubyte format requires 0 <= number <= 255because the option length field is encoded as a single unsigned byte, limiting option values to 255 bytes. Similarly, receiving a DHCP packet containing consecutive options with the same code (as produced by RFC 3396 encoding) results in incorrect dissection.Changes
All changes are in
scapy/layers/dhcp.py, within the classDHCPOptionsField:i2m: options with values exceeding 255 bytes are automatically split into consecutive TLV fragments of at most 255 bytes each, all carrying the same option code._concat_fragments(new): helper method that concatenates consecutive raw fragments with the same option code.m2i: uses_concat_fragmentsto reassemble fragmented options before interpretation, for both known and unknown option codes._find_overload(new): scans the raw options buffer for optionoverload(code 52).getfield: when optionoverloadis present, builds the aggregate option buffer from the options, file and sname fields (RFC 3396 section 5) before passing it tom2i.Tests
Added a test covering: encoding (split at 256 bytes), decoding (fragment concatenation for typed fields, non-concatenation of non-consecutive fragments, unknown option codes), roundtrip (encode then decode), and option overload (negative and positive cases).
Note: Two pre-existing test failures in
test/scapy/layers/dhcp.uts(tests "DHCP - build" and "DHCP - dissection", both on the s5/p5 packet) are unrelated to this change and also fail on the current master branch.