Project

General

Profile

Bug #4245

SMTP/Email Body md5: Only logs the md5 of the first part in a multi-part mime message

Added by Jason Ish 6 months ago. Updated 5 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:
Needs backport to 5.0, Needs backport to 6.0

Description

When computing the MD5 of an email body in, the mime decoding appears to attempt to build the hash up over the contents of each mime part. The issue is that ProcessBodyComplete is called at the end of each part wich results in "HASH_End" being called. As the same MD5 context continues to be used, the hash is no longer updated as libnss appears to accept updates, but continued calls to HASH_End keep returning the value from the first HASH_End.

I found this while converting to the Rust MD5 implementation which free's the MD5 context when finalized (the equivalent to HASH_End). By tweaking the Rust MD5 bindings I can let it continue accumulate after "finalize", but it would probably be better to wait until the message is completed, instead of doing this at the end of every part, if thats an easy enough modification, as I'd rather keep the behaviour where the MD5 context is "consumed" upon finalization.


Related issues

Copied to Bug #4264: SMTP/Email Body md5: Only logs the md5 of the first part in a multi-part mime messageClosedJason IshActions
#1

Updated by Jason Ish 6 months ago

  • Status changed from New to In Review
#2

Updated by Victor Julien 5 months ago

  • Assignee set to Jason Ish
  • Target version set to 7.0rc1
  • Label Needs backport to 5.0, Needs backport to 6.0 added
#3

Updated by Victor Julien 5 months ago

  • Copied to Bug #4264: SMTP/Email Body md5: Only logs the md5 of the first part in a multi-part mime message added
#4

Updated by Jason Ish 5 months ago

  • Status changed from In Review to Closed

This was fixed in master via the the Rust hashing pull request: https://github.com/OISF/suricata/pull/5716

Also available in: Atom PDF