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

[Jon Siwek (JIRA)]

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

Jon Siwek commented on BIT-1235:
--------------------------------

The fix I came up with is in the topic/jsiwek/bit-1235 branch, are you able to verify your own test cases work better with the change?  My own testing seems to show things are only improved and nothing got worse, but as you've seen, some code/comments behind how this works are worrying (thanks for taking a crack at figuring it out).

> 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
>         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
(v6.4-OD-04-006#64001)