[Bro-Dev] [JIRA] (BIT-1235) HTTP multipart POST request alters file contents

Brian O'Berry (JIRA) jira at bro-tracker.atlassian.net
Tue Sep 9 13:22:07 PDT 2014

    [ https://bro-tracker.atlassian.net/browse/BIT-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18006#comment-18006 ] 

Brian O'Berry commented on BIT-1235:

Hi, Jon,

A quick update... I made the change as documented in BIT-1235, and we've been running it in our unit test environment since then.  All feedback is positive so far.  Our release cycle got extended to add a couple significant features, so the fix won't go into QA testing until the week after next.  If things go according to the new schedule, we'll have it running on our corporate network a week after that, where we'll watch it for another week or so.  I anticipate updating the ticket for the final time in 3 weeks or so.

Thanks again for the quick fix, and let me know if you need anything.



> HTTP multipart POST request alters file contents
> ------------------------------------------------
>                 Key: BIT-1235
>                 URL: https://bro-tracker.atlassian.net/browse/BIT-1235
>             Project: Bro Issue Tracker
>          Issue Type: Problem
>          Components: Bro
>    Affects Versions: 2.3
>         Environment: CentOS 6.5, file extract analyzer
>            Reporter: Brian O'Berry
>             Fix For: 2.4
>         Attachments: bro-2.3-HTTP.patch, gdb.log, upload-api-http.pcap
> HTTP POST multipart processing converts bare CR or LF chars to CRLF pairs, corrupting most files when extracted with Files::ANALYZER_EXTRACT.  This is clear in the attached gdb.log, which has a backtrace that shows a buffer with the start of a PDF file entering MIME/HTTP entity processing at frame 25, and emerging with LF chars converted to CRLF at frame 6.
> Also attached are the pcap file associated with the backtrace, and an initial patch that we've barely begun to test.  A point of concern with the patch is that it changes a weird.log entry from "line_terminated_with_single_CR" to "http_no_crlf_in_header_list".  It does enable Files::ANALYZER_EXTRACT to correctly extract the PDF file from the attached pcap.
> Please let me know if we can provide anything else to help with this.

This message was sent by Atlassian JIRA

More information about the bro-dev mailing list