We are just about ready to release Bro version 1.4. Prior to doing so,
wed like to have some folks volunteer to try out a pre-release to catch
any lingering problems. If you're interested in doing so, reply privately
to me *and Robin Sommer (cc'd)* and we'll point you at the distribution.
Vern
(Note, I'm out of the office for several weeks, with limited email access,
which is why you should be sure to include Robin.)
Hi,
I'm a little confused about the license under which is Bro distributed.
Is it "BSD" or "BSD with advertising"? It looks like that in the
COPYING file is "BSD with advertising" and on
http://bro-ids.org/license.html "BSD". Could you please tell me
which one is the right one?
Thanks,
Dan
Hi Stepan,
On Fri, 2008-08-29 at 12:37 +0200, Stepan Kasal wrote:
> Hello Christian and Vern,
>
> > Thanks -- the patch seems to do a little more than just rename a
> > colliding variable (which I presume was "simplified").
>
> Actually, it's not the case. I have bundled two changes into the
> patch, without proper explanation; I'm sorry for that.
>
> The problem was that configure built with Autoconf 2.62 died
> conpaining that unknown option "option-checking" was used.
>
> The problem is that with Autoconf 2.62, shell variable
> enable_option_checking is set near the top of the script, no matter
> whether --enable-option-checking was given or not.
>
> When your macro AC_LBL_ENABLE_CHECK finds this variable in the
> environment, it bails out compaining about unknown option named
> "option_checking". That makes the configuire script unusable.
Ah! That rings a bell, but I can't seem to remember the circumstances
under which this was pointed out to us in the past. I'm sure though that
it was, and in fact we were considering ditching the (dated)
AC_LBL_ENABLE_CHECK in favor of the new built-in option checking once
2.62 is in widespread use.
> The issue can be fixed by this change:
>
> --- bro-20080804/acinclude.m4.orig 2006-04-23 07:55:10.000000000 +0200
> +++ bro-20080804/acinclude.m4 2008-08-26 16:19:45.000000000 +0200
> @@ -192,7 +192,7 @@
> ok=0
> dnl change '-' to '_'
> simplified=`echo $1| sed -e 's/-/_/g'`
> - for o in $simplified; do
> + for o in option_checking $simplified; do
> if test "${o}" = "${var}" ; then
> ok=1
> break
>
> This way, the built in enable_option_checking option is added to the
> list of options supplied as a parameter to AC_LBL_ENABLE_CHECK.
Understood, and agreed with.
> > I like the use of
> > m4_translit, assuming it is provided by a wide range of m4 versions.
>
> That was the other change; I thought the substitution should rather
> be done when configure is created, not during its run. And yes,
> m4_translit is available for very long time, no problem.
Okay, likewise agreed with then.
> Yes, Autoconf 2.62 introduces option checking (for both --enable-* and
> --with-* options). Unfortunately, this feature is not generally
> compatible with recursive configure calls, at least in its present
> form, so it's switched on by default as soon as AC_CONFIG_SUBDIRS is
> used. You could run configure with --enable-option-checking, but you
> would get many false warnings from the sub configures.
Got it.
> Let me remind: AC_CONFIG_SUBDIRS is not primarily meant to define a
> structure within a huge project, it is meant for incorporating
> tarballs, which are not under your control. The tarballs are
> generally supposed to have different maintainers, the configure
> scripts might be generated by different version of Autoconf, etc.
We're aware of that. We needed a way to combine individual subtrees into
a single tree so that the overall tree would "just build", while
preserving the ability to produce tarballs of the subtrees when needed.
> You might file a feature request to enhance the
> --enable-option-checking so that it supports sub-configures, to
> bug-autoconf(a)gnu.org.
>
> Or, if the sub-projects are maintained more or less together with the
> main project, you might integrate them so that they use a tree of
> Makefiles, but one common configure script. I would be glad to help
> you investigate this possibility, but for general good, we should
> move to autoconf(a)gnu.org with that.
Regarding this, see my point above -- we primarily want a tree that
builds from scratch, but can provide subtree tarballs when needed.
Advice on how to do this, assuming our current approach is horribly
wrong, would be appreciated, but the real problem for us is lack of time
for a much-needed overhaul of our build scripts.
> Hope this mail helps. I hope I managed to keep the offense rate low.
> ;-)
I'll be the last person to claim that our autotools setup is in good
shape at this point, so don't worry about offenses. :^)
--
Cheers,
Christian
Hi,
I encountered a problem with Autoconf during packaging Bro (svn rev.
6043) for Fedora 10 and after consulting it with Stepan Kasal he
created the attached patch that fixes this problem. It was caused by a
collision with the internal variable in Autoconf 2.62.
Dan
Hello,
I ran into a problem while building the Broccoli part of the Bro
development version (1.3.2) on NetBSD 4.0. On NetBSD, <sys/sem.h> does
not define the union semun. The attached patch fixes this build problem
for me.
Best regards,
Christoph Leuzinger
Hello and Greetings !
I have a question on overlaps - TCP segment overlaps and IP fragments
overlap - how common they are
and how legitimate?
AFAIK, TCP segmentation overlaps can be seen in normal traffic and by
themselves cannot be deemed
malicious.
Is IP fragmentation overlap abnormal always? What is a scenario when
this can happen in a normal scenario?
Thanks in advance for the reply !
Hello again,
Half a day more of GDB have unearthed the root cause of this problem. I
am posting this, since this is behavior that potential developers of Bro
analyzers will want to know about. Or possibly, it is a bug.
In my binpac grammar, at one point I need to decide which rule to take
based on the state of both upflow and downflow. The first payload packet
(handshake) comes from upflow and, while processing, I check if a bit is
set. The second packet processed is the handshake from downflow where
the bit is also checked. For any subseqent packets/messages a different
rule is taken depending on if both bits are set or not.
However, Bro does something (at least for me) unexpected. After
processing the upflow handshake, it starts processing the next message
in this flow, although the data is not there yet. Since the downflow
message has not been processed yet the flag is not set, and Bro decides
(somehow correctly) that the next message is going to be of the standard
type. It creates a message object, and sets the FlowBuffer frame size to
4, since this is how long the next message is at least supposed to be.
Then it stops processing since the data isn't actually there, and starts
working on the downflow.
When the processing comes back to the upflow, the downflow handshake has
been parsed and the flag set. Therefore, Bro does not reuse the message
object, but creates a new one for the other type of message. However,
the state in FlowBuffer (namely the frame size) is not reset, and the
first step in parsing the new message is to skip the 4 bytes from the
(actually nonexistent) previous message which effectively swallows the
first 4 bytes of the current message - and that causes the parsing to
use the wrong fields and in the end causes an out_of_bounds exception
that stops the processing.
I my grammar, I did not expect processing of messages before they arrive
and it should work perfectly fine when the messages are processed in the
same order they appear in the dump file. I'm curious if the observed
behavior is some sort of optimization that you just need to consider
when writing binpac grammars (and even more wondering if for some cases
it's possible to write the grammar in the required way) or if protocols
where both sides contribute to the state have not been considered when
designing binpac. I have noticed that the Bro wiki mentions the
$context.flow macro but not the $context.connection macro which is also
there. For now, I am rewriting my grammar in the hope that I can
circumvent my problem, but I would welcome any comments or
clarifications from the authors or savvy developers on that issue.
greetz Martin
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
hi robin,
I just notice the new version of tm is out, the download link is correct but
the name to click for download is wrong
20060814
I think it should be 20080814?
Cheers ;]
--
Best Regards,
CS Lee<geek00L[at]gmail.com>
http://geek00l.blogspot.com
(Below a reply I sent earlier in private mail. Miguel, please don't
send a question separately both in private mail and on the list,
thanks.)
Robin
----- Forwarded message from Robin Sommer <robin(a)icir.org> -----
From: Robin Sommer <robin(a)icir.org>
Date: Tue, 12 Aug 2008 10:09:25 -0700
Subject: Re: [Bro] Bro 1.4, another pre-release
To: Miguel Angel Calvo Moya <mangel12321(a)hotmail.com>
Message-ID: <20080812170925.GC5416(a)icir.org>
On Tue, Aug 12, 2008 at 18:03 +0200, you wrote:
> line 1: warning: event handlers never invoked:
> line 1: warning: Drop::restore_dropped_address
This is actually expected and harmless. It says that Bro sees an
handler for an event yet based on the scripts you load can tell that
the event will never actually be raised. In this case, that's
because your configuration never calls the function
Drop::drop_address (which is a rare thing to do anyway).
There's a switch to suppress these warnings:
# If true, warns about unused event handlers at startup.
const check_for_unused_event_handlers = T &redef;
I've already been wondering whether we should change this to off by
default.
> Also I noticed there is no longer a 'site' folder. Where would be
> the right place to place our host-specific Bro policy file?
Hmmm... Good question, didn't think about that when redoing the
default installation. How about $prefix/share/bro/site? Looks like
"make install" should then create that directory if it doesn't
exist.
Robin
--
Robin Sommer * Phone +1 (510) 666-2886 * robin(a)icir.org
ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org
----- End forwarded message -----
--
Robin Sommer * Phone +1 (510) 666-2886 * robin(a)icir.org
ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org
