CVE-2012-4049 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2012-4049): epan/dissectors/packet-nfs.c in the NFS dissector in Wireshark 1.4.x before 1.4.14, 1.6.x before 1.6.9, and 1.8.x before 1.8.1 allows remote attackers to cause a denial of service (loop and CPU consumption) via a crafted packet. CVE-2012-4048 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2012-4048): The PPP dissector in Wireshark 1.4.x before 1.4.14, 1.6.x before 1.6.9, and 1.8.x before 1.8.1 allows remote attackers to cause a denial of service (invalid pointer dereference and application crash) via a crafted packet, as demonstrated by a usbmon dump.
on bump I get this and no idea how to resolve: /usr/lib64/libwireshark.so.2: undefined symbol: py_create_dissector_handle
(In reply to comment #1) > on bump I get this and no idea how to resolve: > > > /usr/lib64/libwireshark.so.2: undefined symbol: py_create_dissector_handle Have you tried to unmerge old version before merging new one?
okay I get the exact same error with 1.8.0 so considering the security issue: +*wireshark-1.8.1 (25 Jul 2012) + + 25 Jul 2012; Rick Farina <zerochaos@gentoo.org> +wireshark-1.8.1.ebuild: + version bump to resolve bug #427964 (and because I like version bumps)
(In reply to comment #2) > (In reply to comment #1) > > on bump I get this and no idea how to resolve: > > > > > > /usr/lib64/libwireshark.so.2: undefined symbol: py_create_dissector_handle > > Have you tried to unmerge old version before merging new one? Yes but right now on rebuild I get the same error for 1.8.0 so I will assume it's a bug on my system somewhere...
sorry, bad commit, reverted, give me a few to fix morbid stupidity. (at defcon, no sleep)
+*wireshark-1.8.1 (25 Jul 2012) + + 25 Jul 2012; Rick Farina <zerochaos@gentoo.org> +wireshark-1.8.1.ebuild: + version bump for bug #427964 (done right this time) I apologize for the noise but good to go this time, seriously. If the noise offended you too much, and you are at defcon, and you can find me, first beer is on me.
Arch teams, please test and mark stable: =net-analyzer/wireshark-1.8.1 Stable KEYWORDS : alpha amd64 hppa ia64 ppc ppc64 sparc x86
*** Bug 428064 has been marked as a duplicate of this bug. ***
I am going to add 1.6.9 too since python support is broken in 1.8.* and some users may rely on it.
(In reply to comment #7) > Arch teams, please test and mark stable: > =net-analyzer/wireshark-1.8.1 > Stable KEYWORDS : alpha amd64 hppa ia64 ppc ppc64 sparc x86 Since python support is broken in 1.8.1, please test and mark stable: =net-analyzer/wireshark-1.6.9 =net-analyzer/wireshark-1.8.1 Stable KEYWORDS : alpha amd64 hppa ia64 ppc ppc64 sparc x86
If we stabilize 1.8.1, users will get a hard block as wireshark blocks itself. I was unable to upgrade from 1.6.9 to 1.8.1 using stable portage. Do we really want to expose the block to stable users and force them to remove and re-install? Otherwise both 1.6.9 and 1.8.1 appear to be fine on amd64. I'll wait for guidance since I don't want to make users upgrade twice in succession by staggering the keywording.
(In reply to comment #11) > If we stabilize 1.8.1, users will get a hard block as wireshark blocks > itself. I was unable to upgrade from 1.6.9 to 1.8.1 using stable portage. > Do we really want to expose the block to stable users and force them to > remove and re-install? Bug #394479. It has a link to the upstream bug report that's been sitting there for a year. Maybe the upstream developers are prudent in that they remove the old version before building a new one. Or maybe it's just us (and Fedora). Patches welcome. > Otherwise both 1.6.9 and 1.8.1 appear to be fine on amd64. Then please stabilise both.
amd64 stable for both That bug sounds like it is linking to the library on the root filesystem and not to its own supplied library. That would be a build system error. This sort of issue wouldn't impact a binary distro a great deal - they can just build it on a system without wireshark installed, and once built it would work fine.
Stable for HPPA.
x86 stable
*** Bug 430630 has been marked as a duplicate of this bug. ***
Arch teams, please continue testing and stabilisation in bug #431572.
Already on existing GLSA draft.
This issue was resolved and addressed in GLSA 201308-05 at http://security.gentoo.org/glsa/glsa-201308-05.xml by GLSA coordinator Sergey Popov (pinkbyte).