[Snort-devel] Email mime part data_state reassembly problem
Bhagya Bantwal (bbantwal)
bbantwal at ...3461...
Thu Dec 11 10:03:03 EST 2014
So this code actually just returns a paf verdict PAFLIMIT and not PAFFLUSH. This was added to handle boundaries split across packets (especially at the LF--). It shouldn't cause the flush of attachments with LF. Are you seeing this behavior?
From: Mitesh Jadia <mitesh.jadia at ...2499...<mailto:mitesh.jadia at ...2499...>>
Date: Tuesday, December 9, 2014 2:57 AM
To: "Snort-devel at lists.sourceforge.net<mailto:Snort-devel at ...362....net>" <Snort-devel at lists.sourceforge.net<mailto:Snort-devel at ...2763...rge.net>>
Subject: [Snort-devel] Email mime part data_state reassembly problem
I found that when \n character found in mime data following mime header found in pop paf function flushes stream at that point.
scanning_boundary function is responsible for that.
static inline bool scanning_boundary(MimeDataPafInfo *mime_info, uint32_t boundary_start, uint32_t* fp)
if (boundary_start &&
mime_info->data_state == MIME_PAF_FOUND_BOUNDARY_STATE &&
mime_info->boundary_state != MIME_PAF_BOUNDARY_UNKNOWN)
*fp = boundary_start;
current logic says that when \n is found (means mime->info.data_state = MIME_PAF_BOUNDARY_LF) then if condition will be true (other two conditions are also true in this case) and flush point will be set. Now it is possible that \n character can be there in attachment data.
As per my logic when all three characters '\n--' should be there before setting flush point by this condition. This solution will perform proper flushing by paf function. Also this problem may be in smtp and imap as scanning_boundary function is common for them.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Snort-devel