<div dir="ltr">Hi Martin,<br><br>Can you post your binpac script?<br><br>Thanks,<br>Ruoming<br><br><div class="gmail_quote">On Wed, Aug 20, 2008 at 11:02 AM, Martin Szydlowski <span dir="ltr"><<a href="mailto:msz@seclab.tuwien.ac.at">msz@seclab.tuwien.ac.at</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hello again,<br>
<br>
Half a day more of GDB have unearthed the root cause of this problem. I<br>
am posting this, since this is behavior that potential developers of Bro<br>
analyzers will want to know about. Or possibly, it is a bug.<br>
<br>
In my binpac grammar, at one point I need to decide which rule to take<br>
based on the state of both upflow and downflow. The first payload packet<br>
(handshake) comes from upflow and, while processing, I check if a bit is<br>
set. The second packet processed is the handshake from downflow where<br>
the bit is also checked. For any subseqent packets/messages a different<br>
rule is taken depending on if both bits are set or not.<br>
<br>
However, Bro does something (at least for me) unexpected. After<br>
processing the upflow handshake, it starts processing the next message<br>
in this flow, although the data is not there yet. Since the downflow<br>
message has not been processed yet the flag is not set, and Bro decides<br>
(somehow correctly) that the next message is going to be of the standard<br>
type. It creates a message object, and sets the FlowBuffer frame size to<br>
4, since this is how long the next message is at least supposed to be.<br>
Then it stops processing since the data isn't actually there, and starts<br>
working on the downflow.<br>
<br>
When the processing comes back to the upflow, the downflow handshake has<br>
been parsed and the flag set. Therefore, Bro does not reuse the message<br>
object, but creates a new one for the other type of message. However,<br>
the state in FlowBuffer (namely the frame size) is not reset, and the<br>
first step in parsing the new message is to skip the 4 bytes from the<br>
(actually nonexistent) previous message which effectively swallows the<br>
first 4 bytes of the current message - and that causes the parsing to<br>
use the wrong fields and in the end causes an out_of_bounds exception<br>
that stops the processing.<br>
<br>
I my grammar, I did not expect processing of messages before they arrive<br>
and it should work perfectly fine when the messages are processed in the<br>
same order they appear in the dump file. I'm curious if the observed<br>
behavior is some sort of optimization that you just need to consider<br>
when writing binpac grammars (and even more wondering if for some cases<br>
it's possible to write the grammar in the required way) or if protocols<br>
where both sides contribute to the state have not been considered when<br>
designing binpac. I have noticed that the Bro wiki mentions the<br>
$context.flow macro but not the $context.connection macro which is also<br>
there. For now, I am rewriting my grammar in the hope that I can<br>
circumvent my problem, but I would welcome any comments or<br>
clarifications from the authors or savvy developers on that issue.<br>
<div class="Ih2E3d"><br>
greetz Martin<br>
_______________________________________________<br>
Bro mailing list<br>
<a href="mailto:bro@bro-ids.org">bro@bro-ids.org</a><br>
</div><div><div></div><div class="Wj3C7c"><a href="http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro" target="_blank">http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro</a><br>
</div></div></blockquote></div><br></div>