For some scripting I'm doing, I'm running into the problem that
attributes associated with named types don't get propagated. For
example,
type a: table[count] of count &default = 5;
global c: a;
print c[9];
complains that c[9] isn't set, instead of returning the value 5.
Having dived[*] into this and examined some potential fixes, I've identified
that the problem is that (1) the attribute "&default = 5" in the above
example gets associated with the identifier 'a' rather than with a's type,
and (2) when the parser processes the second line, early in the process 'a'
gets converted to its underlying type, with the attributes lost at that
point since, internally, BroType's do not have attributes.
This is a pain to deal with. If we simply add attributes to BroType's and
for statements like the first line associate the attributes with the type,
then a sequence like:
type a: table[count] of count &default = 5;
type b: a &read_expire = 1 min;
will wind up changing the attributes associated with 'a' even though it
really shouldn't.
I think the right solution for this is to introduce a new BroType called
a NamedType. A NamedType has an identifier, an underlying BroType, and a
set of attributes. When a NamedType is constructed, for its attributes
it combines both the explicit attributes in its declaration (like the
&read_expire for 'b' above) and the implicit (i.e., it inherits/copies the
&default from 'a').
I plan to implement this soon, so please speak up if you have thoughts.
Vern
[*] The dive also exposed some other bugs in attribute processing, which
I'll enter into the tracker shortly.
I bumped into a limitation that was a little frustrating to work around with the config framework.
It is inconvenient that values stored in files read by adding to Config::config_files are not available within the bro_init event. After reviewing how the Config framework works, I understand why this is the case, but it means that if you want to use configuration values on startup, you're not guaranteed to be working with the anticipated value.
I think the introduction of an event that ensures that configuration files have been read by the time that the event fires might be worthwhile. I was wondering if anyone had any thoughts on how to resolve/work-around this issue.
known.dat:
Known::KnownServers 10.230.21.220,10.230.21.221
try-config.bro:
module Known;
redef Config::config_files += {"Known.dat"};
export {
option KnownServers: set[addr] = set();
}
event bro_init() {
print KnownServers;
}
event bro_done() {
print KnownServers;
}
======= output =======
bro -r stream-1.pcap ./try-config.bro
{
}
{
10.230.21.220,
10.230.21.221
}
Thanks,
Stephen
Attributes currently receive essentially no consistency checking.
For example, executing this script:
global a: count
&default = 10
&default = 9
&optional
&log
&add_func = function(d: double, t: time): count { return 3; };
print a;
simply results in:
error in /Users/vern/tmp/attr-type-check.bro, line 7: value used but not set (a)
I'm planning to add basic consistency checking, which will look for
(1) attributes that are repeated (which doesn't appear to be meaningful for
any of them) and (2) attributes that don't make sense in a given context,
like the ones listed above.
I'm thinking of implementing this as an internal table of meta-attributes,
i.e., each attribute type, like ATTR_OPTIONAL, will have its own attributes
like whether it requires a record context, only makes sense for aggregates,
etc. Here are the ones that come to mind, based on looking at the attributes
at https://www.bro.org/sphinx/script-reference/attributes.html with examples
in parens:
applies to global variable (&redef)
to global type (&redef)
to event handler (&priority)
to record field (&log)
to indexed type (&default)
to global indexed type (&add_func)
to type with expirable entries (&expire_func)
to a file (&rotate_interval)
Any feedback?
Vern
Good morning!
We have been seeing occasional core dumps from bro, currently running on 2.5-870. We've tried a few things to reproduce it on-demand but haven't been successful. We were wondering if you might have some insight into the crash. This is the backtrace we get:
#0 TableEntryVal::ExpireAccessTime (this=0x9b349bd32ebb5614) at /hostname/bro-devel-src/src/Val.h:741
#1 TableVal::DoExpire (this=0x3955a40, t=1539447574.1403711) at /hostname/bro-devel-src/src/Val.cc:2353
#2 0x00000000006a34cb in PQ_TimerMgr::DoAdvance (this=0x2e520c0, new_t=1539447574.1403711, max_expire=300) at /hostname/bro-devel-src/src/Timer.cc:166
#3 0x0000000000664d38 in expire_timers (src_ps=src_ps@entry=0x2eab8c0) at /hostname/bro-devel-src/src/Net.cc:232
#4 0x0000000000664de1 in net_packet_dispatch (t=1539447574.1403711, pkt=pkt@entry=0x2eab8f0, src_ps=src_ps@entry=0x2eab8c0) at /hostname/bro-devel-src/src/Net.cc:249
#5 0x0000000000925a89 in iosource::PktSrc::Process (this=0x2eab8c0) at /hostname/bro-devel-src/src/iosource/PktSrc.cc:263
#6 0x00000000006652c5 in net_run () at /hostname/bro-devel-src/src/Net.cc:315
#7 0x00000000005acab1 in main (argc=<optimized out>, argv=<optimized out>) at /hostname/bro-devel-src/src/main.cc:1227
Thank you for your help!
--Tim
________________________________
IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
It strikes me that as Bro development marches on, package maintainers don't
have great choices in terms of maintaining compatibility with multiple Bro
versions. For JA3, to maintain compatibility, you have to do something like
this, due to the SSL event change:
@if ( Version::at_least("2.6") )
> event ssl_client_hello(c: connection, version: count, record_version:count,
> possible_ts: time, client_random: string, session_id: string, ciphers:
> index_vec, comp_methods: vector of count) &priority=1
> @else
> event ssl_client_hello(c: connection, version: count, possible_ts: time,
> client_random: string, session_id: string, ciphers: index_vec) &priority=1
> @endif
>
That works, but I worry that the overhead of trying to maintain that will
grow out of hand. I'm wondering if there's a better mechanism for this. A
naive approach might be to include an option in the package metadata, which
specifies minimum/maximum Bro versions that it requires. The installer,
then, would simply install the latest version that supports your Bro
version.
I don't want to overcomplicate things, but it does feel like there's a
mechanism that's currently missing.
Any other thoughts?
--Vlad
During BroCon, someone brought a bug in the SSH analyzer to my attention.
The SSH Capabilities record has the following field, which is being set
incorrectly:
## Are these the capabilities of the server?
> is_server: bool;
>
> result->Assign(6, new Val(${msg.is_orig}, TYPE_BOOL));
>
Obviously, I'd like to fix this. I'm curious to hear thoughts about getting
this into 2.6. I know that the hassh package currently works around the
broken logic.
--Vlad
The FreeBSD security/bro port does not build under the latest FreeBSD
12.0 alpha due to compile errors in the X509 module. I verified that
this is due to openssl 1.1.1 by building on 11.2-RELEASE with the
openssl111 port. I've attached an example failing build log.
Is openssl 1.1.1 support on the roadmap?
Craig
Hello,
I would like to bring your attention to one strange and unexpected problem
I faced
while trying to include user agent parser for bro I have developed (plugin:
https://github.com/vitalyrepin/uap-bro ) into the list of uap
implementations https://github.com/ua-parser
The req
--
WBR & WBW, Vitaly
Not sure if this is a bug or I am using it wrong. Consider the following
snippet. I start it using `sudo ./bin/bro -i eth0 module_test`.
*File: share/bro/site/module_test/raise.bro*
```
module module_test;
# Remove the module to make the example work
# OR define the event handler within another module
export {
global my_event: event(a: int, s: string);
}
event raise_my_event() {
local a: int = 42;
local s: string = "Hello World";
print(fmt("Raising event with a=%d and s=%s", a, s));
event my_event(a, s);
}
#module module2;
event my_event(a: int, s: string) {
print(fmt("Received event with a=%d and s=%s", a, s));
}
event bro_init() {
local w: interval = 10sec;
print(fmt("Starting example, waiting for %s", w));
#"raise_my_event()" is executed immediately
schedule w {raise_my_event()};
}
```
# Problem 1: Event Handling within module
The handler for "my_event" is not invoked as long as it is defined
within the same module "module_test".
- Workaround a): Do not use modules at all
- Workaround b): Define the handler in a different module
But why should not it be allowed to raise and handle events within the
same module?
# Problem 2: Direct execution of scheduled events
At least within this example, I expected the "raise_my_event" to be
invoked after 10 seconds. However, it is done immediately. Am I using
the schedule wrong?
I am running the current master (0f550806252b46d3e13be24cd2ab4bb8a63bf49b).
Any help appreciated. Best,
Steffen.
--
M.Sc. Steffen Haas
Research Assistant
Phone: +49 40 42883 2353
IT-Sicherheit und Sicherheitsmanagement (ISS)
Universität Hamburg
Fachbereich Informatik
Vogt-Kölln-Straße 30
22527 Hamburg
Deutschland
