NetBSD Problem Report #36780

From Wolfgang.Stukenbrock@nagler-company.com  Tue Aug 14 13:05:19 2007
Return-Path: <Wolfgang.Stukenbrock@nagler-company.com>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id 82A8F63B8EA
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 14 Aug 2007 13:05:19 +0000 (UTC)
Message-Id: <200708141305.l7ED5GT3017705@test-s0.nagler-company.com>
Date: Tue, 14 Aug 2007 15:05:16 +0200 (CEST)
From: Wolfgang Stukenbrock <Wolfgang.Stukenbrock@nagler-company.com>
Reply-To: Wolfgang.Stukenbrock@nagler-company.com
To: gnats-bugs@NetBSD.org
Subject: FAST-IPSEC accepts IPSEC packets from anywhere - security whole!
X-Send-Pr-Version: 3.95

>Number:         36780
>Category:       kern
>Synopsis:       FAST-IPSEC accepts IPSEC packets from anywhere - security whole!
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Aug 14 13:10:00 +0000 2007
>Originator:     Wolfgang Stukenbrock
>Release:        NetBSD 3.1
>Organization:
Dr. Nagler & Company GmbH

>Environment:


System: NetBSD test-s0 3.1 NetBSD 3.1 (test-s0) #0: Tue Apr 3 11:33:43 CEST 2007 root@test-s0:/usr/src/sys/arch/i386/compile/test-s0 i386
Architecture: i386
Machine: i386
>Description:
	FAST IPSEC does not require any input configuration for recieving packets. This migth be an advantage in speed but is a security whole
	in general!
	On the output side ESP/AH/IPCOMP will only be generated if an SPD and corresponding SA entries are present.
	But on the reciever side ignores the configuration and simply processes the packets.
	This means for IPCOMP, if it is compresses in transport mode, it will get decrompressed regardless if there is an SPD entry or an SA entry.
	For ESP this means, that the packet is decrypted when an matching SA entry is found (match means the spi must match). no SPD entry required
	or checked.
	(I do not use AH up to now, so I've not checked the effects there ...)

	For IPCOMP this behavior may be aceptable. The specification of a require in recieving of IPCOMP packets in any case is not realy usefull.
	But for ESP only the destination address and the spi needs to match in the SA entry. This results in acepting and decrypting any packet
	send to me from any machine that knows the key.
	If decryption will succeed depends on the number of equal spi' with the endpoint at my ip-address.
	And if someone gets knowlegde of the key, he may inject packets in tunnel mode to me. This is a realy big security whole in the system.

	By the way: the documentation of IPSEC seems to be completly out of date. The current implementation behaves different in lots
	of places
>How-To-Repeat:
	configure ESP between two systems and trasfer the encryption key to a third system and send ESP-tunnel packets from that system to
        the reciever side of the previous ESP setup.
>Fix:
	Prior decoding a ESP packet check if there is a valid SPD input-entry for it in any case!

>Unformatted:

Home	PR Database Search