New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
File hashing 4279 v4 #5929
File hashing 4279 v4 #5929
Conversation
Files are truncated when they exceed stream reassembly depth. However, for some purposes, a hash of the prefix of the file is still useful, as long as we know the size of this prefix. We therefore change the logging logic to output the hash in the case of file truncation.
Allow capping number of bytes of files used for file hash. This is to allow for consistency and avoid relying on whatever the stream reassembly limit happens to be. If 0 or not present, the original behaviour of hashing up to the stream reassembly limit remains. If the value is greater than the stream reassembly limit, the stream reassembly limit takes precedence.
5ef4d2e
to
eba5b5c
Compare
Codecov Report
@@ Coverage Diff @@
## master #5929 +/- ##
==========================================
- Coverage 76.69% 76.68% -0.01%
==========================================
Files 604 604
Lines 187657 187837 +180
==========================================
+ Hits 143926 144046 +120
- Misses 43731 43791 +60
Flags with carried forward coverage won't be shown. Click here to find out more. |
eba5b5c
to
5142b09
Compare
if !bytes_hashed.is_null() { | ||
if g_hash_byte_limit > 0 { | ||
let bytes_remaining = match g_hash_byte_limit > *bytes_hashed { | ||
true => g_hash_byte_limit - *bytes_hashed, | ||
false => 0, | ||
}; | ||
if len > bytes_remaining { | ||
len = bytes_remaining; | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like the length logic being put into a low level hashing function which is not file-store specific. I think this accounting should be moved out of here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general I'm in favour of this approach, I just don't want specifics of filestore to leak into the lower level hashing API.
Ping @rtkjweeks, any plans to continue on this? |
If urilen induced depth was set, later DetectContentPropagateLimits() would apply a wrong depth setting, leading to a false negative in some cases. Bug: OISF#5929.
If urilen induced depth was set, later DetectContentPropagateLimits() would apply a wrong depth setting, leading to a false negative in some cases. Bug: OISF#5929.
If urilen induced depth was set, later DetectContentPropagateLimits() would apply a wrong depth setting, leading to a false negative in some cases. Bug: OISF#5929.
If urilen induced depth was set, later DetectContentPropagateLimits() would apply a wrong depth setting, leading to a false negative in some cases. Bug: OISF#5929.
Make sure these boxes are signed before submitting your Pull Request -- thank you.
Link to redmine ticket:
https://redmine.openinfosecfoundation.org/issues/4279
Previous PR:
#5882
Describe changes:
suricata-verify-pr: 430
#suricata-verify-repo:
#suricata-verify-branch:
#suricata-update-pr:
#suricata-update-repo:
#suricata-update-branch:
#libhtp-pr:
#libhtp-repo:
#libhtp-branch: