Ipreassembler header issue #417
Open
Conversation
This file contains 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
added 5 commits
October 2, 2018 13:57
A malformed IP6Address, i.e. with more than 8 components, will cause the memmove/memset at the end of parsing to fail. This code is supposed to move the post-:: bytes to the end of the address and zero out the bytes in the center. Instead, it moves some of the bytes the wrong way, potentially writing prior to parts[] and then zeroing with a negative size. Instead, make the parser stop when it hits 8 components and let parse figure out that we did not consume the entire String. Thanks: American Fuzzy Lop Change-Id: I2966cb22fb5b44eb9e92dfc6a94e891cf5d02fa7
The check here appears to be intended to make sure that we only connect if both indexes are valid; specifically, idx can be -1. Unfortunately, it checks (*cp)[0] twice. Instead, check (*cp)[1] too. Thanks, American Fuzzy Lop Change-Id: I5cdeb45ac0cef5bbb0a18c6f19b4540df8007bfe
…Packet::data These two uint16_ts may end up placed at arbitrary offsets into a packet. In order to generate proper unaligned read/write instructions, mark the struct as packed. This was exposed by Defensic suite IPv4 Header Fragment-offset, test 45067 and discovered by Waldin Stone. I verified it by asserting proper alignment of ChunkLinks and found that they were not always properly aligned.
When storing the first of a series of fragments, IPReassembler copies the IP header from the fragment to the reassembly buffer. However, the header of the new fragment may not be the same length as the original fragment that created the buffer. If the new fragment's header is shorter, we will end up with weirdness preceeding the payload. If the new fragment's header is longer, we will overwrite the payload and possibly overrun it. Both cases show up as 'bad mem_used' warnings. Changing header_delta in the p_off=0 case to account for header length changes (and not just offset changes) fixes the issue. Found by Waldin Stone, running Defensics. Signed-off-by: pallas@meraki.com
We actually need to make sure to expand the data area to hold ChunkLink; right now, it's just checking the size of the data, so we might write out of bounds later on. Found-by: jtruba@meraki.com Thanks: AddressSanitizer
# for free
to join this conversation on GitHub.
Already have an account?
# 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.
No description provided.