Bug 24578 - tcpflow new security issue CVE-2018-18409
Summary: tcpflow new security issue CVE-2018-18409
Status: RESOLVED FIXED
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: advisory, validated_update
Depends on:
Blocks:
 
Reported: 2019-03-28 21:01 CET by David Walser
Modified: 2019-09-12 21:11 CEST (History)
8 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.

Assignee: bugsquad => pkg-bugs
CC: (none) => cjw, geiger.david68210, guillomovitch, marja11

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

Version: Cauldron => 6
Whiteboard: MGA6TOO => (none)
Assignee: pkg-bugs => qa-bugs

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.

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

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.

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

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

Comment 8 Thomas Andrews 2019-09-11 14:17:22 CEST
The feedback flag has been set since April, with no response. Mageia 6 goes EOL very soon. What are we to do with this?
Comment 9 David Walser 2019-09-11 14:26:48 CEST
Is the issue a regression?
Comment 10 Len Lawrence 2019-09-12 10:05:14 CEST
Replying to David Walser, comment 9:
It is impossible to say without going back to the beginning.  This is a package I know very little about but shall try to find the time to run through it again.
The issue is a segfault which has the appearance of being intermittent so may be difficult to track down.
Comment 11 Len Lawrence 2019-09-12 11:13:30 CEST
Tried  this command on another, pre-update system:

# tcpflow host belexeuli
reportfilename: ./report.xml
tcpflow: listening on wlp4s0
^Ctcpflow: terminating orderly
Segmentation fault (core dumped)

This indicates that we have no regression after the update.  The "terminating orderly" message is encouraging.  It may be that there is a tidier way than control-C to stop the program.

So this is a non-issue.  Removing the feedback marker, and we might as well validate this at the same time.

Keywords: feedback => validated_update
CC: (none) => sysadmin-bugs

Thomas Backlund 2019-09-12 19:11:08 CEST

CC: (none) => tmb
Keywords: (none) => advisory

Comment 12 Mageia Robot 2019-09-12 21:11:23 CEST
An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2019-0264.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED


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