[Snort-users] Corrupt binaries in CVS (was: Snort 1.8.1 WIN32 MSSQL)
Chris Reid
John,
In short, what you're seeing is caused by a "feature" of CVS. It needs to
be told to handle binary files specially, to preserve the binary content so
they don't become corrupt. From what I understand, this is not currently
happening with the standard check-in/check-out commands. In your particular
case, the library files are altered either when they are checked into CVS,
or when they are checked out of CVS. I'm not sure which it is, and
unfortunately I haven't had time to investigate this problem any further
yet.
Can anybody else offer suggestions to fix this??? Changing standard CVS
commands listed on snort.org website, maybe??? I'm not a CVS expert, and
I'm very interested in hearing if there is an easy fix for this, since it
has been reported to the various Snort mailing lists several times now.
To get around this problem you need to download the libraries from somewhere
else, use these new ones to overwrite the ones found in the Snort source
code, and recompile. The place where I found the libraries when I
originally ported Snort 1.8 to Win32 was from the website of the person who
ported Snort 1.7 to Win32 (Michael Davis). The website is:
http://www.datanerds.com/~mike/source/snort-1.7-win32-source.zip
Download the file, extract the libraries, copy them into your Snort
.../Win32-Libraries/... directory and recompile. Good luck!
Chris Reid
----- Original Message -----
From: "John Kirk" <jki...@home.com>
To: <snort...@lists.sourceforge.net>
Sent: Thursday, August 30, 2001 8:38 AM
Subject: RE: [Snort-users] Snort 1.8.1 WIN32 MSSQL
> Chris,
>
> Thanks for the reply. I'm green at working with source code but I went
> and tried to compile the WIN32 source. I can't compile with the
> following error:
>
> Linking...
> ..\Win32-Libraries\libpcap.lib : fatal error LNK1127: library is corrupt
>
> Guess I'll have to wait for the next release or learn how to use visual
> C !
>
> Thanks,
> jk
>
> -----Original Message-----
> From: Chris Reid [mailto:Chris...@CodeCraftConsultants.com]
> Sent: Tuesday, August 28, 2001 3:08 AM
> To: John Kirk; snort...@lists.sourceforge.net
> Subject: Re: [Snort-users] Snort 1.8.1 WIN32 MSSQL
>
>
>
> John,
>
> I used the symptoms you described to help me narrow down the cause of
> the crashes (or rather what I think is the cause). I found one line of
> code in "spo_database.c" that writes into a buffer without checking if
> the buffer will overflow. (Bad me!!)
>
> If you have the source code for Snort, make the following change
> yourself and test it out. If you don't have the source, you'll need to
> wait for a little bit for things to propagate through the appropriate
> channels. I submitted the fix to Jed Pickel earlier this evening. I
> assume he'll put the fix into the official Snort source fairly quickly.
> Then it will be up to the guys at Silicon Defence to build and release a
> current version of the MSSQL build.
>
> Anyway, here is the fix... (sorry for the line-wrap -- remember to keep
> it all on one line in your source code)
>
> Line 65 is currently:
> #define SAVESTATEMENT(str) strcpy(g_CurrentStatement, str);
>
> Line 65 should become:
> #define SAVESTATEMENT(str) strncpy(g_CurrentStatement, str,
> sizeof(g_CurrentStatement)-1);
>
> Chris Reid
>
>
>
>
> ----- Original Message -----
> From: "John Kirk" <jki...@home.com>
> To: <snort...@lists.sourceforge.net>
> Sent: Sunday, August 26, 2001 5:24 AM
> Subject: [Snort-users] Snort 1.8.1 WIN32 MSSQL
>
>
> > Having difficult time getting 1.8.1 WIN32 MSSQL stable. Snort.exe
> > crashes with fatal error "snort.exe has generated errors and will be
> > closed by Windows, you will need to restart the program, an error log
> > is being created"
> >
> > This occurs as soon as an alert is logged to MSSQL. The alert is
> > completely logged to MSSQL before the crash. I'm using default rule
> > sets at this point. I've run 1.8.1 logging to mysql on the same WIN2k
> > box since it's release and it is rock solid stable. I also tried
> > running on a test box and MSSQL build creates the same fatal error.
> >
> > Thanks,
> > jk
> >
>
>
>
>
> _______________________________________________
> Snort-users mailing list
> Snort...@lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> http://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users
>
_______________________________________________
Snort-users mailing list
Snort...@lists.sourceforge.net
Go to this URL to change user options or unsubscribe:
http://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users
Olaf Schreck
> be told to handle binary files specially, to preserve the binary content so
> they don't become corrupt. From what I understand, this is not currently
> happening with the standard check-in/check-out commands. In your particular
> case, the library files are altered either when they are checked into CVS,
> or when they are checked out of CVS. I'm not sure which it is, and
> unfortunately I haven't had time to investigate this problem any further
> yet.
Anyone who wants to checkin binary files into CVS should use the -kb flag.
This tells CVS to take the file as-is, without any keyword substitutions or
NL->CR conversion. If -kb is used on checkin, it becomes a "sticky tag",
so anyone doing a checkout gets served with -kb enabled implicitly.
ciao,
chakl