[Wireshark-bugs] [Bug 16778] Display Filter Macros Crash Wireshark

2020-08-14 Thread bugzilla-daemon
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16778

--- Comment #5 from [email protected] ---
(In reply to Guy Harris from comment #4)
> (In reply to allenmenor16 from comment #3)
> > Yes, the macros I have been using did not crash, and worked, with packets
> > being filtered correctly in Wireshark versions up to 3.2.3, and crash in
> > Wireshark 3.2.4 and later versions. 
> > 
> > In regards to defining macros, I provided the example of "R" and "4RS" due
> > to macros being confidential information. For the case of this bug report, I
> > have defined a few macros below:
> > 
> > W - wlan.sa contains 0912.F4$1 ($1 being the remainder of the IP)
> > 2DS - (wlan.fc.ds == 0x01)
> > WB - (${W:$1} && ${2DS})
> > nRt - wlan.fc.retry == 0
> > WBR2 (${WB:$1} && ${nRt}.
> > 
> > Typing the macro "${WBR2$1} into the display filter bar crashes Wireshark.
> 
> With Wireshark 3.2.6 on macOS, it reports "Invalid character in macro name"
> in the status bar, because that's not part of the body of a macro, so $n
> doesn't stand for the nth argument to a macro - it's interpreted as part of
> a macro name.  Typing Enter does nothing (because the filter is invalid and
> can't be applied).
> 
> The crash might be the result of a difference in the Wireshark version, or a
> Windows-versus-macOS difference (such as a difference between the way their
> memory allocators work), or some other difference.
> 
> Presumably you've tried it with 3.2.6 (the latest version), as you say
> "3.2.4 and later versions".
> 
> The exception is an "access violation", which is Windows-ese for what, in
> UN*X-ese, is a "segmentation violation".  The most common cause of those is
> a null-pointer dereference, but dereferencing other invalid pointers can
> also cause a reference to an address that's not part of the address space,
> so there's a bad pointer being used somewhere.
> 
> Does it crash if you have no capture file open, and type that expression in
> and press Enter?
> 
> If not, then, if you have a file open that was open when the crash occurred,
> does it crash if you just type, for example, "ip" in the display filter bar
> and press Enter?

Wireshark does crash when I type in the expression "${WBR2:$1}" and press the
Enter key with no capture file open.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:[email protected]?subject=unsubscribe

[Wireshark-bugs] [Bug 16778] Display Filter Macros Crash Wireshark

2020-08-13 Thread bugzilla-daemon
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16778

Guy Harris  changed:

   What|Removed |Added

 Status|UNCONFIRMED |INCOMPLETE
 Ever confirmed|0   |1

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:[email protected]?subject=unsubscribe

[Wireshark-bugs] [Bug 16778] Display Filter Macros Crash Wireshark

2020-08-13 Thread bugzilla-daemon
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16778

--- Comment #4 from Guy Harris  ---
(In reply to allenmenor16 from comment #3)
> Yes, the macros I have been using did not crash, and worked, with packets
> being filtered correctly in Wireshark versions up to 3.2.3, and crash in
> Wireshark 3.2.4 and later versions. 
> 
> In regards to defining macros, I provided the example of "R" and "4RS" due
> to macros being confidential information. For the case of this bug report, I
> have defined a few macros below:
> 
> W - wlan.sa contains 0912.F4$1 ($1 being the remainder of the IP)
> 2DS - (wlan.fc.ds == 0x01)
> WB - (${W:$1} && ${2DS})
> nRt - wlan.fc.retry == 0
> WBR2 (${WB:$1} && ${nRt}.
> 
> Typing the macro "${WBR2$1} into the display filter bar crashes Wireshark.

With Wireshark 3.2.6 on macOS, it reports "Invalid character in macro name" in
the status bar, because that's not part of the body of a macro, so $n doesn't
stand for the nth argument to a macro - it's interpreted as part of a macro
name.  Typing Enter does nothing (because the filter is invalid and can't be
applied).

The crash might be the result of a difference in the Wireshark version, or a
Windows-versus-macOS difference (such as a difference between the way their
memory allocators work), or some other difference.

Presumably you've tried it with 3.2.6 (the latest version), as you say "3.2.4
and later versions".

The exception is an "access violation", which is Windows-ese for what, in
UN*X-ese, is a "segmentation violation".  The most common cause of those is a
null-pointer dereference, but dereferencing other invalid pointers can also
cause a reference to an address that's not part of the address space, so
there's a bad pointer being used somewhere.

Does it crash if you have no capture file open, and type that expression in and
press Enter?

If not, then, if you have a file open that was open when the crash occurred,
does it crash if you just type, for example, "ip" in the display filter bar and
press Enter?

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:[email protected]?subject=unsubscribe

[Wireshark-bugs] [Bug 16778] Display Filter Macros Crash Wireshark

2020-08-13 Thread bugzilla-daemon
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16778

--- Comment #3 from [email protected] ---
(In reply to Guy Harris from comment #2)
> (In reply to allenmenor16 from comment #0)
> > Steps to Reproduce:
> > 1. In Analyze > Display Filter Macros, create a complex macro with macros 
> > separated by '&&' or '||'
> > 
> > For example, complex macro 'R4' has the following text ${R:$1} && ${4RS}0
> 
> Presumably you've already defined the macros "R" and "4RS"; how are they
> defined?
> 
> > 2. Apply the macro in 'Apply a display filter' bar typing in the complex
> > macro 
> > 'R4'
> 
> That's not how you apply a macro. "R4", as a packet-matching expression,
> means "does the packet have a field named 'R4' in it?"  To apply the macro,
> you'd type in something such as "${R4:fff}", where "fff" is what should get
> passed to the macro "R".

Yes, the macros I have been using did not crash, and worked, with packets being
filtered correctly in Wireshark versions up to 3.2.3, and crash in Wireshark
3.2.4 and later versions. 

In regards to defining macros, I provided the example of "R" and "4RS" due to
macros being confidential information. For the case of this bug report, I have
defined a few macros below:

W - wlan.sa contains 0912.F4$1 ($1 being the remainder of the IP)
2DS - (wlan.fc.ds == 0x01)
WB - (${W:$1} && ${2DS})
nRt - wlan.fc.retry == 0
WBR2 (${WB:$1} && ${nRt}.

Typing the macro "${WBR2$1} into the display filter bar crashes Wireshark.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:[email protected]?subject=unsubscribe

[Wireshark-bugs] [Bug 16778] Display Filter Macros Crash Wireshark

2020-08-13 Thread bugzilla-daemon
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16778

--- Comment #2 from Guy Harris  ---
(In reply to allenmenor16 from comment #0)
> Steps to Reproduce:
> 1. In Analyze > Display Filter Macros, create a complex macro with macros 
> separated by '&&' or '||'
> 
> For example, complex macro 'R4' has the following text ${R:$1} && ${4RS}0

Presumably you've already defined the macros "R" and "4RS"; how are they
defined?

> 2. Apply the macro in 'Apply a display filter' bar typing in the complex
> macro 
> 'R4'

That's not how you apply a macro. "R4", as a packet-matching expression, means
"does the packet have a field named 'R4' in it?"  To apply the macro, you'd
type in something such as "${R4:fff}", where "fff" is what should get passed to
the macro "R".

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:[email protected]?subject=unsubscribe

[Wireshark-bugs] [Bug 16778] Display Filter Macros Crash Wireshark

2020-08-13 Thread bugzilla-daemon
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16778

--- Comment #1 from Guy Harris  ---
(In reply to allenmenor16 from comment #0)
> Build Information:
> 3.2.4 (v3.2.4-0-g893b5a5e1e3e)
> 
> Compiled (64-bit) with Qt 5.12.8, with WinPcap SDK (WpdPack) 4.1.2, with GLib
> 2.52.3, with zlib 1.2.11, with SMI 0.4.8, with c-ares 1.15.0, with Lua 5.2.4,
> with GnuTLS 3.6.3 and PKCS #11 support, with Gcrypt 1.8.3, with MIT Kerberos,
> with MaxMind DB resolver, with nghttp2 1.39.2, with brotli, with LZ4, with
> Zstandard, with Snappy, with libxml2 2.9.9, with QtMultimedia, with automatic
> updates using WinSparkle 0.5.7, with AirPcap, with SpeexDSP (using bundled
> resampler), with SBC, with SpanDSP, with bcg729.
> 
> Running on 64-bit Windows Server 2012R2, build 9600, with Intel(R) Xeon(R)
> CPU
> E5-2690 v4 @ 2.60GHz (with SSE4.2), with 8191 MB of physical memory, with
> locale
> English_United States.1252, with light display mode, without HiDPI, with
> Npcap
> version 0.9991, based on libpcap version 1.9.1, with GnuTLS 3.6.3, with
> Gcrypt
> 1.8.3, with brotli 1.0.2, without AirPcap, binary plugins supported (19
> loaded).
> 
> Built using Microsoft Visual Studio 2019 (VC++ 14.25, build 28614).
> 
> --
> When applying combined display filter macros, Wireshark crashes.
> 
> Steps to Reproduce:
> 1. In Analyze > Display Filter Macros, create a complex macro with macros 
> separated by '&&' or '||'
> 
> For example, complex macro 'R4' has the following text ${R:$1} && ${4RS}0
> 
> 2. Apply the macro in 'Apply a display filter' bar typing in the complex
> macro 
> 'R4'
> 3. Press 'Enter' key and Wireshark crashes
> 
> Actual Results: Wireshark crashes.
> 
> Expected Results: Packet capture is parsed and filtered according to the
> macro 
> with no interruptions/crash.
> 
> Additional Information/Problem Details: The macros I have been using no
> longer works in Wireshark versions 3.2.4 and above.

"No longer works in Wireshark versions 3.2.4 and above" meaning:

The macros I have been using didn't crash, and worked, with packets being
filtered correctly, in Wireshark versions up to 3.2.3, and don't crash, but
don't work, with packets *not* being filtered correctly, in Wireshark 3.2.4 and
later versions?

The macros I have been using didn't crash, and worked, with packets being
filtered correctly, in Wireshark versions up to 3.2.3, and crash in Wireshark
3.2.4 and later versions?

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:[email protected]?subject=unsubscribe

[Wireshark-bugs] [Bug 16778] Display Filter Macros Crash Wireshark

2020-08-13 Thread bugzilla-daemon
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16778

Gerald Combs  changed:

   What|Removed |Added

  Component|GTK+ UI |Qt UI

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:[email protected]?subject=unsubscribe