Project

General

Profile

Actions

Bug #5981

closed
SB SB

smtp: Long DATA line post boundary is capped at 4k Bytes

Bug #5981: smtp: Long DATA line post boundary is capped at 4k Bytes

Added by Shivani Bhardwaj about 3 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Normal
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

This can affect for example size and content of the logged file in case of multipart MIME.


Subtasks 1 (0 open1 closed)

Bug #5982: smtp: Long DATA line post boundary is capped at 4k Bytes (6.0.x backport)ClosedShivani BhardwajActions

SB Updated by Shivani Bhardwaj about 3 years ago Actions #1

  • Target version changed from 6.0.12 to 7.0.0-rc2

OT Updated by OISF Ticketbot about 3 years ago Actions #2

  • Subtask #5982 added

OT Updated by OISF Ticketbot about 3 years ago Actions #3

  • Label deleted (Needs backport to 6.0)

SB Updated by Shivani Bhardwaj about 3 years ago Actions #4

  • 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

SB Updated by Shivani Bhardwaj about 3 years ago Actions #5

  • Status changed from Rejected to In Progress

Reopening because the anomaly doesn't mean the processing necessarily stops. Needs more testing.

SB Updated by Shivani Bhardwaj almost 3 years ago Actions #6

  • Status changed from In Progress to In Review

PA Updated by Philippe Antoine almost 3 years ago Actions #7

Why is this urgent ?
I think https://redmine.openinfosecfoundation.org/issues/3487 solves this issue

SB Updated by Shivani Bhardwaj almost 3 years ago Actions #8

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.

VJ Updated by Victor Julien almost 3 years ago Actions #9

  • Status changed from In Review to Resolved

VJ Updated by Victor Julien almost 3 years ago Actions #10

  • Status changed from Resolved to Closed

VJ Updated by Victor Julien almost 3 years ago Actions #11

  • Private changed from Yes to No
Actions

Also available in: PDF Atom