Fedora has issued an advisory on May 31: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/66H2BSENPSIALF2WIZF7M3QBVWYBMFGW/ The problems are fixed in 3.0.15. Mageia 9 is also affected.
Whiteboard: (none) => MGA9TOOSource RPM: (none) => wireshark-4.0.14-1.mga10.src.rpmCVE: (none) => CVE-2024-4853, CVE-2024-4854, CVE-2024-4855Status comment: (none) => Fixed upstream in 4.0.15
Suggested advisory: ======================== The updated packages fix security vulnerabilities: Memory handling issue in editcap could cause denial of service via crafted capture file. (CVE-2024-4853) MONGO and ZigBee TLV dissector infinite loops in Wireshark 4.2.0 to 4.2.4, 4.0.0 to 4.0.14, and 3.6.0 to 3.6.22 allow denial of service via packet injection or crafted capture file. (CVE-2024-4854) Use after free issue in editcap could cause denial of service via crafted capture file. (CVE-2024-4855) References: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/66H2BSENPSIALF2WIZF7M3QBVWYBMFGW/ ======================== Updated packages in core/updates_testing: ======================== dumpcap-4.0.15-1.mga9 lib(64)wireshark-devel-4.0.15-1.mga9 lib(64)wireshark16-4.0.15-1.mga9 lib(64)wiretap13-4.0.15-1.mga9 lib(64)wsutil14-4.0.15-1.mga9 rawshark-4.0.15-1.mga9 tshark-4.0.15-1.mga9 wireshark-4.0.15-1.mga9 wireshark-tools-4.0.15-1.mga9 from SRPM: wireshark-4.0.15-1.mga9.src.rpm
Source RPM: wireshark-4.0.14-1.mga10.src.rpm => wireshark-4.0.14-1.mga9.src.rpmAssignee: bugsquad => qa-bugsWhiteboard: MGA9TOO => (none)Status comment: Fixed upstream in 4.0.15 => (none)Status: NEW => ASSIGNEDVersion: Cauldron => 9
Keywords: (none) => advisory
I'm not yet seeing wireshark-4.0.15-1.mga9 in M9 despite enabling and updating core-updates testing.
CC: (none) => tablackwell
mga9, x64 Wireshark was recently tested here and passed. Followed the RedHat links to gitlab.com and downloaded the PoC testfiles. Before update CVE-2024-4855 $ editcap --inject-secrets tls,file1.log -E 0.01 -c 10 poc1 /tmp/outfile.pcap Segmentation fault (core dumped) $ editcap --inject-secrets tls,./secrets.txt -E 0.01 -c 100 poc2 /tmp/outfile_00000.pcapng Segmentation fault (core dumped) $ editcap --inject-secrets tls,./secrets3.txt -E 0.01 -c 100 poc3 /tmp/outfile_00000.pcapng Segmentation fault (core dumped) Updated packages via qarepo and drakrpm-update. $ editcap --inject-secrets tls,file1.log -E 0.01 -c 10 poc1 /tmp/outfile.pcap <No error and no output in /tmp/> $ editcap --inject-secrets tls,./secrets.txt -E 0.01 -c 100 poc2 /tmp/outfile_00000.pcapng <Same again, no error and no output> $ editcap --inject-secrets tls,./secrets3.txt -E 0.01 -c 100 poc3 /tmp/outfile_00000.pcapng editcap: The file "poc3" appears to have been cut short in the middle of a packet. The first two tests seem to show that the problem files were handled gracefully while the third is more explicit about the corrupt file. Ran some simple tests as in bug 33121. $ wireshark -n lcl1.cap which showed the wireshark interface with a view of the packets captured over a short interval. $ wireshark -i enp0s20f0u3u1 -w qa.cap --autostop duration:60 ** (wireshark:602984) 21:15:00.042262 [Capture MESSAGE] -- Capture Start ... ** (wireshark:602984) 21:15:00.071408 [Capture MESSAGE] -- Capture started ** (wireshark:602984) 21:15:00.071439 [Capture MESSAGE] -- File: "qa.cap" ** (wireshark:602984) 21:16:00.462855 [Capture MESSAGE] -- Capture stopped. <played quordle in a browser while that was going on> Used the same interface to look at the capture file. Lots of TCP keepalive messages and ACKs. TLS Application Data relevant to the local machine and an ARP probe for the Powerlink adapter. The same data can be viewed in a terminal afterwards. $ tshark -nr qa.cap $ editcap -r qa.cap wiresharktest20 1-20 $ ll wiresharktest20 -rw-r--r-- 1 lcl lcl 3064 Jun 1 21:28 wiresharktest20 $ mergecap -V -w merged qa.cap wiresharktest20 mergecap: qa.cap is type Wireshark/... - pcapng. mergecap: wiresharktest20 is type Wireshark/... - pcapng. mergecap: selected frame_type Ethernet (ether) mergecap: ready to merge records Record: 1 [...] Record: 326 mergecap: merging complete $ ll wiresharktest20 -rw-r--r-- 1 lcl lcl 3064 Jun 1 21:28 wiresharktest20 No change of size because the records matched. Leaving this at this stage. It looks good.
CC: (none) => tarazed25Whiteboard: (none) => MGA9-64-OK
CC: (none) => andrewsfarm
(In reply to Tony Blackwell from comment #2) > I'm not yet seeing wireshark-4.0.15-1.mga9 in M9 despite enabling and > updating core-updates testing. Make sure you are not getting packages from an out of sync repository or use qarepo to get the testing packages you can use other mirror that the one configured by default
Validating.
CC: (none) => sysadmin-bugsKeywords: (none) => validated_update
For the record, the fixed version in this bug description should read 4.0.15.
CC: (none) => dan
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2024-0206.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED