[Bro] weird behavior in binpac-generated analyzer

[Ruoming Pang]

Hi Martin,

I can help you look at the issue. The first thing to do is to extract the
exact connection that causes the problem and use tcpdump to extract a dump
that only contains the connection. I assume that there's no cross-connection
state that could affect the analysis.

Ruoming

2008/8/19 Martin Szydlowski <msz at seclab.tuwien.ac.at>

> Hi all,
>
> I am extending the BitTorrent analyzer (kudos to Nadi Sarrar) that has
> finally made it into the 1.4.prerelease to handle messages beyond the
> standard protocol. In particular, I am including the Azureus Messaging
> protocol and there's where the trouble begins. When "switching" from
> standard to azureus protocol, the analyzer consistently swallows the
> first 4 bytes in the upflow direction. The downflow is unaffected and
> the analysis works fine there and it does not matter if the first
> message after the switch was upflow or downflow, it is always the first
> upflow message that is affected.
>
> The effect of the swallow is that the analyzer misses the 4-byte length
> field and takes the first four bytes of the following string instead.
> That produces a huge number that causes an out_of_bound exception and
> stops the anaylsis for the upflow.
>
> I did some debugging with gdb and found that FlowBuffer::NewMessage
> in aux/binpac/lib/binpac_buffer.cc increases the orig_data_begin_
> pointer by 4 when it is actually pointing at the correct spot. Either
> the increment is wrong, or the data pointer is 4 bytes to far already, I
> cannot tell.
>
> I have only made changes to ,pac (and .bro) files, therefore all the
> code is binpac-generated. As long as the network dumps do not contain
> azureus traffic, my code does not get invoked, and the analysis runs
> fine, therefore the fault must lie in my changes. However, since the
> code for upflow and downflow is obviously identical and only upflow is
> affected by this error, maybe my code triggers some obscure bug in
> binpac or bro. Oh and BTW, I also tried disabling the connection
> compressor, since in the past that caused trouble with localhost
> connections (but that bug should be fixed by now).
>
> I am attaching a diff of my changes (against SVN revision 6054).
> The dumps I have been testing against can be found at
> http://hades.seclab.tuwien.ac.at/msz/azu.dump and
> http://hades.seclab.tuwien.ac.at/msz/azu2.dump (both ~30MB).
> When using this dumps, you must use the -C flag since the tcp checksums
> are invalid (as always when capturing traffic on the originating host).
> (My invocation of bro is: $ bro -C -r xxx.dump bittorrent bt-tracker weird)
>
> I hope someone can look at this and tell me what is going wrong.
>
> greetz Martin
>
>
>
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20080820/3a6c4704/attachment.html