Bug 1637481 (CVE-2018-16737, CVE-2018-16738, CVE-2018-16758)

Summary: CVE-2018-16737 CVE-2018-16738 CVE-2018-16758 tinc: Multiple issues fixed in the 1.0.35 release
Product: [Other] Security Response Reporter: Andrej Nemec <anemec>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: mail
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: tinc 1.0.35 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-01-22 09:45:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1637482, 1637483    
Bug Blocks:    

Description Andrej Nemec 2018-10-09 10:48:56 UTC 
CVE-2018-16758: Michael Yonli discovered that tinc 1.0.34 and earlier allow a man-in-the-middle attack that, even if the MITM cannot decrypt the traffic sent between the two endpoints, when the MITM can correctly predict when an ephemeral key exchange message is sent in a TCP connection between two nodes, allows the MITM to force one node to send UDP packets in plaintext. The tinc 1.1pre versions are not affected by this.

CVE-2018-16738: Michael Yonli discovered that tinc versions 1.0.30 to 1.0.34 allow an oracle attack, similar to CVE-2018-16737, but due to the mitigations put in place for the Sweet32 attack in tinc 1.0.30, it now requires a timing attack that has only a limited time to complete. Tinc 1.1pre16 and earlier are also affected if there are nodes on the same VPN that still use the legacy protocol from tinc version 1.0.x.

CVE-2018-16737: Michael Yonli discovered that tinc 1.0.29 and earlier allow an oracle attack that could allow a remote attacker to establish one-way communication with a tinc node, allowing it to send fake control messages and inject packets into the VPN. The attack takes only a few seconds to complete. Tinc 1.1pre14 and earlier allow the same attack if they are configured to allow connections from nodes using the legacy 1.0.x protocol.

References:

http://www.tinc-vpn.org/security/
Comment 1 Andrej Nemec 2018-10-09 10:49:17 UTC 
Created tinc tracking bugs for this issue:

Affects: epel-all [bug 1637483]
Affects: fedora-all [bug 1637482]