OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Bugtraq archives for 3rd quarter (Jul-Sep) 1998: Re: SmurfLog 1.0

Re: SmurfLog 1.0

Bug Lord (buglordSY.NET)
Fri, 10 Jul 1998 22:17:39 -0400 

On Tue, 7 Jul 1998, Solar Designer wrote:

> 3. There're also several "generic" IDS problems in your code, including
> things pointed out by SNI in their paper (like the fact that this might
> miss packets under heavy load; probably not really important in the smurf
> case, but still should be realized), and things I mentioned in my Phrack
> 53 article (coming "soon", I hope), like the usage of qsort(3) and dynamic
> memory allocation being dangerous in such applications. There're obviously
> log flood issues also.

This is definantly a problem and has been fixed in SmurfLog v1.1
(available at http://www.sy.net/security). I took out dynamic memory
allocation entirely and placed a limit on the number of broadcasts that
will be logged during an attack. I can't imagine a genuine smurf attack
going over 200 /24's, a far cry from the 256 * 256 * 256 = 16,777,216
possible /24's (at 4 bytes each entry an attack of spoofed echo replies
could force the logger to hold 64MB of memory under the old system). This
also fixes some problems with other platforms and occational segfaults
under heavy load, so everyone should upgrade.