[UNIX] Security Flaws Found in Tinc
From: support@securiteam.comDate: 01/11/02
- Previous message: support@securiteam.com: "[NEWS] Netscape Publishing wp-force-auth Command"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: support@securiteam.com To: list@securiteam.com Date: Fri, 11 Jan 2002 10:55:10 +0100 (CET)
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -
Security Flaws Found in Tinc
------------------------------------------------------------------------
SUMMARY
<http://www.nl.linux.org/pub/linux/tinc/> Tinc is a Virtual Private
Network daemon that uses tunneling and encryption to create a secure,
private network between hosts on the Internet.
An analysis of Tinc revealed several cryptographic weaknesses in the VPN
protection.
DETAILS
Background:
This section describes how Tinc secures forwarded packets. The outgoing
packet begins with a 'salt' of 2 bytes containing a cryptographically
strong random value. It plays the role of an IV according to the manual "2
bytes of salt (random data) are added in front of the actual VPN packet,
so that two VPN packets with (almost) the same content do not seem to be
the same for eavesdroppers." The forwarded packet is appended. The couple
salt and forwarded is padded to be 64bit aligned (blowfish's block size).
The whole (salt, forwarded packet and padding) is encrypted with blowfish
in CBC.
Vulnerabilities:
No packet authentication:
The aim of encryption is to make the data unreadable for anybody who does
not know the key. It does not prevent an attacker from modifying the data.
People assume that an attacker will not do it because the attacker would
not be able to choose the resulting clear text. However, this section
shows that the attacker can choose the resulting clear text to some
extends and that modifying the cipher text data may be interesting even if
the attacker ignores the result.
Inserting random data:
If the attacker modifies the cipher text without choosing the resulting
clear text, it will likely produce random data. The legitimate user will
not detect the modification and will use them as if they were valid. As
they likely appear random, it will result of a Denial of Service (DoS).
Inserting chosen data:
The encryption mode is CBC[oST81,sec 5.3]. CBC allows "cut and paste"
attacks - i.e. the attacker can cut encrypted data from one part of a
packet and paste them in another location. As both data sections have been
encrypted by the same key, the clear text will not be completely random
data.
This lack of authentication is not a CBC flaw. Authentication is not
considered an aim of the encryption mode, so most modes (e.g. ECB, CFB,
and OFB) do not authenticate the data. To use another mode would be flawed
in the same way except if they explicitly protect against forgery.
Recently some modes including authentication popped up to speed up the
encryption / authentication couple but as far as we know, they are all
patented.
In short, encrypting with CBC is Cn=Enc(Cn-1 xor Pn) where Enc(x) is
encrypting x, Pn is the nth block of plain text and Cn the nth block of
cipher text. For the first block, Cn-1 is an Initial vector (a.k.a IV)
which may be public and must be unique for a given key. The decryption is
Pn = Dec(Cn) xor Cn-1. See, "National Institute of Standards and
Technology implementing and using the nbs data encryption standard.
Federal information processing standards fips74, April 1981", for a longer
description of CBC.
If the attacker copies s blocks from the location m to n (a.k.a
[Cn,...,Cn+s-1] == [Cm,...,Cm+s-1]), Pn+1 up to Pn+s-1 will the same as
Pm+1 to Pm+s-1 and Pn will likely appears random. Cn (i.e. Cm) will be
decrypted as Pn = Dec(Cm) xor Cn-1 but Cm-1 and Cn-1 are different so Pn
will likely appears random. Nevertheless Pn+1 = Dec(Cn+1) xor Cn =
Dec(Cm+1) xor Cm = Pm+1, so Pn+1=Pm+1. Therefore, if the attacker has an
idea of the content of a group of blocks in a packet, he can copy them to
the Nth block, thus it can choose the content of it without being
detected.
As usual packets are not designed to appear random its content may be
predictable to some extents (e.g. IP header). The attacker may use such
information to guess the contents and do a knowledgeable cut/past.
Insecure IV:
The aim of an IV is to hide the repetitive patterns inside the encrypted
plain text, so it must be unique for a given key. Tinc's IV, called salt
in the source, is random so they are not guaranteed to be unique and are
vulnerable to the birthday paradox. Moreover, the IV is only 16bit long,
so as a rule of thumb if Tinc forwards 255 packets, there is a probability
of 50% to have at least 2 packets with the same IV.
No replay protection:
Tinc does not include any protection against packet's replay, so an
attacker who can eavesdrop the encrypted packets can successfully replay
them later and the destination will consider them as legitimate.
The manual section 6.3.2 claims "There is no extra provision against
replay attacks or alteration of packets. However, the VPN packets,
normally UDP or TCP packets themselves, contain checksums and sequence
numbers. Since those checksums and sequence numbers are encrypted, they
automatically become cryptographically secure. The kernel will handle any
checksum errors and duplicate packets."
We believe it is risky to base the security on assumption on the forwarded
packets. Moreover, in this case, the assumptions are incorrect. UDP does
not have any sequence number. TCP do have sequence numbers but, for
example, an attacker can replay a TCP SYN packet to perform a SYN flood
attack on a server behind the Tinc peer.
ADDITIONAL INFORMATION
The information has been provided by <mailto:jme@off.net> Jerome Etienne.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Previous message: support@securiteam.com: "[NEWS] Netscape Publishing wp-force-auth Command"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
