Bug #5981
closed
smtp: Long DATA line post boundary is capped at 4k Bytes
Added by Shivani Bhardwaj over 1 year ago.
Updated over 1 year ago.
Description
This can affect for example size and content of the logged file in case of multipart MIME.
- Target version changed from 6.0.12 to 7.0.0-rc2
- Label deleted (
Needs backport to 6.0)
- Status changed from Assigned to Rejected
While trying to create a test to prove this issue, when I was successfully able to create the test, I noticed an anomaly
event MIME_LONG_LINE
. Upon investigating the code and then the RFC 2045 and 2822, I found that if we receive more than 998 bytes as a part of MIME
excluding CRLF
, we must ideally reject the line as the 998 character limit is due to limitations in many implementations which send, receive, or store Internet Message Format messages that simply cannot handle more than 998 characters on a line
In fact, modern implementations are enforcing 78 Bytes long line.
Conclusion: Even in theory, if this happens, we have it handled well as it should be as per the RFCs. This issue is invalid and must be rejected.
Demonstrated by test https://github.com/OISF/suricata-verify/pull/1187
- Status changed from Rejected to In Progress
Reopening because the anomaly doesn't mean the processing necessarily stops. Needs more testing.
- Status changed from In Progress to In Review
Philippe Antoine wrote in #note-7:
Why is this urgent ?
It was set to urgent bc we wanted to include it in the last release. Then, we decided to leave it to the future release.
I think https://redmine.openinfosecfoundation.org/issues/3487 solves this issue
oh. I also have an MR. I'll check your PR w the test.
- Status changed from In Review to Resolved
- Status changed from Resolved to Closed
- Private changed from Yes to No
Also available in: Atom
PDF