Reporting security issues

In case you have found a security issue in tinc, please report it via email to Guus Sliepen guus@tinc-vpn.org, preferrably PGP encrypted. We will then try to get a CVE number assigned, and coordinate a bugfix release with major Linux distributions.

Security advisories

The following list contains advisories for security issues in tinc in old versions:

  • 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 discoverd 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 Yonly 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.

  • CVE-2013-1428, DSA-2663, Sitsec advisory: stack based buffer overflow

  • CVE-2002-1755: 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.

  • CVE-2001-1505: Tinc 1.0pre3 and 1.0pre4 allow remote attackers to inject data into user sessions by sniffing and replaying packets.

Possible weak keys generated by tinc on Debian (and derivates) due to a security bug in Debian’s OpenSSL packages

For those who run tinc on Debian or Debian-based distributions like Ubuntu and Knoppix, be advised that the following security issue affects tinc as well: https://www.debian.org/security/2008/dsa-1571 In short, if you generated public/private keypairs for tinc between 2006 and May 7th, 2008 on a machine running Debian or a derivative, they may have been generated without a properly seeded random number generator. Please ensure you have updated your OpenSSL packages and regenerate all suspect keypairs. Do not forget to restart tinc.

If you have compiled a static version of tinc on an affected platform, you need to recompile tinc to ensure it is statically linked with a fixed OpenSSL library.

I do not know if the session keys also have been weak, but it is best to assume they were. If you exchanged private key material via your tinc VPN, then an eavesdropper may have seen seen this as well. Regenerate any keying material that you have exchanged via your tinc VPN if any of the nodes was running on an affected platform.

Known security issues in tinc 1.0.x

Although tinc uses the OpenSSL library, it does not use the SSL protocol to establish connections between daemons. The reasons for this were:

  • When tinc was created, SSL 3.0 was only just gaining popularity for use outside web browsers and servers.
  • SSL at that time did not make it easy to have both sides of the connection authenticate each other.
  • 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.

When tinc 1.0 was released, the protocol used was declared stable and would not change anymore. However, since then some weaknesses were found, mainly by Peter Gutmann in 2003. René Korthaus, Andreas Hübner, Felix Stein and Wladimir Paulsen have also looked at tinc’s protocol recently, and have provided a more in-depth analysis of the most critical weaknesses. In the interest of full disclosure we will list the known weaknesses below.

Tinc 1.1pre3 and later will use a new protocol that fixes all these issues, and that is similar to (D)TLS with a strong cipher suite.

Predictable IV

When encrypting UDP packets, tinc uses the CBC block cipher mode with a 32-bit counter as the IV. This was chosen to avoid the overhead of a full random IV for every packet. 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.

Truncated MAC

By default, tinc uses a HMAC to authenticate packets that is trunctated to 32 bits. This default was chosed to avoid the overhead of a full 160 bit hash for every packet. An attacker on a high-speed network connection could inject a forged packet by sending it 231 times on average with different HMACs. It is possible to change the strength of the HMAC with the MACLength option. We will change the default length in the future.

Use of RSA

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. However, tinc always encrypts random numbers that have the same size as the RSA key, which should safe.

There are timing attacks against RSA. Tinc does not protect against those.

Authentication protocol

Tinc uses RSA encryption to send symmetric cipher keys to its peer. Then, a challenge/response exchange is done to verify that each peer indeed has the private key. 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. The MITM cannot decrypt messages between peers, but it can send messages to the peer that initiated the connection. If the MITM knows enough about the VPN, it could trick peers into sending it packets that it can decrypt. However, the MITM cannot send packets to other peers.