Clam 1643 cli_ac_addsig 2 byte over-read #611
Merged
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.
Fix possible 2-byte overread when adding sig pattern
It is possible to create a signature pattern that tries to add a
zero-byte matching pattern to the A-C trie. A missing check at this
stage can end up with a 2-byte overread when indexing the (empty)
pattern to make sure the bytes added to the A-C trie are static and
not both zero.
This over read issue is not a vulnerability.
This commit fixes the issue by adding a check for the pattern length.
Resolves: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=43832
Also added:
over read.
Add code comments to explain AC pattern prefix process
When adding a pattern to the AC trie, checks are done to make sure the
bytes that go in the AC trie don't have any
?wildcards andadditionally that the first two bytes are not "\x00\x00".
If they are, the position of the pattern that goes in the AC trie can be
shifted right until a static pattern is identified that can go in the
AC trie. Any bytes to the left of the new start of the pattern become a
"prefix".
During matching, once the AC trie match occurs and the bytes to the
right of that pattern are matched, then the bytes from the prefix are
matched.
The reason that we don't want the bytes that go in the AC trie to start
with "\x00\x00" is that it is such a common pattern in files that it
would match constantly, and the scan process would spend a lot of time
just checking through the list of patterns associated with a "\x00\x00"
AC match, and that'd be crazy slow.
But it is important to note that when shifting right, if there aren't
enough nonzero, non-wildcard bytes to form a good prefix for the AC
trie, that it is tolerable to bend the rule and let some patterns start
with "\x00\x00". In that way, a small pattern like "0000ab" is still
valid, and can be matched.