Skip Menu |

This queue is for tickets about the Net-LibNIDS CPAN distribution.

Report information
The Basics
Id: 52879
Status: resolved
Worked: 15 min
Priority: 0/
Queue: Net-LibNIDS

People
Owner: david [...] edeca.net
Requestors: dave [...] pdx.net
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Bug returning TCP data via Net::LibNIDS::tcp_stream::data()
Date: Thu, 17 Dec 2009 16:04:26 -0800
To: "bug-Net-LibNIDS [...] rt.cpan.org" <bug-Net-LibNIDS [...] rt.cpan.org>
From: David Giller <dave [...] pdx.net>
LibNIDS.xs has a bug when returning the data from a packet to the TCP callback sub. See the libnids API.txt or API.html section 5, which states: "If nids_discard function is never called (like in above sample program), buffer hlf->data contains exactly hlf->count_new bytes." Net::LibNIDS never calls nids_discard, and uses the default behavior, so the code in LibNIDS.xs is wrong here: *** Net-LibNIDS-0.01.orig/LibNIDS.xs 2004-06-27 04:45:00.000000000 -0700 --- Net-LibNIDS-0.01.drg/LibNIDS.xs 2009-12-17 15:33:05.000000000 -0800 *************** *** 252,258 **** data(obj) SV* obj CODE: ! RETVAL = newSVpv( obj2halfstream(obj)->data , obj2halfstream(obj)->count); OUTPUT: RETVAL --- 253,259 ---- data(obj) SV* obj CODE: ! RETVAL = newSVpv( obj2halfstream(obj)->data , obj2halfstream(obj)->count_new); OUTPUT: RETVAL The hlf->count value is the total number of bytes received in the stream, not the number of bytes in the buffer. Alternately, and probably more correctly in general, the API document suggests that this would be the way to do it that would be correct even if Net::LibNIDS eventually exposes access to the nids_discard() function: RETVAL = newSVpv( obj2halfstream(obj)->data , obj2halfstream(obj)->count - obj2halfstream(obj)->offset ); This is using libnids 1.20. This is using my own much simpler patch to solve the compilation problem that 'edeca' fixed with his patches for bug #34545, so these line numbers are relative to the unmodified Net::LibNIDS sources, but the code should not be at all hard to find. Without this fix, LibNIDS.xs accesses uninitialized data and any TCP stream with more than one packet will be corrupted when decoded using $stream->client->data() or $stream->server->data(). Development is on Debian etch, with libnids and libnet from Debian repositories. David Giller
On Thu Dec 17 19:04:48 2009, dgiller wrote: Show quoted text
> LibNIDS.xs has a bug when returning the data from a packet to the TCP > callback sub. See the libnids API.txt or API.html section 5, which > states: > > "If nids_discard function is never called (like in above sample > program), buffer hlf->data contains exactly hlf->count_new bytes." > > Net::LibNIDS never calls nids_discard, and uses the default behavior, > so the code in LibNIDS.xs is wrong here: > > *** Net-LibNIDS-0.01.orig/LibNIDS.xs 2004-06-27 04:45:00.000000000 > -0700 > --- Net-LibNIDS-0.01.drg/LibNIDS.xs 2009-12-17 15:33:05.000000000 > -0800 > *************** > *** 252,258 **** > data(obj) > SV* obj > CODE: > ! RETVAL = newSVpv( obj2halfstream(obj)->data , > obj2halfstream(obj)->count); > OUTPUT: > RETVAL > > --- 253,259 ---- > data(obj) > SV* obj > CODE: > ! RETVAL = newSVpv( obj2halfstream(obj)->data , > obj2halfstream(obj)->count_new); > OUTPUT: > RETVAL > > > The hlf->count value is the total number of bytes received in the > stream, not the number of bytes in the buffer. > > Alternately, and probably more correctly in general, the API document > suggests that this would be the way to do it that would be correct > even if Net::LibNIDS eventually exposes access to the > nids_discard() function: > > RETVAL = newSVpv( obj2halfstream(obj)->data , obj2halfstream(obj)-
> >count - obj2halfstream(obj)->offset );
> > > This is using libnids 1.20. This is using my own much simpler patch > to solve the compilation problem that 'edeca' fixed with his > patches for bug #34545, so these line numbers are relative to the > unmodified Net::LibNIDS sources, but the code should not be at all > hard to find. > > Without this fix, LibNIDS.xs accesses uninitialized data and any TCP > stream with more than one packet will be corrupted when decoded > using $stream->client->data() or $stream->server->data(). > > Development is on Debian etch, with libnids and libnet from Debian > repositories. > > David Giller
Hi David. Thanks for this, I am pretty sure I have this same fix in my local version of Net::LibNIDS (along with a few others). I can't upload it just yet until the author of the libnids libraries uploads the version 1.21 tarball I sent him which contain a few important fixes. I will update this bug and the module with the fix as soon as possible. David
From: perl [...] modtwo.com
Could somebody please apply the one-line fix changing count to count_new? This module, without the fix, can cause perl to segfault, making the module useless.
RT-Send-CC: perl [...] modtwo.com
On Thu Jan 28 19:41:42 2010, perl@modtwo.com wrote: Show quoted text
> Could somebody please apply the one-line fix changing count to > count_new? This module, without the fix, can cause perl to segfault, > making the module useless.
I have just uploaded Net::LibNIDS v0.02 which adds only this one line fix. My apologies that this may seem slow, but I have a large number of fixes for this module ready to go (which was going to be v0.02). However, they require the C API updated and my communications with the library maintainer are slower than expected.