tinc-vpn.org Git - wiki/blob - security.mdwn

   1 ## Reporting security issues
   2
   3 In case you have found a security issue in tinc, please report it via email
   4 to Guus Sliepen <guus@tinc-vpn.org>, preferrably PGP encrypted.
   5 We will then try to get a CVE number assigned, and coordinate a bugfix release with major Linux distributions.
   6
   7 ## Security advisories
   8
   9 The following list contains advisories for security issues in tinc in old versions:
  10
  11 - [CVE-2018-16758](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16758):
  12   Michael Yonli discovered that tinc 1.0.34 and earlier allow a [man-in-the-middle attack](https://en.wikipedia.org/wiki/Man-in-the-middle_attack)
  13   that, even if the MITM cannot decrypt the traffic sent between the two
  14   endpoints, when the MITM can correctly predict when an ephemeral key exchange
  15   message is sent in a TCP connection between two nodes, allows the MITM to
  16   force one node to send UDP packets in plaintext.
  17   The tinc 1.1pre versions are not affected by this.
  18
  19 - [CVE-2018-16738](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16738):
  20   Michael Yonli discoverd that tinc versions 1.0.30 to 1.0.34 allow an [oracle attack](https://en.wikipedia.org/wiki/Oracle_attack),
  21   similar to CVE-2018-16737, but due to the mitigations put in place for the Sweet32
  22   attack in tinc 1.0.30, it now requires a [timing attack](https://en.wikipedia.org/wiki/Timing_attack)
  23   that has only a limited time to complete.
  24   Tinc 1.1pre16 and earlier are also affected if there are nodes on the same
  25   VPN that still use the legacy protocol from tinc version 1.0.x.
  26
  27 - [CVE-2018-16737](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16737):
  28   Michael Yonly discovered that tinc 1.0.29 and earlier allow an [oracle attack](https://en.wikipedia.org/wiki/Oracle_attack)
  29   that could allow a remote attacker to establish one-way communication with a
  30   tinc node, allowing it to send fake control messages and inject packets into
  31   the VPN. The attack takes only a few seconds to complete.
  32   Tinc 1.1pre14 and earlier allow the same attack if they are configured to allow connections
  33   from nodes using the legacy 1.0.x protocol.
  34
  35 - [CVE-2013-1428](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1428),
  36   [DSA-2663](https://www.debian.org/security/2013/dsa-2663),
  37   [Sitsec advisory](http://sitsec.net/blog/2013/04/22/stack-based-buffer-overflow-in-the-vpn-software-tinc-for-authenticated-peers):
  38   stack based buffer overflow
  39
  40 - [CVE-2002-1755](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-1755):
  41   Tinc 1.0pre3 and 1.0pre4 VPN do not authenticate forwarded packets, which allows remote attackers to inject data into user sessions without detection, and possibly control the data contents via cut-and-paste attacks on CBC.
  42
  43 - [CVE-2001-1505](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2001-1505):
  44   Tinc 1.0pre3 and 1.0pre4 allow remote attackers to inject data into user sessions by sniffing and replaying packets.
  45
  46 ## Possible weak keys generated by tinc on Debian (and derivates) due to a security bug in Debian's OpenSSL packages
  47
  48 For those who run tinc on Debian or Debian-based distributions like
  49 Ubuntu and Knoppix, be advised that the following security issue
  50 affects tinc as well:
  51 [https://www.debian.org/security/2008/dsa-1571](https://www.debian.org/security/2008/dsa-1571)
  52 In short, if you generated public/private keypairs for tinc between
  53 2006 and May 7th, 2008 on a machine running Debian or a derivative,
  54 they may have been generated without a properly seeded random
  55 number generator. Please ensure you have updated your OpenSSL
  56 packages and regenerate all suspect keypairs. Do not forget to
  57 restart tinc.
  58
  59 If you have compiled a static version of tinc on an affected
  60 platform, you need to recompile tinc to ensure it is statically
  61 linked with a fixed OpenSSL library.
  62
  63 I do not know if the session keys also have been weak, but it is
  64 best to assume they were. If you exchanged private key material via
  65 your tinc VPN, then an eavesdropper may have seen seen this as
  66 well. Regenerate any keying material that you have exchanged via
  67 your tinc VPN if any of the nodes was running on an affected
  68 platform.
  69
  70 ## Known security issues in tinc 1.0.x
  71
  72 Although tinc uses the OpenSSL library, it does not use the SSL protocol
  73 to establish connections between daemons. The reasons for this were:
  74
  75 - When tinc was created, SSL 3.0 was only just gaining popularity for use outside web browsers and servers.
  76 - SSL at that time did not make it easy to have both sides of the connection authenticate each other.
  77 - SSL requires a TCP-like transport layer to function, whereas a VPN works much more efficient if it can send encapsulated packets via a UDP-like transport layer.
  78
  79 When tinc 1.0 was released, the protocol used was declared stable and would not change anymore.
  80 However, since then some weaknesses were found, mainly by Peter Gutmann in 2003.
  81 René Korthaus, Andreas Hübner, Felix Stein and Wladimir Paulsen have also looked at tinc's protocol recently,
  82 and have provided a more in-depth analysis of the most critical weaknesses.
  83 In the interest of full disclosure we will list the known weaknesses below.
  84
  85 Tinc 1.1pre3 and later will use a new protocol that fixes all these issues,
  86 and that is similar to (D)TLS with a strong cipher suite.
  87
  88 ### Predictable IV
  89
  90 When encrypting UDP packets, tinc uses the CBC block cipher mode with a 32-bit counter as the IV.
  91 This was chosen to avoid the overhead of a full random IV for every packet.
  92 However, due to the predictable IV, an attacker could launch a chosen-plaintext attack (Katz/Lindell, "Introduction to cryptography", p.97), allowing it to distinguish known plaintexts from each other.
  93
  94 ### Truncated MAC
  95
  96 By default, tinc uses a HMAC to authenticate packets that is trunctated to 32 bits.
  97 This default was chosed to avoid the overhead of a full 160 bit hash for every packet.
  98 An attacker on a high-speed network connection could inject a forged packet by sending it 2^31 times on average with different HMACs.
  99 It is possible to change the strength of the HMAC with the `MACLength` option.
 100 We will change the default length in the future.
 101
 102 ### Use of RSA
 103
 104 Tinc uses RSA without padding. Padding schemes are designed to prevent attacks when the size of the plaintext is not equal to the size of the RSA key.
 105 However, tinc always encrypts random numbers that have the same size as the RSA key,
 106 which should safe.
 107
 108 There are timing attacks against RSA.
 109 Tinc does not protect against those.
 110
 111 ### Authentication protocol
 112
 113 Tinc uses RSA encryption to send symmetric cipher keys to its peer.
 114 Then, a challenge/response exchange is done to verify that each peer indeed has the private key.
 115 However, there is a man-in-the-middle possible where an attacker that has the public key of the peers can gain control over one side of the communication between two peers.
 116 The MITM cannot decrypt messages between peers,
 117 but it can send messages to the peer that initiated the connection.
 118 If the MITM knows enough about the VPN, it could trick peers into sending it packets that it can decrypt.
 119 However, the MITM cannot send packets to other peers.