Bug 24578 - tcpflow new security issue CVE-2018-18409
Summary: tcpflow new security issue CVE-2018-18409
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 6
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL:
Whiteboard: MGA6-64-OK
Keywords: feedback
Depends on:
Blocks:
 
Reported: 2019-03-28 21:01 CET by David Walser
Modified: 2019-05-17 21:03 CEST (History)
6 users (show)

See Also:
Source RPM: tcpflow-1.5.0-2.mga7.src.rpm
CVE:
Status comment: Fixed upstream in 1.5.2 tag at github


Attachments

Description David Walser 2019-03-28 21:01:24 CET
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.
David Walser 2019-03-28 21:01:31 CET

Whiteboard: (none) => MGA6TOO

David Walser 2019-03-28 21:22:20 CET

Status comment: (none) => Fixed upstream in 1.5.2 tag at github

Comment 1 Marja Van Waes 2019-03-29 07:56:57 CET
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, marja11
Assignee: bugsquad => pkg-bugs

Comment 2 David GEIGER 2019-04-02 09:22:02 CEST
Fixed both mga6 and Cauldron!
Comment 3 David Walser 2019-04-02 17:48:34 CEST
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-bugs
Whiteboard: MGA6TOO => (none)
Version: Cauldron => 6

Comment 4 Len Lawrence 2019-04-03 16:37:11 CEST
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-OK
CC: (none) => tarazed25

Comment 5 Len Lawrence 2019-04-03 17:13:15 CEST
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]
Comment 6 Len Lawrence 2019-04-03 18:05:27 CEST
# 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.
Comment 7 Thomas Andrews 2019-04-04 22:43:36 CEST
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

Len Lawrence 2019-04-05 20:07:27 CEST

Keywords: (none) => feedback

Len Lawrence 2019-05-17 21:03:58 CEST

Whiteboard: (none) => MGA6-64-OK


Note You need to log in before you can comment on or make changes to this bug.