Fedora has issued an advisory today (January 6): https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/5UTDLO275Z67H3IN6UL57U6OAI4R3G5I/ The issues are fixed upstream in 4.3.1. Mageia 6 is also affected.
Whiteboard: (none) => MGA6TOOCC: (none) => geiger.david68210
tcpreplay 4.3.1 pushed to Cauldron.
Whiteboard: MGA6TOO => (none)Version: Cauldron => 6CC: (none) => smelror
(In reply to Stig-Ørjan Smelror from comment #1) > tcpreplay 4.3.1 pushed to Cauldron. Thanks! You didn't assign this report to yourself, so I assume you don't have time to take care of this issue in Mageia 6 Assigning to all packagers collectively, since there is no registered maintainer for this package.
Assignee: bugsquad => pkg-bugsCC: (none) => marja11, nicolas.salguero
Suggested advisory: ======================== The updated package fixes security vulnerabilities: An issue was discovered in Tcpreplay 4.3.0 beta1. A heap-based buffer over-read was triggered in the function dlt_en10mb_encode() of the file plugins/dlt_en10mb/en10mb.c, due to inappropriate values in the function memmove(). The length (pktlen + ctx -> l2len) can be larger than source value (packet + ctx->l2len) because the function fails to ensure the length of a packet is valid. This leads to Denial of Service. (CVE-2018-17974) A heap-based buffer over-read exists in the function fast_edit_packet() in the file send_packets.c of Tcpreplay v4.3.0 beta1. This can lead to Denial of Service (DoS) and potentially Information Exposure when the application attempts to process a crafted pcap file. (CVE-2018-17580) Tcpreplay v4.3.0 beta1 contains a heap-based buffer over-read. The get_next_packet() function in the send_packets.c file uses the memcpy() function unsafely to copy sequences from the source buffer pktdata to the destination (*prev_packet)->pktdata. This will result in a Denial of Service (DoS) and potentially Information Exposure when the application attempts to process a file. (CVE-2018-17582) A heap-based buffer over-read was discovered in the tcpreplay-edit binary of Tcpreplay 4.3.0 beta1, during the incremental checksum operation. The issue gets triggered in the function csum_replace4() in incremental_checksum.h, causing a denial of service. (CVE-2018-18407) A use-after-free was discovered in the tcpbridge binary of Tcpreplay 4.3.0 beta1. The issue gets triggered in the function post_args() at tcpbridge.c, causing a denial of service or possibly unspecified other impact. (CVE-2018-18408) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17974 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17580 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17582 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18407 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18408 https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/5UTDLO275Z67H3IN6UL57U6OAI4R3G5I/ ======================== Updated packages in core/updates_testing: ======================== tcpreplay-4.3.1-1.mga6 from SRPMS: tcpreplay-4.3.1-1.mga6.src.rpm
Status: NEW => ASSIGNEDAssignee: pkg-bugs => qa-bugsCVE: (none) => CVE-2018-17974, CVE-2018-17580, CVE-2018-17582, CVE-2018-18407, CVE-2018-18408Source RPM: tcpreplay-4.2.6-2.mga7.src.rpm => tcpreplay-4.1.0-3.mga6.src.rpm
mga6, x86_64 Not up to speed on network packets but have some pcap files left over from wireshark testing so here goes. Resident package: tcpreplay-4.1.0-3.mga6 CVE-2018-17974 Heap-buffer overflow https://github.com/SegfaultMasters/covering360/blob/master/tcpreplay/get_next_paket_01 # tcpreplay -i eno1 -t -K --loop 4 --unique-ip get_next_paket_01 Could not get this to run using local ethernet name: $ sudo tcpreplay -i enp3s0 -t -K --loop 4 --unique-ip get_next_paket_01 Fatal Error: Unable to parse args: Invalid interface name/alias: enp3s0 $ sudo ip address | grep inet | grep -v inet6 inet 127.0.0.1/8 scope host lo inet 192.168.1.xxx/24 brd 192.168.1.255 scope global enp3s0 The man page yields: -i string, --intf1=string Client to server/RX/primary traffic output interface. This option may appear up to 1 times. Required network interface used to send either all traffic or traffic which is marked as 'primary' via tcpprep. Primary traf‐ fic is usually client-to-server or inbound (RX) on khial virtual interfaces. which does not provide any enlightenment at all. Does anybody have a clue what this all means?
CC: (none) => tarazed25
It is possible that the man page is out of date. For instance: " --listnics List available network interfaces and exit." $ sudo tcpreplay --listnics /bin/tcpreplay: illegal option -- listnics
And, sure enough, the usage message makes no mention of the --listnics option.
The man page online also lists the --listnics option.
MGA6-32 MATE on IBM Thinkpad R50e No installation issues Not much testing because not a specialist in this subject. Installed and run wireshark to get a pcap file (do not forget to make your user member of the wireshark group!!!!) Then at CLI: $ tcpcapinfo wireshtest.pcap file size = 10248 bytes magic = 0x0a0d0d0a (unknown) version = 116.0 thiszone = 0x1a2b3c4d sigfigs = 0x00000001 snaplen = 4294967295 linktype = 0xffffffff Sorry, we only support file format version 2.4 Our wireshark is at 2.2.17, so apparently obsolete. $ tcpreplay-edit wireshtest.pcap Warning: May need to run as root to get access to all network interfaces. tcpreplay-edit error: The intf1 option is required tcpreplay (tcpreplay) - Replay network traffic stored in pcap files Usage: tcpreplay-edit [ -<flag> [<val>] | --<name>[{=| }<val>] ]... <pcap_file(s)> -r, --portmap=str Rewrite TCP/UDP ports -s, --seed=num Randomize src/dst IPv4/v6 addresses w/ given seed -N, --pnat=str Rewrite IPv4/v6 addresses using pseudo-NAT and a lot more..... $ tcpreplay --listnics wireshtest.pcap Warning: May need to run as root to get access to all network interfaces. Warning: May need to run as root to get access to all network interfaces. Available network interfaces: enp2s8 any wlp2s2 wlp0s29f7u4 bluetooth-monitor nflog nfqueue usbmon1 usbmon2 usbmon3 usbmon4 Looks sensible. OK for me.
Whiteboard: (none) => MGA6-32-OKCC: (none) => herman.viaene
Before update : tcpreplay-4.1.0-3.mga6 No wireshark group. Installed wireshark and added user to the wireshark group. Tried the query option again, seeing that Herman had some success with it and used an old capture file. No difference. $ tcpreplay --listnics /bin/tcpreplay: illegal option -- listnics test2.pcap Since it is impossible to test the POC it would be as well just to update the package. Done that. $ tcpreplay --listnics test2.pcap Warning: May need to run as root to get access to all network interfaces.Available network interfaces: enp3s0 [...] So the old version was broken and testing POC was *really* impossible. But it works now. $ sudo tcpreplay -i enp3s0 -t -K --loop 4 --unique-ip get_next_paket_01 File Cache is enabled safe_pcap_next ERROR: Invalid packet length in send_packets.c:get_next_packet() line 1038: 8388670 is greater than maximum 65549 Unfortunately there is nothing with which to compare this so the result has no value. The tpcapinfo command worked here. Part of wireshark I assume. Copying the POC command: $ sudo tcpreplay -i enp3s0 -t -K --loop 4 --unique-ip test2.pcap File Cache is enabled Warning: Unable to send packet: Error with PF_PACKET send() [91]: Message too long (errno = 90) Warning: Unable to send packet: Error with PF_PACKET send() [182]: Message too long (errno = 90) Warning: Unable to send packet: Error with PF_PACKET send() [273]: Message too long (errno = 90) Warning: Unable to send packet: Error with PF_PACKET send() [364]: Message too long (errno = 90) Actual: 360 packets (72476 bytes) sent in 0.004455 seconds Rated: 16268462.4 Bps, 130.14 Mbps, 80808.08 pps Statistics for network device: enp3s0 Successful packets: 360 Failed packets: 4 Truncated packets: 0 Retried packets (ENOBUFS): 0 Retried packets (EAGAIN): 0 No progress as user - back to su: $ sudo tcpreplay-edit -i enp3s0 test2.pcap That hung......... $ sudo tcpreplay-edit -i enp3s0 --loop=2 test2.pcap Warning: Unable to send packet: Error with PF_PACKET send() [91]: Message too long (errno = 90) Warning: Unable to send packet: Error with PF_PACKET send() [182]: Message too long (errno = 90) Actual: 180 packets (36238 bytes) sent in 101.11 seconds Rated: 358.3 Bps, 0.002 Mbps, 1.78 pps Statistics for network device: enp3s0 Successful packets: 180 Failed packets: 2 Truncated packets: 0 Retried packets (ENOBUFS): 0 Retried packets (EAGAIN): 0 Don't really know what is going on here but it looks OK sort of. Thanks Herman for the pointers.
Whiteboard: MGA6-32-OK => MGA6-32-OK MGA6-64-OK
Keywords: (none) => advisory, validated_updateCC: (none) => davidwhodgins, sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2019-0094.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED