Fedora has issued an advisory on March 21: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/MN5FW6HKPDP7PI2IVNMFSQVIDSCQ5BOR/ Mageia 6 is also affected.
Whiteboard: (none) => MGA6TOO
Status comment: (none) => Fixed upstream in 1.5.2 tag at github
Assigning to all packagers collectively, since there is no registered maintainer for this package. Also CC'ing some committers.
CC: (none) => cjw, geiger.david68210, guillomovitch, marja11Assignee: bugsquad => pkg-bugs
Fixed both mga6 and Cauldron!
Advisory: ======================== Updated tcpflow package fixes security vulnerability: A stack-based buffer over-read exists in setbit() at iptree.h of TCPFLOW 1.5.0, due to received incorrect values causing incorrect computation, leading to denial of service during an address_histogram call or a get_histogram call (CVE-2018-18409). References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18409 https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/MN5FW6HKPDP7PI2IVNMFSQVIDSCQ5BOR/ ======================== Updated packages in core/updates_testing: ======================== tcpflow-1.5.2-1.mga6 from tcpflow-1.5.2-1.mga6.src.rpm
Assignee: pkg-bugs => qa-bugsWhiteboard: MGA6TOO => (none)Version: Cauldron => 6
mga6, x86_64 CVE-2018-18409 https://github.com/SegfaultMasters/covering360/blob/master/tcpflow/setbit_00 # tcpflow -a -D -b -m -o . -Fk –r setbit_00 reportfilename: ./report.xml ./report.xml: Permission denied If this is run from the root directory after copying the POC file: # tcpflow -a -D -b -m -o /root -Fk –r setbit_00 reportfilename: /root/report.xml tcpflow: illegal token: – Upstream this aborted under ASAN. Updated to tcpflow-1.5.2-1.mga6 and ran the POC from the /root directory. # tcpflow -a -D -b -m -o . -Fk –r setbit_00 reportfilename: ./report.xml tcpflow: illegal token: – Which is the same as before and implies that the POC is not effective without ASAN. # od -a setbit_00 | grep - 0026640 1 ack nul etx nul : nul soh bs - nul nul etx w nul nul so there is a minus sign in the data, which is reported before and afterwards. No conclusion to be drawn from that. Tried a modified version of the POC command, which produced a lengthy XML report. # tcpflow -a -D -b -m -o . -Fk -i enp3s0 reportfilename: ./report.xml tcpflow: listening on enp3s0 Accessed an NFS directory hosted on another machine and also performed a remote login to that host. Used Ctrl-C to stop tcpflow. ^Ctcpflow: terminating orderly Examined report.xml and found references to MAC addresses and the LAN address of the remote machine. # firefox file:///root/report.xml Tried to display the file in a browser and ran into a parsing failure at line 37. Examined the file in emacs - there was a large chunk of garbage at line 37. After that was deleted a failure occurred three lines further on so it looks like the recording was corrupted at some point or it could have been an encapsulated binary chunk. Apart from that the file looked OK. # tcpflow -a -D -b -m -o . -Fk -r /data/qa/wireshark/test2.pcap reportfilename: ./report.xml Examination of the report shows this oddity: <dfxml xmloutputversion="1.0"><metadata><dc:type>Feature Extraction</dc:type></metadata><creator version="1.0"><program>TCPFLOW</program><version>1.5.1</version> $ rpm -qa | grep tcpflow tcpflow-1.5.2-1.mga6 # tcpflow -V TCPFLOW 1.5.1 The rest of the file looks good as far as I can see, with several fileobjects of this sort which contain recognizable LAN addresses: <fileobject><filename>000/192.168.001.<...>.02049-192.168.001.<...>.00778</filename><filesize>1344</filesize><tcpflow startime="2017-05-19T19:23:52.539396Z" endtime="2017-05-19T19:30:57.204866Z" mac_daddr="<......>" mac_saddr="<.... >" family="2" src_ipn="192.168.1.<...>" dst_ipn="192.168.1.<...>" srcport="2049" dstport="778" packets="16" len="2432"/></fileobject> $ su - Password: # tcpflow -U lcl -a -i enp3s0 reportfilename: ./report.xml dropped privs to lcl tcpflow: listening on enp3s0 tcpflow: Cannot open: <vega>.51428-<difda>.00631 # This probably happened because the network connection needed user's authentication tokens. The report was just the standard header and nothing else. # tcpflow -H This returned information on "scanners" : md5, http, netviz, python, tcpdemux, wifiviz : all disabled. Terminal output only - hexadecimal + ASCII (packet by packet by the look of it). # tcpflow -U lcl -C -D -a -i enp3s0 reportfilename: ./report.xml dropped privs to lcl tcpflow: listening on enp3s0 0000: 8000 0074 91a2 a4a2 0000 0000 0000 0002 0001 86a3 0000 0004 0000 0001 0000 0001 ...t............................ 0020: 0000 001c 0047 a537 0000 0005 6469 6664 6100 0000 0000 0000 0000 0000 0000 0000 .....G.7....difda............... [...] 0000: 504f 5354 202f 7072 696e 7465 7273 2f6f 6b64 6140 6469 6664 612e 6c6f 6361 6c20 POST /printers/okda@difda.local 0020: 4854 5450 2f31 2e31 0d0a 436f 6e74 656e 742d 4c65 6e67 7468 3a20 3232 360d 0a43 HTTP/1.1..Content-Length: 226..C [...] 0200: ae8e abe6 b3a3 6e0c 8492 38b1 824c 3d71 aca4 8ac0 767c 24a3 a73b b156 0a74 500f ......n...8..L=q....v|$..;.V.tP. 0220: 0746 3aaf 3313 699a f82d cfc4 3538 df04 7305 3d63 d106 .F:.3.i..-..58..s.=c.. ^Ctcpflow: terminating orderly Without any background knowledge, most of these sessions look fine to me. Allowing a tentative OK for 64-bits.
Whiteboard: (none) => MGA6-64-OKCC: (none) => tarazed25
Spoke too soon. Running as root: # tcpflow host localhost reportfilename: ./report.xml tcpflow: listening on enp3s0 ^Ctcpflow: terminating orderly Segmentation fault (core dumped) Note that host can also be specified by name, e.g. difda, or by network address. The journal does not help - tail of the current journal: Apr 03 16:01:32 difda su[17222]: pam_unix(su-l:session): session opened for user root by (uid=1000) Apr 03 16:01:43 difda kernel: device enp3s0 entered promiscuous mode Apr 03 16:02:05 difda kernel: device enp3s0 left promiscuous mode Apr 03 16:02:05 difda kernel: tcpflow[19858]: segfault at 0 ip 00007f11a2f2fc6a sp 00007ffe12de7218 error 4 in libc-2.22.so[7f11a2eaa000+1a9000] Apr 03 16:03:01 difda kernel: device enp3s0 entered promiscuous mode Apr 03 16:03:13 difda kernel: device enp3s0 left promiscuous mode Apr 03 16:03:13 difda kernel: tcpflow[30570]: segfault at 0 ip 00007f0a5b3f2c6a sp 00007ffcd94a0668 error 4 in libc-2.22.so[7f0a5b36d000+1a9000] Apr 03 16:04:33 difda kernel: device enp3s0 entered promiscuous mode Apr 03 16:05:56 difda kernel: device enp3s0 left promiscuous mode Apr 03 16:05:56 difda kernel: tcpflow[8603]: segfault at 0 ip 00007f2743474c6a sp 00007ffc652f7768 error 4 in libc-2.22.so[7f27433ef000+1a9000]
# tcpflow host difda and port 80 or port 443 reportfilename: ./report.xml tcpflow: listening on enp3s0 ^Ctcpflow: terminating orderly Segmentation fault (core dumped) While waiting for the Ctrl-C, browsed several sites in firefox and logged in remotely to canopus on the LAN. Recognized exoplanet.eu IP address in the report.xml. Also, the /root directory is filling up with files with names like this: -rw-r--r-- 1 root root 476 Apr 3 16:05 192.168.001.<...>.00631-192.168.001.<...>.52140 and a directory 000 with similar contents.
Sounds to me like it needs another look. Removing the 64-bit OK, because of comments 5 and 6.
Whiteboard: MGA6-64-OK => (none)CC: (none) => andrewsfarm
Keywords: (none) => feedback
Whiteboard: (none) => MGA6-64-OK