[Oisf-devel] FN on suricata 103/11beta2 - ftp format string

Victor Julien victor at inliniac.net
Mon Apr 18 10:48:01 UTC 2011

On 04/17/2011 01:38 AM, rmkml wrote:
> Thx you again for your time for checking my test.
> If you confirm, Im open a new ticket on suricata redmine.

Thanks rmkml, please open a ticket.

I have found that it is caused by different issues:

1. the pcap contains only a part of connection, it's missing the
shutdown. Suricata in IDS mode inspects ACK'd TCP data in the stream,
when the stream data reaches a minimum size or the stream is shut down.
In inline mode it's inspected in a sliding window manner, based on un
ACK'd data. In the case of your pcap, only "stream.inline" mode inspects
the stream correctly. Adding support for doing the reassembly for
streams that fully time out is on my todo list.

2. It seems we have an issue with how distance and within cooperate.
Suricata treats within as an absolute value from the offset of the last
match. Example: content:"abc"; content:"def"; within:3;

payload: abcdefghi
within      ---

But it also does this when distance is used. Example: content:"abc";
content:"def"; within:3; distance:1;

payload: abcdefghi
within&dis   --

It appears the signature expects within to be updated with the distance.
Example: content:"abc"; content:"efg"; within:3; distance:1;

payload: abcdefghi
within&dis   ---

Apparently this is what Snort does, although it's manual doesn't tell us so.

On a side note, I think the signature quality is quite poor. By using
the depth on TCP packet data, evasion becomes trivial. Unless you're
targeting a very specific exploit in which you know the the explicit
packet size and layout, you should always write signatures for the
stream. TCP data can come in any order, spliced, etc. Stream reassembly
will not help as it's very likely that the depth modifier will cause it
not to fire because the stream buffer normally will include the payloads
of packet 4 and 6.

I'll do some more testing on the distance/within combination and see if
I can get a fix into our code.


Victor Julien
PGP: http://www.inliniac.net/victorjulien.asc

More information about the Oisf-devel mailing list