Re: Buffer overwrites with pcap_next_ex

[Michael Bernstein <mb_jobs () yahoo com>]

Man, you are such a geek.  But I acknowledge and appreciate your effort as a research and developer.  And also an MIT 
guy.  My SAT scores would never have allowed me to get into that.  What do you think about security?  MS just put a 
bounty of 1/4 million to lead to the capture of the writers of this new crippling WORM.  Aren't you interested in IT 
Security rather than devoting so much time to development of a low level packet capture program??  You would be so 
value to us whitehats in the IT Sec industry!!  I would love to see you devote your talent to IT Security - something 
larger - not saying that should not contribute to this mailing list, but we could really use your expertise for larger 
problems.  You can help us so much, since you are so knowledgeable about code at a low level.

Best,

Michael Bernstein
Sales Engineer & Security Specialist
CCIE Security #16395
CISSP, CCNP, JNCIS, PMP, IAM
GCIA, GCIH, GCFW, GSEC, CCSE+
NSA, MCAD C# Core, MCP, CNE


--- On Sat, 2/14/09, Guy Harris <guy () alum mit edu> wrote:
From: Guy Harris <guy () alum mit edu>
Subject: Re: [tcpdump-workers] Buffer overwrites with pcap_next_ex
To: tcpdump-workers () lists tcpdump org
Cc: "KT" <kt () isl de>
Date: Saturday, February 14, 2009, 6:17 PM

On Jan 25, 2009, at 2:05 AM, Andreas Rieke wrote:

> I have forgotten to mention that I use libpcap 1.0.0.

...which means that, at least on Linux, libpcap's probably using the
memory-mapped interface...

> Since I placed a debug output before and after each call to pcap, I am
> very sure that no pcap functions are called - especially not those you
> mention.

...and:

        in the memory-mapped interface, each packet in the buffer shared between the
kernel and userland has a status flag indicating, among other things, to whom
the packet "belongs";

        when the callback for a packet returns, the packet is marked as belonging to
the kernel, which means the kernel can reuse that space in the shared buffer;

        pcap_next() and pcap_next_ex() use pcap_dispatch() plus a callback which fills
in pointers to the packet header and the packet data, and then, after
pcap_dispatch() returns (which means the callback routine has returned),
returns.

This means that, with the memory-mapped interface, the packet is subject to
being overwritten by the kernel after pcap_next() or pcap_next_ex() returns.

This is probably fixable only by releasing the packet to the kernel before we
call the callback for the *next* packet rather than after the callback for
*that* packet returns.

For now, the workaround would be not to use pcap_next() or pcap_next_ex(), but
to use pcap_loop() or pcap_dispatch(), and not to assume that you can do
anything with the packet data once your callback returns.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.



      -
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.