Bug 620858 – <net-analyzer/wireshark-2.2.7: Multiple vulnerabilities

• Status: RESOLVED FIXED
• Product: Gentoo Security

[Description Michael Boyle 2017-06-05 02:09:01 UTC]

In Wireshark 2.2.0 to 2.2.6, the IPv6 dissector could crash. This was addressed in epan/dissectors/packet-ipv6.c by validating an IPv6 address.

[Comment 1 Thomas Deutschmann (RETIRED) 2017-06-11 10:42:44 UTC]

@ Maintainer(s): Can we already start stabilization of =net-analyzer/wireshark-2.2.7?

[Comment 2 GLSAMaker/CVETool Bot 2017-06-11 10:51:43 UTC]

CVE-2017-9343 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9343):
  In Wireshark 2.2.0 to 2.2.6 and 2.0.0 to 2.0.12, the MSNIP dissector misuses
  a NULL pointer. This was addressed in epan/dissectors/packet-msnip.c by
  validating an IPv4 address.

CVE-2017-9344 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9344):
  In Wireshark 2.2.0 to 2.2.6 and 2.0.0 to 2.0.12, the Bluetooth L2CAP
  dissector could divide by zero. This was addressed in
  epan/dissectors/packet-btl2cap.c by validating an interval value.

CVE-2017-9345 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9345):
  In Wireshark 2.2.0 to 2.2.6 and 2.0.0 to 2.0.12, the DNS dissector could go
  into an infinite loop. This was addressed in epan/dissectors/packet-dns.c by
  trying to detect self-referencing pointers.

CVE-2017-9346 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9346):
  In Wireshark 2.2.0 to 2.2.6 and 2.0.0 to 2.0.12, the SoulSeek dissector
  could go into an infinite loop. This was addressed in
  epan/dissectors/packet-slsk.c by making loop bounds more explicit.

CVE-2017-9347 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9347):
  In Wireshark 2.2.0 to 2.2.6, the ROS dissector could crash with a NULL
  pointer dereference. This was addressed in
  epan/dissectors/asn1/ros/packet-ros-template.c by validating an OID.

CVE-2017-9348 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9348):
  In Wireshark 2.2.0 to 2.2.6, the DOF dissector could read past the end of a
  buffer. This was addressed in epan/dissectors/packet-dof.c by validating a
  size value.

CVE-2017-9349 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9349):
  In Wireshark 2.2.0 to 2.2.6 and 2.0.0 to 2.0.12, the DICOM dissector has an
  infinite loop. This was addressed in epan/dissectors/packet-dcm.c by
  validating a length value.

CVE-2017-9350 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9350):
  In Wireshark 2.2.0 to 2.2.6 and 2.0.0 to 2.0.12, the openSAFETY dissector
  could crash or exhaust system memory. This was addressed in
  epan/dissectors/packet-opensafety.c by checking for a negative length.

CVE-2017-9351 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9351):
  In Wireshark 2.2.0 to 2.2.6 and 2.0.0 to 2.0.12, the DHCP dissector could
  read past the end of a buffer. This was addressed in
  epan/dissectors/packet-bootp.c by extracting the Vendor Class Identifier
  more carefully.

CVE-2017-9352 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9352):
  In Wireshark 2.2.0 to 2.2.6 and 2.0.0 to 2.0.12, the Bazaar dissector could
  go into an infinite loop. This was addressed in epan/dissectors/packet-bzr.c
  by ensuring that backwards parsing cannot occur.

CVE-2017-9353 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9353):
  In Wireshark 2.2.0 to 2.2.6, the IPv6 dissector could crash. This was
  addressed in epan/dissectors/packet-ipv6.c by validating an IPv6 address.

CVE-2017-9354 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9354):
  In Wireshark 2.2.0 to 2.2.6 and 2.0.0 to 2.0.12, the RGMP dissector could
  crash. This was addressed in epan/dissectors/packet-rgmp.c by validating an
  IPv4 address.

[Comment 3 Jeroen Roovers (RETIRED) 2017-06-11 11:50:08 UTC]

(In reply to Thomas Deutschmann from comment #1)
> @ Maintainer(s): Can we already start stabilization of
> =net-analyzer/wireshark-2.2.7?

Of course you can.

[Comment 4 Thomas Deutschmann (RETIRED) 2017-06-11 13:20:47 UTC]

@ Arches,

please test and mark stable: =net-analyzer/wireshark-2.2.7

[Comment 5 Agostino Sarubbo 2017-06-12 12:42:07 UTC]

amd64 stable

[Comment 6 Agostino Sarubbo 2017-06-12 12:54:58 UTC]

x86 stable

[Comment 7 Agostino Sarubbo 2017-06-13 12:34:48 UTC]

ppc64 stable

[Comment 8 Markus Meier 2017-06-13 18:22:49 UTC]

arm stable

[Comment 9 Tobias Klausmann (RETIRED) 2017-06-20 15:00:08 UTC]

Stable on alpha.

[Comment 10 Agostino Sarubbo 2017-06-21 12:02:48 UTC]

ppc stable

[Comment 11 Sergei Trofimovich (RETIRED) 2017-06-30 07:32:30 UTC]

ia64 stable

[Comment 12 Agostino Sarubbo 2017-07-07 09:08:47 UTC]

sparc stable

[Comment 13 Christopher Díaz Riveros (RETIRED) 2017-08-17 01:09:27 UTC]

Arches, please finish stabilizing hppa

Gentoo Security  Padawan
ChrisADR

[Comment 14 Andreas Sturmlechner 2017-08-19 10:10:47 UTC]

It seems hppa was stabilised by git commit ec35de853bc3f1331de3fd5cc6611390d6824b3c

[Comment 15 Christopher Díaz Riveros (RETIRED) 2017-08-19 16:20:09 UTC]

(In reply to Andreas Sturmlechner from comment #14)
> It seems hppa was stabilised by git commit
> ec35de853bc3f1331de3fd5cc6611390d6824b3c

Thank you Andreas for the info.

Security please vote for the GLSA.

Gentoo Security Padawan
ChrisADR

[Comment 16 Aaron Bauman (RETIRED) 2017-08-21 01:27:49 UTC]

GLSA Vote: No