Skip to content
This repository has been archived by the owner on Jan 18, 2024. It is now read-only.

odlaw.pl tool error #15

Closed
aval13 opened this issue Jan 9, 2012 · 1 comment
Closed

odlaw.pl tool error #15

aval13 opened this issue Jan 9, 2012 · 1 comment

Comments

@aval13
Copy link

aval13 commented Jan 9, 2012

Hello.

I just ran into a weird behaviour of the odlaw.pl tool from barnyard2/tools.

Since this morning (at least), all our servers that report snort/barnyard2 status based on a shell script which uses odlaw.pl started complaining that b2 was following a non-existant file. After checking the reason, on all servers, when running odlaw.pl -r <b2_waldo_file>, Perl would complain like this:

# ./odlaw.pl -r /var/log/snort/barnyard2.waldo 
waldo: /var/log/snort/barnyard2.waldo
{
 directory = /var/log/snort
 filebase = snort.log
Use of uninitialized value in concatenation (.) or string at ./odlaw.pl line 101.
 timestamp = 
Use of uninitialized value in concatenation (.) or string at ./odlaw.pl line 102.
 record = 
}
[!] Read waldo data is incomplete or corrupted.

After some digging, i found out the reason was the fact that the timestamp logged in the waldo file (1326104643) in hex contains 0x0A, which perl when reading the waldo file with treated as newline and did not feed all the file data in the unpack function. As such, the unpack function got less then expected and returned bad data (undef) for timestamp and record fields.

Hexdump on the waldo file showed the following:

# hexdump barnyard2.waldo 
0000000 762f 7261 6c2f 676f 732f 6f6e 7472 0000
0000010 0000 0000 0000 0000 0000 0000 0000 0000
*
0000400 6e73 726f 2e74 6f6c 0067 0000 0000 0000
0000410 0000 0000 0000 0000 0000 0000 0000 0000
*
0000800 c043 4f0a 0014 0000                    
0000808

The quick and dirty solution was to unset the native system's line terminator by inserting this line at line 70:
local $/ = undef;

This way without any line terminator character defined, Perl "slurped" all the file and fed it into the unpack function and odlaw.pl worked again.

Since this condition only rarely happens (but it's not impossible), i just wanted to let you guys know about it in case you might want to patch it.

The patch would be the following:

--- odlaw.pl    2011-11-17 19:48:44.000000000 +0200
+++ odlaw.pl   2012-01-09 13:30:50.000000000 +0200
@@ -67,7 +67,6 @@ sub waldo_read
     # read the data
     if ( open (FD, "<$file") )
     {
+        local $/ = undef;
         my $waldo_raw = <FD>;
         # unpack
         @values{@fields} = unpack("Z[".MAX_FILEPATH_BUF."] Z[".MAX_FILEPATH_BUF."] L L", $waldo_raw);

Thank you for your time.

@firnsy
Copy link
Owner

firnsy commented Jan 17, 2012

@aval13 - Thanks for chasing down your issue and providing the patch to correct. I'll commit this shortly and attribute appropriately.

Thanks again.

@firnsy firnsy closed this as completed Jan 17, 2012
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants