Wireshark mailing list archives

Re: Filtering on (negated) frame.time_relative filters out wrong frame.number


From: Miroslav Rovis <miro.rovis () croatiafidelis hr>
Date: Thu, 27 Apr 2017 18:56:51 +0200

( 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 () lekensteyn nl> 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 () wireshark org> 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 () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?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 () wireshark org> 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

Attachment: dump_170317_0928_g0n_SSLKEYLOGFILE.txt
Description:

Attachment: dump_170317_0928_g0n_EDIT-1070.pcap
Description:

Attachment: signature.asc
Description: Digital signature

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

Current thread: