Bug 16582

Updated package uploaded for Mageia 4.

Testing procedure:
https://wiki.mageia.org/en/QA_procedure:Wireshark

Updated packages in core/updates_testing:
========================
wireshark-1.12.7-1.mga4
libwireshark5-1.12.7-1.mga4
libwiretap4-1.12.7-1.mga4
libwsutil4-1.12.7-1.mga4
libfiletap0-1.12.7-1.mga4
libwireshark-devel-1.12.7-1.mga4
wireshark-tools-1.12.7-1.mga4
tshark-1.12.7-1.mga4
rawshark-1.12.7-1.mga4
dumpcap-1.12.7-1.mga4

from wireshark-1.12.7-1.mga4.src.rpm

Whiteboard: (none) => MGA4TOO has_procedure

Testing Mageia 4 x64

BEFORE the update:
Installed from normal repos the pkgs in Comment 1, except devel; several pkg names differed (final digit):
- lib64wireshark3
- lib64wiretap3
- lib64wsutil3
Also, the pkg libfiletap0 *does not exist*. Should it be in the list?

Added my own user to group wireshark:
 # usermod -a -G wireshark lewis
From my home directory followed the good tests noted in
 https://wiki.mageia.org/en/QA_procedure:Wireshark
which omit to start capturing. Note that with no existing capture file:
 # dumpcap -w wiresharktest
 Capturing on 'enp4s0'
 dumpcap: The file to which the capture would be saved ("wiresharktest") could
 not be opened: Permission denied.
For root! So first create it:
 # > wiresharktest
Then dumpcap works        [end it with Ctrl/C].
 # dumpcap -w wiresharktest
 Capturing on 'enp4s0'
 File: wiresharktest
 ...
I refreshed a number of web pages to generate some traffic.

As the normal user, all the commands in the procedure gave O/P as indicated (except '$ dftest ip' did not show the 'dfilter' line). They accumulate O/P files: wireshark_dns.pcap  wiresharktest  wiresharkmerged   wiresharktest50 

AFTER the update to:
 wireshark-1.12.7-1.mga4
 wireshark-tools-1.12.7-1.mga4
 lib64wireshark5-1.12.7-1.mga4
 tshark-1.12.7-1.mga4
 rawshark-1.12.7-1.mga4
 lib64wiretap4-1.12.7-1.mga4
 lib64wsutil4-1.12.7-1.mga4
 dumpcap-1.12.7-1.mga4
Note that lib64wireshark5, lib64wiretap4, lib64wsutil4 are updated (number) pkg names, so leave their predecessors (all 3) rather than replacing them.

Removed the 4 previous O/P files, re-created (as root) void wiresharktest, and re-ran all the tests from dumpcap onwards. All the results were similar *except* that '$ editcap -r wiresharktest wiresharktest50 1-50' gave *no* output:
 Add_Selected: 1-50
 Inclusive ... 1, 50
which it had done before. Does this matter?

This update looks OK, but better to answer the following points before OK'ing it:
- The relevance of lib[64]filetap0
- The ultimate duplication of: lib64wireshark*, lib64wiretap*, lib64wsutil*
- Change in 'editcap' behaviour.

CC: (none) => lewyssmith

The libraries are different because for Mageia 4, this is an update to a new stable branch.  The old libraries will be orphaned.  For Wireshark updates, we usually test the PoC's from the upstream bugs, most of which tend to be tested with tshark (it's generally indicated on the bugs), as well as testing a capture as you already did.

OpenSuSE has issued an advisory for this today (August 24):
http://lists.opensuse.org/opensuse-updates/2015-08/msg00026.html

URL: (none) => http://lwn.net/Vulnerabilities/655412/

Testing more MGA4 x64 (further to Comment 2)

The only references I could use for testing from upstream - because many of the Wireshark bugs denied access; and some referred to a file [provided] which 'caused problems' - were:-
1)
 https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11373
provides test file mystery.pcap and the command for it:
 $ tshark -r mystery.pcap -d tcp.port==16568,socks -T fields -e frame.number
which previously was supposed to crash. Too late for me to try that - but M5 tester can, pre-update - but after the update, it listed 1 - 83 without crashing.
2)
 https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11389
provides test file zigbee_segfault.pcap and the command for it:
 $ tshark -r zigbee_segfault.pcap
which before the update supposedly segfaulted after line 140 (M5 tester can try this pre-update), but post-update went on to line 144 then ended
"tshark: The file "zigbee_segfault.pcap" appears to be damaged or corrupt.
(pcap: File has 1544507246-byte packet, bigger than maximum of 262144)"

So OK'ing this update.

Whiteboard: MGA4TOO has_procedure => MGA4TOO has_procedure MGA4-64-OK

These two are accessible and testable too:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11309
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11381

but I don't get a crash with tshark -nVxr on those two.  I can reproduce the segfaults with 11373 and 11389.  Everything is fine with 1.12.7.  Capture and analysis work too.  Tested on Mageia 5 i586.

Whiteboard: MGA4TOO has_procedure MGA4-64-OK => MGA4TOO has_procedure MGA4-64-OK MGA5-32-OK

All tested fine on Mageia 4 i586 as well.

Whiteboard: MGA4TOO has_procedure MGA4-64-OK MGA5-32-OK => MGA4TOO has_procedure MGA4-32-OK MGA4-64-OK MGA5-32-OK

mga5 64 LANG=fr_FR.UTF-8

Before update :
mystery.pcap list until 31 and segfault
zigbee_segfault.pcap list until 140 and segfault

After updating :
tshark-1.12.7-1.mga5.x86_64.rpm
wireshark-1.12.7-1.mga5.x86_64.rpm
wireshark-common-1.12.7-1.mga5.x86_64.rpm
lib64wireshark5-1.12.7-1.mga5.x86_64.rpm

mystery.pcap list until 83, no segfault, clean exit
zigbee_segfault.pcap list until 144 and throw  :
tshark: The file "zigbee_segfault.pcap" appears to be damaged or corrupt.
(pcap: File has 1544507246-byte packet, bigger than maximum of 262144)

but no segfault and clean exit.

Update OK.

Validated update

The advisory is in comment#0
The source rpms are:
wireshark-1.12.7-1.mga4
wireshark-1.12.7-1.mga5

A QA committer needs to upload the advisory to SVN

The packages can then be pushed to updates

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

Advisory uploaded.

Whiteboard: MGA4TOO has_procedure MGA4-32-OK MGA4-64-OK MGA5-32-OK MGA5-64-OK => MGA4TOO has_procedure MGA4-32-OK MGA4-64-OK MGA5-32-OK MGA5-64-OK advisory

An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGASA-2015-0323.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED

These have CVE-2015-6241 through CVE-2015-6249 now:
http://openwall.com/lists/oss-security/2015/09/08/4

(In reply to David Walser from comment #12)
> These have CVE-2015-6241 through CVE-2015-6249 now:
> http://openwall.com/lists/oss-security/2015/09/08/4

LWN reference:
http://lwn.net/Vulnerabilities/658449/