[Snort-devel] ftp USER packet processed twice in SnortFTP

Russ Combs rcombs at ...402...
Mon Sep 9 09:07:39 EDT 2013


If you can send a pcap and your related configuration we'll have a look.

Thanks
Russ


On Thu, Sep 5, 2013 at 12:15 AM, Reinoud Koornstra <sockstat at ...445...>wrote:

> Hi Everyone,
>
> I am running into a weird case with the ftp/telnet preprocessor.
> I instrumented the code to make sure
> I am running a ftp connection through the preprocessor.
> In short, i'll exlain below, in case when the USER is specified in the ftp
> connection, the packet is being processed twice by the preprocessor.
> So in detect.c in Preprocess the preprocessors do process the packet.
> So during the linked list we'll enter FTPTelnetChecks.
> spp_ftptelnet.c, FTPTelnetChecks, calling SnortFTPTelnet
> snort_ftptelnet.c, SnortFTPTelnet, calling SnortFTP
> In case of the USER ftp command we see this:
> snort_ftptelnet.c, SnortFTP, Client packet: rebuilt yes: USER blabla
> snort_ftptelnet.c, SnortFTP, calling initialize_ftp
> snort_ftptelnet.c, SnortFTP, calling check_ftp
> snort_ftptelnet.c, SnortFTP, calling do_detection which calls DynamicDetect
> snort_ftptelnet.c, do_detection, calling DynamicDetect
> sf_dynamic_plugins.c, DynamicDetect, calling Detect, Packet ID is 39515
>
> Now the weird thing ..... only in case of the USER statement in the packet
> is being processed by the preprocessor yet another time ....
> I have no clue as to why.
> When once processed in do_detection, the preprocessor flags is set to
> ALL_OFF.
> After this is done we return to DynamicDetect which returns to
> SnortFTP.....
> But we return to initialize_ftp....... in case of the USER statement. I do
> not understand or see why, but it happens, I verified it 100 times over.
>
> I did some instrumentation to verify whether what i saw was real by
> checking the if the IP ID is the same as the packet processed before, and
> in the case of the USER statement it is.
> In SnortFTP we see this:
>
>     if (iInspectMode == FTPP_SI_SERVER_MODE)
>     {
>         /* Force flush of client side of stream  */
>        bla bla bla bla
> then there is an else statement and after the initialize_ftp function is
> called and it's exactly here where we return after the first time
> inspection in case of the USER statement.
> I am baffled, as nothing in the code tells me why we return here, i can
> find nothing that tells me where we're returning there.
> It looks like a bug to me.
> I compiled with -O0 to rule out it was the optimization but that didn't
> help.
> Running it thought gdb ... and the packet is not processed twice.
> Does anybody have a clue why i am seeing what i am seeing?
>
> Also, because of this i do propose some checking code in do_detection:
>
> void do_detection(void *p)
> {
>     //extern int     do_detect;
>     //extern OptTreeNode *otn_tmp;
>     Packet *checkPacket;
>     checkPacket = (Packet *)p;
>     if (checkPacket->preprocessor_bits == PP_ALL_OFF) // This is set by
> _dpd.disableAllDetect(p)
>     {
>                return;
>     }
>
>    now we'll need to cast p to SFSnortPacket to continue the function.
> Thanks,
>
> Reinoud.
>
>
>
>
> ------------------------------------------------------------------------------
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-devel
> Archive:
> http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel
>
> Please visit http://blog.snort.org for the latest news about Snort!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20130909/bf0eba3d/attachment.html>


More information about the Snort-devel mailing list