Wireshark · Wireshark-users: Re: [Wireshark-users] Filtering on (negated) frame.time_relative filters out wrong frame.number

[Miroslav Rovis <miro.rovis@xxxxxxxxxxxxxxxxx>]

( should the subject be changed to:
Filtering on frame.number filters out wrong, in *shark, editcap
    ? )

Because, in my machine...:

(but first the quote, complete, with one interrupting remark)

On 170317-11:29+0000, Graham Bloice wrote:
> On 17 March 2017 at 11:23, Peter Wu <peter@xxxxxxxxxxxxx> wrote:
> 
> > On Thu, Mar 16, 2017 at 11:57:00PM +0100, Miroslav Rovis wrote:
> > [..]
> > > I like to prepare traces (and other stuff) when I have issues. Pretty
> > > often it's been stuff like login issues to forums and similar. In which
> > > case what's most needed is get the packet with the password cut out from
> > > the trace before publishing, obviously.
> > >
> > > The version:
> > >
> > > $ wireshark --version
> > > Wireshark 2.2.5 (wireshark-2.2.5)
> > >
> > > Copyright 1998-2017 Gerald Combs <gerald@xxxxxxxxxxxxx> and
> > contributors.
> > > License GPLv2+: GNU GPL version 2 or later <http://www.gnu.org/licenses/
> > old-licenses/gpl-2.0.html>
> > > This is free software; see the source for copying conditions. There is NO
> > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> > PURPOSE.
> > >
> > > Compiled (64-bit) with Qt 5.7.1, with libpcap, with POSIX capabilities
> > (Linux),
> > > with libnl 3, with GLib 2.50.3, with zlib 1.2.11, with SMI 0.5.0, without
> > > c-ares, with Lua 5.1.5, with GnuTLS 3.5.10, with Gcrypt 1.7.6, without
> > Kerberos,
> > > without GeoIP, with QtMultimedia, without AirPcap.
> > >
> > > Running on Linux 4.9.13-hardened-r1-170310_23, with locale en_GB.utf8,
> > with
> > > libpcap version 1.8.1, with GnuTLS 3.5.10, with Gcrypt 1.7.6, with zlib
> > 1.2.11.
> > > AMD Phenom(tm) II X4 965 Processor
> > >
> > > Built using gcc 5.4.0.
> > > $
> > >
> > > And downgrading to 2.2.4 didn't chase the issue away. The repeated test
> > > below I'll do with 2.2.4.
> > >
> > > Either Wireshark or Tshark, issue is (almost always with Wireshark,
> > > always with Tshark) reproducible here. [1]
> > >
> > > On this trace [2]:
> > > dump_170316_1529_g0n.pcap (for obvious reasons not yet published)
> > > , that I need to take away the packets (two of them) containing
> > > password, I put this filter into the filter track:
> > >
> > > ((!(frame.time_relative == 159.123717557)) && (!(frame.time_relative ==
> > 188.863380487)))
> > > because upon perusing the trace, I saw that password containing packets
> > > were:
> > > 1310 and 1484
> >
> > Rather than dumping the tshark -V output, what about using File ->
> > "Export PDUs to File"? Then you also strip the TLS layer (since
> > redaction of the HTTP layer would otherwise be pretty useless when you
> > have the TLS session secrets and the encrypted data).
> >
> > To filter out frames by number you can also use "not frame.number==1310
> > and not frame.number==1484". Can you try to prepare a smaller capture
> > that can reproduce the issue which does not contain sensitive passwords?
> >
> >
> Or use editcap to drop the packets;
> 
>   editcap infile outfile packet#1 packet#2
> 
> See the man page here: https://www.wireshark.org/docs/man-pages/editcap.html

(this remark:) and I followed the above recommendation, but...

> -- 
> Graham Bloice

> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
> Archives:    https://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
>              mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe


[(but)] --...but...-- [(first the quote, complete)], and next should be the
missing info so that our kind developers, as well as the readers
generally) quickly connect the old thread (in case this email causes a
disruption in how web presents it):

Here:
( still the same subject as this very email )
https://www.wireshark.org/lists/wireshark-users/201703/msg00030.html

is where I started trying to tell about this issue.

And here:
https://www.croatiafidelis.hr/foss/cap/cap-170313-git-devuan-mail/
( the most, at this time, being in the last page of March:
https://www.croatiafidelis.hr/foss/cap/cap-170313-git-devuan-mail/git-devuan-mail-3.php
)

Pls. allow me the luxury to just continue from what I have already
explained in the linked places, (very much) without repeating. Thank
you.

...And I followed the above recommendation, but... same buggy behavior I
get.

And now that new buggy stuff (IMO) that I get.
(
And I (a customer^Wuser) had even told one of you, Jeff Morriss, that
the bug of the then thread and the then report wasn't fixed, and I was
right back then (so pls. devs and anybody, try and check this more
closely):
`tshark -T fields -e data -qz follow,ssl,raw,0` crashes in versions after 2.0.x
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12616#c7
)

Because, in my machine, with:

$ tshark -v
TShark (Wireshark) 2.2.6 (wireshark-2.2.6)

Copyright 1998-2017 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
License GPLv2+: GNU GPL version 2 or later <http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with libpcap, with POSIX capabilities (Linux), with libnl 3,
with GLib 2.50.3, with zlib 1.2.11, with SMI 0.5.0, without c-ares, with Lua
5.1.5, with GnuTLS 3.5.11, with Gcrypt 1.7.6, without Kerberos, without GeoIP.

Running on Linux 4.9.22-hardened-170417_13, with locale en_GB.utf8, with libpcap
version 1.8.1, with GnuTLS 3.5.11, with Gcrypt 1.7.6, with zlib 1.2.11.
AMD Phenom(tm) II X4 965 Processor

Built using gcc 5.4.0.
$

after having run these commands... (all of these are real-life pastes,
just the prompt is reduced to only "$"):

$ editcap dump_170317_0928_g0n.pcap  dump_170317_0928_g0n_EDIT-1069.pcap 1069
$ editcap dump_170317_0928_g0n.pcap  dump_170317_0928_g0n_EDIT-1070.pcap 1070
$ editcap dump_170317_0928_g0n.pcap  dump_170317_0928_g0n_EDIT-1071.pcap 1071
$ editcap dump_170317_0928_g0n.pcap  dump_170317_0928_g0n_EDIT-1069-1070.pcap 1069 1070
$ editcap dump_170317_0928_g0n.pcap  dump_170317_0928_g0n_EDIT-1070-1071.pcap 1070 1071
$ editcap dump_170317_0928_g0n.pcap  dump_170317_0928_g0n_EDIT-1069-1070-1071.pcap 1069 1070 1071
$ ls -ABgotr | tail -6
-rw-r--r-- 1 889260 2017-04-27 17:52 dump_170317_0928_g0n_EDIT-1069.pcap
-rw-r--r-- 1 888512 2017-04-27 17:52 dump_170317_0928_g0n_EDIT-1070.pcap
-rw-r--r-- 1 888512 2017-04-27 17:52 dump_170317_0928_g0n_EDIT-1071.pcap
-rw-r--r-- 1 888416 2017-04-27 17:53 dump_170317_0928_g0n_EDIT-1069-1070.pcap
-rw-r--r-- 1 887668 2017-04-27 17:53 dump_170317_0928_g0n_EDIT-1070-1071.pcap
-rw-r--r-- 1 887572 2017-04-27 17:53 dump_170317_0928_g0n_EDIT-1069-1070-1071.pcap
$ 

...I check, and see that...:

$ for i in $(ls -1 dump_170317_0928_g0n_EDIT-*.pcap); do ls -l $i ; tshark -r $i | grep sign_in | grep www-form-urle ; echo "---" ;  done ;
-rw-r--r-- 1 miro miro 887572 2017-04-27 17:53 dump_170317_0928_g0n_EDIT-1069-1070-1071.pcap
---
-rw-r--r-- 1 miro miro 888416 2017-04-27 17:53 dump_170317_0928_g0n_EDIT-1069-1070.pcap
 1069 33.105854500  192.168.1.4 → 78.26.97.141 HTTP 812 POST /users/sign_in HTTP/1.1  (application/x-www-form-urlencoded)
---
-rw-r--r-- 1 miro miro 889260 2017-04-27 17:52 dump_170317_0928_g0n_EDIT-1069.pcap
 1069 33.105837782  192.168.1.4 → 78.26.97.141 HTTP 812 POST /users/sign_in HTTP/1.1  (application/x-www-form-urlencoded)
---
-rw-r--r-- 1 miro miro 887668 2017-04-27 17:53 dump_170317_0928_g0n_EDIT-1070-1071.pcap
---
-rw-r--r-- 1 miro miro 888512 2017-04-27 17:52 dump_170317_0928_g0n_EDIT-1070.pcap
 1070 33.105854500  192.168.1.4 → 78.26.97.141 HTTP 812 POST /users/sign_in HTTP/1.1  (application/x-www-form-urlencoded)
---
-rw-r--r-- 1 miro miro 888512 2017-04-27 17:52 dump_170317_0928_g0n_EDIT-1071.pcap
 1070 33.105837782  192.168.1.4 → 78.26.97.141 HTTP 812 POST /users/sign_in HTTP/1.1  (application/x-www-form-urlencoded)
---
$

...[I see that] most of those got the frame.number's wrong...

If I write even more, it could be actually less useful. So what I will
now do, is... no I won't, I'll first ask if I can or need do so, I won't
attach all these:

dump_170317_0928_g0n_EDIT-1069.pcap
dump_170317_0928_g0n_EDIT-1070.pcap
dump_170317_0928_g0n_EDIT-1071.pcap
dump_170317_0928_g0n_EDIT-1069-1070.pcap
dump_170317_0928_g0n_EDIT-1070-1071.pcap
dump_170317_0928_g0n_EDIT-1069-1070-1071.pcap

but just this one I'll attach:
dump_170317_0928_g0n_EDIT-1070.pcap

since the command line used to get them/it is clearly reported. I'm not
saying it's Wireshark, could be something it uses, and I, at least in
theory, could be owned (it really doesn't look so to me)[1], but these are
what I get with those commands.

And in the next mail I could attach any other of the bunch, if it were
needed. Yeah, that's best.

I checked all the new bugs/fixes/CVE's (all the 70 or so pages in one
palemoon command I opened) and I think in none is there mention of
frame.number, so this (?) bug (Wireshark of some other's that it be) is
not in Wireshark bugzilla...

Ah, while the SSL-keys are still the same, it's not a big deal to attach
them handy too:

dump_170317_0928_g0n_SSLKEYLOGFILE.txt
(how else could you find the 'fakepassword' string?)

A couple of hours spent to put this together may not suffice for my
slowness, allow ERRATA later in the thread.

Regards!
---
[1] Pls. devs or any readers, even a confirmation that this does not
	happen in someone else's boxes is also useful to me. My Wireshark
	just consistently gets the frame.number's wrong... And it never used
	to be the case... In case of no reports, I will then try and ask in
	Gentoo Bugzilla about it... Something is causing this...
-- 
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr

CLIENT_RANDOM af775f3d92a19f32fa368147d7724884ffe06b4810c43a6acf31d204cde1cc0c 1e5fc7188ea48d59a3525f53734f5897362f3da6e5117bf7599b85ba7f1d353fb948994af441739fa77b4842143cec78
CLIENT_RANDOM d35e29cbced8c2a70c26e07baf85d66e269d9adbf10a4e27e0a3c8341708ca02 1e5fc7188ea48d59a3525f53734f5897362f3da6e5117bf7599b85ba7f1d353fb948994af441739fa77b4842143cec78
CLIENT_RANDOM f970d25e628c7b055a0d087751c09e9a4b4ce278513f3afdba7d94385bc0ec4f 1e5fc7188ea48d59a3525f53734f5897362f3da6e5117bf7599b85ba7f1d353fb948994af441739fa77b4842143cec78

Attachment: dump_170317_0928_g0n_EDIT-1070.pcap
Description: application/vnd.tcpdump.pcap

Attachment: signature.asc
Description: Digital signature