Open Information Security Foundation: Issueshttps://redmine.openinfosecfoundation.org/https://redmine.openinfosecfoundation.org/favicon.ico?17011170022015-06-11T01:28:12ZOpen Information Security Foundation
Redmine Suricata - Bug #1484 (New): Remove BUG_ON(1) statements in the packet pathhttps://redmine.openinfosecfoundation.org/issues/14842015-06-11T01:28:12ZVictor Julienvictor@inliniac.net
<p>As issue <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: suricata 2.1 beta4: StoreStateTxFileOnly crashes (Closed)" href="https://redmine.openinfosecfoundation.org/issues/1482">#1482</a>, but review all the BUG_ON's.</p> Suricata - Bug #1457 (Feedback): Non-standard prefixes used for file size indicationhttps://redmine.openinfosecfoundation.org/issues/14572015-04-28T13:40:17ZJames Moejimoe@sohnen-moe.com
<p>Here is a typical conversation regarding sizes in bytes:</p>
<blockquote><blockquote>
<p>i increased the stream memcap from default 32mb to 128mb;</p>
</blockquote>
<p>I think you can try setting this to 512mb</p>
<blockquote>
<p>i decreased the reassembly memcap from default 128mb to 64mb.</p>
</blockquote>
<p>and this to 1024mb</p>
</blockquote>
mb = milli-bit<br /> Mb = mega-bit<br /> MB = mega-byte
The metric and binary prefixes are case-sensitive. They are international standards. Usually the context is sufficient to sort what it really meant. But not always; and I find it bothersome to see such misuse.<br /> I feel it professionally imperative to use the correct language, especially in the context of networking where traffic may be discussed in both bytes and bits per second.
The same applies for most of the other letters, k (kilo) being an exception.<br /> See <<a class="external" href="http://en.wikipedia.org/wiki/Metric_prefix">http://en.wikipedia.org/wiki/Metric_prefix</a>> and <br /><<a class="external" href="http://en.wikipedia.org/wiki/Binary_prefix&gt;">http://en.wikipedia.org/wiki/Binary_prefix&gt;</a>. Suricata - Bug #1412 (New): byte_test checks before byte_extract happens in some caseshttps://redmine.openinfosecfoundation.org/issues/14122015-03-12T09:15:11ZDavid Wharton
<p>When there is a byte_extract in the http_raw_header (or http_header) buffer, and it is used in a byte_test in the file_data (or http_server_body) buffer, it doesn't work as expected. I am not sure if other buffer combinations have this issue as well.</p>
<p>The byte_test comparison (DetectBytetestDoMatch() in detect-bytetest.c, called by DetectEngineContentInspection() in detect-engine-content-inspection.c) happens <strong>before</strong> the bytes in byte_extract are actually extracted (extraction done in ByteExtractString() in util-byte.c, which is called by DetectByteExtractDoMatch() in detect-byte-extract.c). This results in the value used in the byte_test comparison being 0 instead of being the value from the byte_extract.</p>
<p>The issue isn't the extractions themselves in byte_extract or byte_test (these work fine), the problem is that the comparison done by byte_test (using a variable from byte_extract) is done before the byte_extract (resulting in the wrong value -- 0 -- being used in the byte_test comparison).</p>
<p>Here is a sample rule that can be used with the atached pcap:</p>
<p><code>alert http any any -> any any (msg:"byte_extract Test"; flow:established,to_client; content:"Content|2D|Length|3A 20|"; http_raw_header; content:!"|0D 0A|"; within:3; http_raw_header; byte_extract:2,0,content-length,relative,string,dec; content:"|0D 0A|"; distance:0; within:2; http_raw_header; file_data; content:"test"; byte_test:2,=,content-length,0,relative,little; priority:3; sid:44412999;)</code></p>
<p>If you trace the code when you run the pcap against the rule, you can see that the byte(s) in byte_test are extracted successfully (in the pcap the extracted value is (decimal) 11) but the comparison compares it with the number 0 instead of the extracted value (because the extraction hasn't happened yet). If you change the operator in the byte_test from '=' to '>', this will pass (since 11 > 0) and then you can see that the byte_extract happens after that (and the byte_extract accurately extracts the value from the http_raw_header as (decimal) 11), but by then it is too late.</p>
<p>Tested in Suricata 2.07.</p> Suricata - Bug #1399 (Assigned): Flowbits rules not always evaluated in necessary orderhttps://redmine.openinfosecfoundation.org/issues/13992015-02-26T09:31:26ZDavid Wharton
<p>Flowbits is a powerful and useful feature of Suricata and multiple flowbits rules can be applied to the same packet/stream. Unfortunately, there appears to be situations where flowbits rules are processed in an order that prevents them from alerting as expected.</p>
<p>Obviously, rules that set flowbits ("flowbit settters") have to be processed before rules that check flowbits ("flowbit checkers"). However, flowbits rules can both set and check flowbits and flowbits "chains" can exist and these rules must be evauated in a certain order based on the flowbits dependencies. Such dependencies do not appear to be respected in all cases by the Suricata engine when processing rules.</p>
<p>From what I can tell, when it comes to flowbits rules, rules that are only flowbit setters get processed first and rules that are only flowbit checkers get processed last. This makes sense and is appropriate. However, rules that both check and set flowbits seem to be proccessed in order based off of SID and this can create dependency issues for flowbits chains. (Note: this is based off my testing on version 2.0.6; older versions of Suricata like version 1.3.4 appear to base the processing order off of the order that the rules appear in the rules file.)</p>
<p>For example, consider the attached pcap. If it is run against the following ruleset that contains a simple flowbits chain, SIDs 1, 2, and 3 fire as expected:</p>
<pre>
alert tcp any any -> any any (msg:"First in chain"; content:"GET"; flowbits:set,1; sid:1;)
alert tcp any any -> any any (msg:"Second in chain"; content:"flow"; flowbits:isset,1; flowbits:set,2; sid:2;)
alert tcp any any -> any any (msg:"Third (Last) in chain"; content:"boss"; flowbits:isset,2; flowbits:set,3; sid:3;)
</pre>
<p>However, if you change the SIDs in the chain like this, then only SIDs 2 and 3 fire:</p>
<pre>
alert tcp any any -> any any (msg:"First in chain"; content:"GET"; flowbits:set,1; sid:3;)
alert tcp any any -> any any (msg:"Second in chain"; content:"flow"; flowbits:isset,1; flowbits:set,2; sid:2;)
alert tcp any any -> any any (msg:"Third (Last) in chain"; content:"boss"; flowbits:isset,2; flowbits:set,3; sid:1;)
</pre>
<p>The solution is, when there is a chain of flowbits, the rules need to be processed appropriately so that all necessary setters are processed before all dependent checkers. This may seem like a non-trivial task since complex dependent chains can be exist because rules can set and check more than one flowbit. Fortunately, there is a simple solution (at least in theory).</p>
<p>Flowbits rules can be represented as a directed acyclic graph (DAG) so the solution is nothing more than doing a topologial sort of them in order to determine appropriate processing order. (<a class="external" href="http://en.wikipedia.org/wiki/Topological_sorting">http://en.wikipedia.org/wiki/Topological_sorting</a>)</p>
<p>If you view each rule as a node, and a directed edge exists from node A to node B if node A sets a flowbit checked by node B, then we end up with a DAG (unless there are loops in which case the graph wouldn't be acyclic and there would be a logical error in the ruleset preventing rules from alerting as expected; flowbits rules should always be able to be represented as a DAG).</p>
<p>In addition to determining rule processing order for flowbits rules, creating a graph of the rules provides other benefits:</p>
<p>1) Flowbits cycles (loops) can be detected and an error message can be thrown.<br />2) Rules that set flowbits that are never checked can be trivially identified and warning messages can be thrown.</p> Suricata - Bug #1382 (Feedback): BPF not reflected in suricata.log when using pf-ringhttps://redmine.openinfosecfoundation.org/issues/13822015-02-09T17:03:22ZPeter Manevpetermanev@gmail.com
<p>Latest git 2.1dev (rev 1010406) - when using a bpf filter from a file with af-packet - this is reflected in the suricata.log.<br /><pre>
....
(runmode-af-packet.c:148) <Info> (ParseAFPConfig) -- Going to use command-line provided bpf filter '( (ip and port 20 or 21..........
....
</pre></p>
<p>The same is not true when using BPF with pf-ring.</p> Suricata - Bug #1370 (New): sctp fp on suricata enginehttps://redmine.openinfosecfoundation.org/issues/13702015-01-28T15:31:57Zrmkml rmkmlrmkml@yahoo.fr
<p>Hello,</p>
<p>I'm continue Suricata testing and 1) found a fp with this (simplified) sig on joigned sctp pcap file:</p>
<p>alert ip any any -> any any (msg:"SCTP Suricata test 1"; ip_proto:132; content:"|00 07 02 10|"; offset:0; depth:4; classtype:attempted-admin; sid:1; rev:1; )</p>
<p>-> Suricata v2.0.6 fire or v2.1beta2 fire but NOT snort2.</p>
<p>02/18/2005-09:49:58.694007 [**] [1:1:1] SCTP Suricata test 1 [**] [Classification: Attempted Administrator Privilege Gain] [Priority: 1] {SCTP} 192.168.170.56:7 -> 192.168.170.8:7</p>
<p>tcpdump dump with joigned sctp pcap file:</p>
<p>09:49:58.694007 IP (tos 0x0, ttl 128, id 45300, offset 0, flags [none], proto SCTP (132), length560)<br /> 192.168.170.56.7 > 192.168.170.8.7: sctp<br /> 1) [DATA] (U)(B)(E) [TSN: 13852] [SID: 8] [SSEQ 0] [PPID 0x0] [Payload]<br /> 0x0000: 4500 0230 b0f4 0000 8084 b1c3 c0a8 aa38 E..0...........8<br /> 0x0010: c0a8 aa08 0007 0007 4323 2544 3ade fb02 ........C#%D:...<br /> 0x0020: 0007 0210 0000 361c 0008 0000 0000 0000 ......6.........<br /> ---------<br /> ...</p>
<p>2) or suricata fp (but not snort2) with this similar sig without ip_proto:132 :</p>
<p>alert ip any any -> any any (msg:"SCTP Suricata test 2"; content:"|00 07 02 10|"; offset:0; depth:4; classtype:attempted-admin; sid:2; rev:1; )</p>
<p>02/18/2005-09:49:58.694007 [**] [1:2:1] SCTP Suricata test 3 [**] [Classification: Attempted Administrator Privilege Gain] [Priority: 1] {SCTP} 192.168.170.56:7 -> 192.168.170.8:7</p>
<p>3) for information, post a true sig sctp fire:</p>
<p>alert sctp any any -> any any (msg:"SCTP Suricata test 3"; content:"|00 07 02 10|"; offset:0; depth:4; classtype:attempted-admin; sid:3; rev:1; )</p>
<p>Please check.</p>
<p>Regards<br /><a class="user active user-mention" href="https://redmine.openinfosecfoundation.org/users/27">@rmkml rmkml</a></p> Suricata - Bug #1247 (New): Using suppress in threshold.config does not prevent droppinghttps://redmine.openinfosecfoundation.org/issues/12472014-07-28T09:40:25ZAndreas Herzoisf@herzandreas.de
<p>I have suricata 2.0.2 running in inline/ips mode, with the following rule active:<br /><pre>
drop ip any any -> any any (msg:"GPL ATTACK_RESPONSE id check returned root"; content:"uid=0|28|root|29|"; fast_pattern:only; classtype:bad-unknown; sid:2100498; rev:8;)
</pre></p>
<p>So i have create a index.html for testing:<br /><pre>
uid=0(root) gid=0(root) groups=0(root)
</pre><br />With small python server<br /><pre>
python -m SimpleHTTPServer
</pre><br />I can trigger the rule by:<br /><pre>
lynx http://10.0.20.89:8000/
</pre></p>
<p>The rule triggers, logs into fast.log etc. and also drops the attempt.<br />I put "suppress gen_id 1, sig_id 2100498" into the threshold.config and did restart suricata.<br />What i would have expected is that i see no logs and it won't be dropped.<br />The logs don't appear (i have fast.log, alert-debug.log, drop.log and http.log active) but it's dropped.<br />The same test in snort with the same suppress rule does not log and not drop.</p>
<p>I guess this might be a bug introduced in some newer version, since Victor Julien got the same issue working in 2012:</p>
<p><a class="external" href="http://blog.inliniac.net/2012/03/07/f-secure-av-updates-and-suricata-ips/">http://blog.inliniac.net/2012/03/07/f-secure-av-updates-and-suricata-ips/</a></p>
<p>And i would suggest the option to also use threshold.config within the dynamic rule reload, so it's not necessary to restart the whole suricata if you just added one line into the threshold.config.</p> Suricata - Bug #1152 (Feedback): Write to ipfw divert socket failed: Message too longhttps://redmine.openinfosecfoundation.org/issues/11522014-03-23T07:14:46ZEvgeny Kovalchukkovalchuk@flynet.pro
<p>8.4-RELEASE + Suricata 2.0dev (rev 9e03550) + IPFW divert</p>
<p>After some hours of work in log write<br />[100152] 23/3/2014 -- 18:42:32 <Warning> [ERRCODE: SC_WARN_IPFW_XMIT(84)] - Write to ipfw divert socket failed: Message too long</p>
<p>And suricata exit.</p>
<p>How fix it? <br />What additional info needed?</p> Suricata - Bug #1084 (Assigned): pfring: valgrind: memory leak at exit in bpf filterhttps://redmine.openinfosecfoundation.org/issues/10842014-01-20T07:04:35ZVictor Julienvictor@inliniac.net
<pre>==19592== 528 bytes in 3 blocks are definitely lost in loss record 526 of 569
==19592== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19592== by 0x5487D83: ??? (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.1.1)
==19592== by 0x547C8D9: pcap_compile (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.1.1)
==19592== by 0x547D16F: pcap_compile_nopcap (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.1.1)
==19592== by 0x56B2A2C: pfring_mod_set_bpf_filter (in /usr/local/pfring/lib/libpfring.so)
==19592== by 0x59E6C0: ReceivePfringThreadInit (source-pfring.c:478)
==19592== by 0x5C9477: TmThreadsSlotPktAcqLoop (tm-threads.c:669)
==19592== by 0x5AECE99: start_thread (pthread_create.c:308)
==19592== by 0x679B3FC: clone (clone.S:112)</pre>
<p>I think this may be a pfring issue as we do have a call to pfring_remove_bpf_filter()</p> Suricata - Bug #1083 (Assigned): pfring: valgrind: Syscall param socketcall.setsockopt(optval) po...https://redmine.openinfosecfoundation.org/issues/10832014-01-20T07:03:13ZVictor Julienvictor@inliniac.net
<pre>==19592== 3 errors in context 1 of 3:
==19592== Thread 3:
==19592== Syscall param socketcall.setsockopt(optval) points to uninitialised byte(s)
==19592== at 0x679C63A: setsockopt (syscall-template.S:82)
==19592== by 0x56B2A6D: pfring_mod_set_bpf_filter (in /usr/local/pfring/lib/libpfring.so)
==19592== by 0x59E6C0: ReceivePfringThreadInit (source-pfring.c:478)
==19592== by 0x5C9477: TmThreadsSlotPktAcqLoop (tm-threads.c:669)
==19592== by 0x5AECE99: start_thread (pthread_create.c:308)
==19592== by 0x679B3FC: clone (clone.S:112)
==19592== Address 0x14427c72 is on thread 3's stack</pre> Suricata - Bug #868 (New): Makefile[.in] doesn't use its own INSTALL variable definitionhttps://redmine.openinfosecfoundation.org/issues/8682013-07-09T05:19:02ZMark Solarismark@ibiblio.org
<p>When doing a 'gmake install' the generated Makefile is using whatever 'install' is in your path, on Solaris that can invoke /etc/install which gives pretty weird results.</p>
<p>This alters the 'install' commands in Makefile.in to be ${INSTALL} instead which is defined earlier in the file.</p>
<pre>
--- suricata-1.4.3/Makefile.in.orig Tue Jul 9 13:52:14 2013
+++ suricata-1.4.3/Makefile.in Tue Jul 9 13:52:52 2013
@@ -810,22 +810,22 @@
install-full: install install-conf install-rules
install-conf:
- install -d "$(e_sysconfdir)"
- @test -e "$(e_sysconfdir)/suricata.yaml" || install -m 600 "$(top_srcdir)/suricata.yaml" "$(e_sysconfdir)"
- @test -e "$(e_sysconfdir)/classification.config" || install -m 600 "$(top_srcdir)/classification.config" "$(e_sysconfdir)"
- @test -e "$(e_sysconfdir)/reference.config" || install -m 600 "$(top_srcdir)/reference.config" "$(e_sysconfdir)"
- @test -e "$(e_sysconfdir)/threshold.config" || install -m 600 "$(top_srcdir)/threshold.config" "$(e_sysconfdir)"
- install -d "$(e_logfilesdir)"
- install -d "$(e_rundir)"
- install -m 770 -d "$(e_localstatedir)"
+ ${INSTALL} -d "$(e_sysconfdir)"
+ @test -e "$(e_sysconfdir)/suricata.yaml" || ${INSTALL} -m 600 "$(top_srcdir)/suricata.yaml" "$(e_sysconfdir)"
+ @test -e "$(e_sysconfdir)/classification.config" || ${INSTALL} -m 600 "$(top_srcdir)/classification.config" "$(e_sysconfdir)"
+ @test -e "$(e_sysconfdir)/reference.config" || ${INSTALL} -m 600 "$(top_srcdir)/reference.config" "$(e_sysconfdir)"
+ @test -e "$(e_sysconfdir)/threshold.config" || ${INSTALL} -m 600 "$(top_srcdir)/threshold.config" "$(e_sysconfdir)"
+ ${INSTALL} -d "$(e_logfilesdir)"
+ ${INSTALL} -d "$(e_rundir)"
+ ${INSTALL} -m 770 -d "$(e_localstatedir)"
install-rules:
- install -d "$(e_sysconfrulesdir)"
+ ${INSTALL} -d "$(e_sysconfrulesdir)"
wget -qO - http://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz | tar -x -z -C "$(e_sysconfdir)" -f -
- @test -e "$(e_sysconfrulesdir)decoder-events.rules" || install -m 600 "$(top_srcdir)/rules/decoder-events.rules" "$(e_sysconfrulesdir)"
- @test -e "$(e_sysconfrulesdir)stream-events.rules" || install -m 600 "$(top_srcdir)/rules/stream-events.rules" "$(e_sysconfrulesdir)"
- @test -e "$(e_sysconfrulesdir)smtp-events.rules" || install -m 600 "$(top_srcdir)/rules/smtp-events.rules" "$(e_sysconfrulesdir)"
- @test -e "$(e_sysconfrulesdir)http-events.rules" || install -m 600 "$(top_srcdir)/rules/http-events.rules" "$(e_sysconfrulesdir)"
+ @test -e "$(e_sysconfrulesdir)decoder-events.rules" || ${INSTALL} -m 600 "$(top_srcdir)/rules/decoder-events.rules" "$(e_sysconfrulesdir)"
+ @test -e "$(e_sysconfrulesdir)stream-events.rules" || ${INSTALL} -m 600 "$(top_srcdir)/rules/stream-events.rules" "$(e_sysconfrulesdir)"
+ @test -e "$(e_sysconfrulesdir)smtp-events.rules" || ${INSTALL} -m 600 "$(top_srcdir)/rules/smtp-events.rules" "$(e_sysconfrulesdir)"
+ @test -e "$(e_sysconfrulesdir)http-events.rules" || ${INSTALL} -m 600 "$(top_srcdir)/rules/http-events.rules" "$(e_sysconfrulesdir)"
@echo ""
@echo "You can now start suricata by running as root something like '$(bindir)/suricata -c $(e_sysconfdir)/suricata.yaml -i eth0'."
@echo ""
</pre> Suricata - Bug #778 (New): ipv6 addr with nat64 notationhttps://redmine.openinfosecfoundation.org/issues/7782013-03-13T09:03:13ZVictor Julienvictor@inliniac.net
<p>Seems we don't parse these correctly.</p> Suricata - Bug #669 (Assigned): windows msi: upgradehttps://redmine.openinfosecfoundation.org/issues/6692012-12-10T03:23:16ZVictor Julienvictor@inliniac.net
<p>Currently installing a new version over an old requires the old version to be manually removed.</p>
<p>Tested:<br />installed 1.3.3-2<br />then tried to install 1.3.5-1, got error saying something like "remove earlier versions of product first".</p> Suricata - Bug #635 (Assigned): Some keywords missing in list-keyword command (like 'tcp-pkt')https://redmine.openinfosecfoundation.org/issues/6352012-11-21T07:52:40ZEric Leblonderic@regit.org
<p>A keyword like 'tcp-pkt' does not appear in list-keyword output because it is only defined by a string match in detect-engine-proto.c</p>
<p>We should find a way to declare this keyword and have them displayed in list-keyword option.</p> Suricata - Bug #500 (New): duplicate values in host-os-policy not detectedhttps://redmine.openinfosecfoundation.org/issues/5002012-07-09T05:48:53ZVictor Julienvictor@inliniac.net
<p>Duplicate values like below are not handled properly.</p>
<pre>
host-os-policy:
# Make the default policy windows.
windows: ["1.2.3.4"]
bsd: ["1.2.3.4"]
bsd-right: []
old-linux: []
linux: ["1.2.3.4"]
old-solaris: []
solaris: ["1.2.3.4"]
hpux10: ["1.2.3.4"]
hpux11: ["1.2.3.4"]
irix: ["1.2.3.4"]
macos: ["1.2.3.4"]
vista: ["1.2.3.4"]
windows2k3: ["1.2.3.4"]
</pre>
<p>Please make sure we error out on this condition.</p>
<p>Please also add unittests.</p>