[Snort-devel] Yet more data corruption in stream4/snort-2.0.5

Andrew Rucker Jones arjones at ...2237...
Wed Dec 3 13:47:04 EST 2003

Hash: SHA1


| Thanks for taking the time to look at this.  We've spoken (the dev team)
| about supporting window scaling and other options such as selective
| acknowledgment but our position has been that they're sufficiently
| complex to require a lot of thought before we took a stab at how to
| properly deal with them.

| That is clearly one problem.  One of the most significant problems with
| supporting window scaling in the first place is that it provides an
| attacker many opportunities for insertion and other types of attacks.
| It makes knowing when to flush more difficult and it may make memory
| management more difficult as we have to hang on to more of the stream
| before flushing it.

I would love to have sat in on THAT discussion! I understand some of
Your concerns, and i'm not interested in convincing You to do things
another way. It's Your software, and You guys know more about this than
most other people, including myself. I would have to say, though, that
data corruption is a big deal to me. In the end, i use snort to detect
attacks. If data are being corrupted, i may be missing attacks, and i
may be getting alerts on packets that never existed, but which require
my time to process. In both of those cases, snort is not meeting my
needs, and what i thought were its design goals. As far as i'm
concerned, use more memory, flush less often, do whatever, but give me
accurate information! Or at least give me the option to turn on
"experimental" support for window scaling and so on.
	That, however, is only my opinion. I will patch all of my installations
of snort to deal with this deficiency, and anyone else who wants to do
the same can use the patch i provided. That satisfies me.

|> 2) Has anyone ever seen a case where one side of a connection
|> acknowledges data that have not yet been sent? I swear that i have a
|> real world capture (an e-mail to a Yahoo! address) in which the client
|> sends data up to sequence number X, after which the server sends two
|> ACKs right after each other: one for X, and one for X+1024 or so. Right
|> after that, the client sends the next 1024 bytes. There are no
|> retransmits involved. Of course, that causes data corruption, too, but
|> snort can hardly be blamed for that. That entire conversation was just
|> as weird as can be, i have to say.
| This might be the result of an "optimization" algorithm, ACKs arriving
| out of sequence or any number of other issues.
| Do you have a capture we could look at?

Well, yes and no. I would have to cleanse it first, and i really don't
think it's worth it. Snort shouldn't be required to understand TCP
implementations that are THAT bad.
	How about the other data corruption bug i reported a few days ago? Have
You guys had a chance to look at that?


- --
GPG key / Schlüssel -- http://simultan.dyndns.org/~arjones/gpgkey.txt
Encrypt everything. / Alles verschlüsseln.

Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the Snort-devel mailing list