https://redmine.openinfosecfoundation.org/https://redmine.openinfosecfoundation.org/favicon.ico?17011170022010-08-27T09:51:54ZOpen Information Security FoundationSuricata - Bug #231: http related segv'shttps://redmine.openinfosecfoundation.org/issues/231?journal_id=8532010-08-27T09:51:54ZPablo Rinconpablo.rincon.crespo@gmail.com
<ul><li><strong>File</strong> <a href="/attachments/314">0001-Fix-a-segv-if-there-is-an-error-at-libhtp-no-connp.patch</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/314/0001-Fix-a-segv-if-there-is-an-error-at-libhtp-no-connp.patch">0001-Fix-a-segv-if-there-is-an-error-at-libhtp-no-connp.patch</a> added</li><li><strong>Status</strong> changed from <i>New</i> to <i>Assigned</i></li><li><strong>Assignee</strong> set to <i>Pablo Rincon</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>50</i></li></ul><p>Check the not NULL of connp and conn before using them. I guess that the problem is more related to libhtp, that unset the pointer connp, but anyway I think that the engine must check this pointers to avoid a crash, so uploading a patch for this.</p>
<p>It would be nice to have a pcap of that filtered session, and/or suricata logs to know how that pointer ended to be NULL.</p> Suricata - Bug #231: http related segv'shttps://redmine.openinfosecfoundation.org/issues/231?journal_id=8542010-08-27T10:08:18ZPablo Rinconpablo.rincon.crespo@gmail.com
<ul><li><strong>File</strong> <a href="/attachments/315">0001-Fix-segv-condition-on-DetectHttpMethodMatch-if-the-a.patch</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/315/0001-Fix-segv-condition-on-DetectHttpMethodMatch-if-the-a.patch">0001-Fix-segv-condition-on-DetectHttpMethodMatch-if-the-a.patch</a> added</li></ul><p>That patch has a strange character and it doesn't compile correctly. Use this one instead.<br />Btw, what about the fix at libhtp? should I send a patch? or ping Ivan?</p> Suricata - Bug #231: http related segv'shttps://redmine.openinfosecfoundation.org/issues/231?journal_id=8682010-08-30T04:48:40ZVictor Julienvictor@inliniac.net
<ul></ul><p>That second segv is quite strange. It is true that hs is set to "state" before the lock, but it's a local variable. So even if the htp state changes, hs would never change. It could point to invalid memory, but the var itself should never become NULL unless state was NULL when hs was set. But then the if (hs == NULL) check should have fixed that. Did you compile suricata at a high optimization level perhaps? Maybe gcc reordered code so the check is bypassed...</p> Suricata - Bug #231: http related segv'shttps://redmine.openinfosecfoundation.org/issues/231?journal_id=8692010-08-30T05:04:04ZPablo Rinconpablo.rincon.crespo@gmail.com
<ul></ul><p>I don't think that the null pointer is hs. I think that connp was NULL.<br />Can you please rerun that pcap with gdb and attach here the backtrace, also printing hs and hs->connp and hs->connp->conn ?<br />It would be helpful.</p> Suricata - Bug #231: http related segv'shttps://redmine.openinfosecfoundation.org/issues/231?journal_id=8702010-08-30T06:17:07ZVictor Julienvictor@inliniac.net
<ul></ul><p>I've applied your patch Pablo.</p>
<p>Lets report the htp issue to Ivan if we have more detailed info like a backtrace.</p> Suricata - Bug #231: http related segv'shttps://redmine.openinfosecfoundation.org/issues/231?journal_id=8812010-09-02T04:27:08ZVictor Julienvictor@inliniac.net
<ul><li><strong>Target version</strong> set to <i>1.0.2</i></li></ul><p>Closing for now. Please reopen or open a new ticket if the issue resurfaces.</p> Suricata - Bug #231: http related segv'shttps://redmine.openinfosecfoundation.org/issues/231?journal_id=8822010-09-02T04:27:18ZVictor Julienvictor@inliniac.net
<ul><li><strong>Status</strong> changed from <i>Assigned</i> to <i>Closed</i></li><li><strong>% Done</strong> changed from <i>50</i> to <i>100</i></li></ul>