Re: [tcpdump-workers] Packet sanitization and IP masking (PR #615)
On Wed, 13 Dec 2017 15:48:32 + alice-cyberreboot wrote > Hello again, > > Here's a new update/summary of my PR: > > - Removed short options in favor of long ones for three features - > zeroing out TCP/UDP payload in IPv4 packets (--zero-tcpudp-payload), > removing said payloads completely (--no-tcpudp-payload), and masking > external IP addresses to a given substitute IP (--mask-external-address > mask_ip); > > - manpage documentation has been updated; > > - commits related to this PR have been consolidated into one commit > message; > > - at the moment, currently up to date with upstream/master, > including modifications resulting from ether.h being unavailable. > > Hope that at this stage, the PR is now ready for proper review. > > And again, if I can assist with work on fixing CVE-related issues, please > let me know. Hello all. I have been thinking about the proposed design (making masking happen at the capture time in the same binary), and there is a possible design issue that bothers me. Consider an end user with a really high rate/bandwidth capture rig. Their first objective would be to copy the packets from the wire to the storage, as quickly as possible to minimize the drops caused by the rig performance. The first problem is, with the additional per-packet processing the performance will drop, is that going to be visible? The second objective would be to hand the capture over with masked endpoints, but what if they have more than one receiver with different mask length, or the mask length is later found to discard too many meaningful bits? It likely does not mean they have to make a new capture each time they need a different mask length. I agree in some cases it is best to mask the endpoints right at the capture time, but do you see the use case for offline masking (as in "tcpdump -r infile.pcap -w outfile.pcap ")? -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] issue with -e in IEEE802_11_RADIO mode
On Wed, 04 Apr 2018 21:14:56 +0100 Peter J. Philipp
wrote
> Hi,
>
> I get a totally bogus output with -e and -X flags set on a wlan0
> interface in monitor mode. I have spent a lot of time looking into this
> and I have finally figured out what I needed to do here. Last I'll
> paste my patch, it's easy. I know it isn't via github but I don't have
> a github login and can't even write an issue wihtout having logged in,
> so I resorted to this sane historical way.
Hello Peter.
Thank you for sending the proposed bug fix. If it requires a specific 802.11
frame to reproduce, could you post a sample .pcap file?
> I want to show you the outputs of tcpdump with the -e flag (which is now
> correct):
>
> root@epsilon:/home/pi/tcpdump/tcpdump-4.9.2# ./tcpdump -X -e -c 1 -n
> -s 100 -i
> wlan0 -l 'ether[10] == 0x18 and ether[2] == 0x0 and ether[3] ==
> 0x0'
> tcpdump: verbose output suppressed, use -v or -vv for full protocol
> decode
> listening on wlan0, link-type IEEE802_11_RADIO (802.11 plus radiotap
> header), ca
> pture size 100
> bytes
> 21:57:51.598450 1.0 Mb/s 2472 MHz 11b -58dBm signal antenna 0
> BSSID:18:d6:c7:51:
> 55:86 DA:ff:ff:ff:ff:ff:ff SA:18:d6:c7:51:55:86 Beacon () [1.0* 2.0 5.5
> 11.0 6.0
> 9.0 12.0 18.0 Mbit] IBSS CH:
> 13[|802.11]
> 0x: 8000 18d6 c751 5586
> .QU.
> 0x0010: 18d6 c751 5586 c0fa 8061 bb4b 0200
> ...QUa.K
> 0x0020: 6400 0108 8204 0b16 0c12 1824 d..$
> 0x0030: 0301 0d05 0401 0200 0032 0430 4860 6c2d .2.0H`l-
> 0x0040: 1aee 111b ff00 ..
> 1 packet captured
> 1 packet received by filter
> 0 packets dropped by kernel
I understand you are saying the above is now correct.
> and without the -e flag (which is probably everythign after the wlan
> header):
>
> root@epsilon:/home/pi/tcpdump/tcpdump-4.9.2# ./tcpdump -X -c 1 -n -s
> 100 -i wl
> an0 -l 'ether[10] == 0x18 and ether[2] == 0x0 and ether[3] ==
> 0x0'
> tcpdump: verbose output suppressed, use -v or -vv for full protocol
> decode
> listening on wlan0, link-type IEEE802_11_RADIO (802.11 plus radiotap
> header), ca
> pture size 100
> bytes
> 21:58:05.627380 1.0 Mb/s 2472 MHz 11b -58dBm signal antenna 0 Beacon ()
> [1.0* 2.
> 0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit] IBSS CH:
> 13[|802.11]
> 0x: 8071 914c 0200 6400 0108
> .q.Ld...
> 0x0010: 8204 0b16 0c12 1824 0301 0d05 0400 0200
> ...$
> 0x0020: 0032 0430 4860 6c2d 1aee 111b ff00 .2.0H`l-
> 0x0030: ..
> 1 packet captured
> 2 packets received by filter
> 0 packets dropped by kernel
I understand the above is now correct as well, right? What is the incorrect
version? Is it incorrect for both "-X -e" and "-e" or just for one of those
cases?
> Lastly as indicated here is my small patch:
>
> --- print-802_11.c.old 2018-04-04 19:40:56.458530097
> +0200
> +++ print-802_11.c 2018-04-04 21:44:15.494773874
> +0200
> @@ -3349,7 +3360,18 @@
> ieee802_11_radio_if_print(netdissect_options
> *ndo,
>const struct pcap_pkthdr *h, const u_char
> *p)
> {
> - return ieee802_11_radio_print(ndo, p, h->len,
> h->caplen);
> + const struct ieee80211_radiotap_header
> *hdr;
> + u_int hdrlen, len;
> +
> +hdr = (const struct ieee80211_radiotap_header
> *)p;
> +len =
> EXTRACT_LE_16BITS(&hdr->it_len);
> +
> + hdrlen = ieee802_11_radio_print(ndo, p, h->len,
> h->caplen);
> + if (ndo->ndo_eflag && hdrlen > len)
> {
> + return len;
> + }
> +
> + return hdrlen;
> }
>
> /*
--
Denis Ovsienko
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [tcpdump] Truncated strings
(moving this to tcpdump-workers)
On Tue, 08 May 2018 14:41:13 +0100 Francois-Xavier Le Bail
wrote
> On 02/05/2018 14:28, Francois-Xavier Le Bail wrote:
> > After the longjmp change, most of the truncated messages will be based on
> > ndo->ndo_protocol field (like: ND_PRINT("[|%s]", ndo->ndo_protocol) in Guy
> > proposal).
> >
> > To harmonize with other truncated prints, based or not on "tstr" strings,
> > I think we need to update
> > them with a new function like:
> >
> > /* Print the truncated string based on ndo_protocol */
> > void nd_print_trunc(netdissect_options *ndo)
> > {
> > ND_PRINT("[|%s]", ndo->ndo_protocol);
> > }
> >
> > And replace:
> > ND_PRINT("%s", tstr) -> nd_print_trunc(ndo)
> > ND_PRINT("\n\t[|EAP]"); -> nd_print_trunc(ndo)
> >
> > In some cases, an old printing in uppercase will go lowercase.
> > In some cases, we will remove some '\n' or '\t' not essential.
>
> I work on this and I commit HEAD~3..HEAD for first steps.
>
> But, it seems we could have site effects with this process.
>
> e.g.:
> proto1_print(...)
> {
> ndo->ndo_protocol = "proto1";
> ...
> proto2_print(...);
> ...
> }
>
> proto2_print(...)
> {
> ndo->ndo_protocol = "proto2";
> ...
> }
>
> If proto2_print, a "final protocol" (don't call another function with
> ndo_protocol assignment), need
> to print truncated string with/without longjmp process: no problem.
>
> If no truncated case occurs in proto2_print, after return, the proto1_print
> function take the
> control and if truncated case occurs in proto1_print it will print
> "[|proto2]".
>
> Thus after all calls of function with ndo_protocol assignment, we will need
> a ndo_protocol re-assign
> like:
>
> proto1_print(...)
> {
> ndo->ndo_protocol = "proto1";
> ...
> proto2_print(...);
> ndo->ndo_protocol = "proto1";
> ...
> }
>
> It can bring errors (forgetting...).
>
> Could we do things differently ?
With things done this way it looks like this issue could happen, although it
would result in incorrect labeling, not incorrect behaviour.
A possible solution could be some stack structure and a macro to call the next
function, which macro would take care to update the stack before and after the
function call. But to me such a solution looks more complicated than the
problem, I would rather proof-read the source code once and leave it to work.
--
Denis Ovsienko
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
