From owner-freebsd-bugs@FreeBSD.ORG Wed Oct 8 11:00:34 2003 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B65E16A4DA for ; Wed, 8 Oct 2003 11:00:34 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B0E244003 for ; Wed, 8 Oct 2003 11:00:23 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h98I0NFY075443 for ; Wed, 8 Oct 2003 11:00:23 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h98I0Nop075442; Wed, 8 Oct 2003 11:00:23 -0700 (PDT) (envelope-from gnats) Resent-Date: Wed, 8 Oct 2003 11:00:23 -0700 (PDT) Resent-Message-Id: <200310081800.h98I0Nop075442@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Joachim Schueth Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A1E616A4B3 for ; Wed, 8 Oct 2003 10:56:57 -0700 (PDT) Received: from arbornet.org (m-net.arbornet.org [209.142.209.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22B9C43FBD for ; Wed, 8 Oct 2003 10:56:56 -0700 (PDT) (envelope-from dl2kcd@m-net.arbornet.org) Received: from m-net.arbornet.org (localhost [127.0.0.1]) by arbornet.org (8.12.3p2/8.11.2) with ESMTP id h98HvaC5017923; Wed, 8 Oct 2003 13:57:36 -0400 (EDT) (envelope-from dl2kcd@m-net.arbornet.org) Received: (from dl2kcd@localhost) by m-net.arbornet.org (8.12.3p2/8.12.3/Submit) id h98HvaPp017917; Wed, 8 Oct 2003 13:57:36 -0400 (EDT) Message-Id: <200310081757.h98HvaPp017917@m-net.arbornet.org> Date: Wed, 8 Oct 2003 13:57:36 -0400 (EDT) From: Joachim Schueth To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 cc: dl2kcd@darc.de Subject: kern/57760: Psec policy on inbound trafic is not enforced (allows spoofing) X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Joachim Schueth List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2003 18:00:34 -0000 >Number: 57760 >Category: kern >Synopsis: Psec policy on inbound trafic is not enforced (allows spoofing) >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Oct 08 11:00:22 PDT 2003 >Closed-Date: >Last-Modified: >Originator: Joachim Schueth >Release: FreeBSD 4.8-RELEASE-p13 i386 >Organization: >Environment: System: FreeBSD 4.8-RELEASE-p13 i386 >Description: A host with an IPsec policy that requires ESP with authentication or AH on inbound traffic accepts plain IP packets that carry no authentication. This allows to bypass the IPsec authentication mechanism. >How-To-Repeat: The following example uses ESP with authentication, but the effect is the same with AH. Configure two hosts running FreeBSD 4.8-RELEASE-p13 with IP addresses of 192.168.0.26 and 192.168.0.42, respectively (called host26 and host42 below). On host42 (the target host), use the following setkey script: flush; spdflush; add 192.168.0.26 192.168.0.42 esp 0x026042 -E 3des-cbc "xxxxxxxxxxxxxxxxxxxxxxxx" -A hmac-sha1 "hhhhhhhhhhhhhhhhhhhh"; add 192.168.0.42 192.168.0.26 esp 0x042026 -E 3des-cbc "AAAAAAAAAAAAAAAAAAAAAAAA" -A hmac-sha1 "rrrrrrrrrrrrrrrrrrrr"; spdadd 192.168.0.0/24 192.168.0.0/24 any -P in ipsec esp/transport//require; spdadd 192.168.0.0/24 192.168.0.0/24 any -P out ipsec esp/transport//require; On host26 (the attacking host), use the same setkey script but omit the spadd lines. This means that host26 has the correct security associations to accept the ESP packets of host42, but host26 itself will not use ipsec on outgoing packets. Then establish a TCP connection between host26 and host42, e.g. by connecting host42 from host26 via ftp. The connection succeeds, and a network dump shows ESP from host42 to host26, but plain TCP packets in the other direction. These packets are accepted by host42 despite the -P in .../require policy which is essentially ignored. Thus, an attacker could inject spoofed packets into an ESP connection simply by omitting the IPsec elements. The same behaviour is observed when AH is used. Note that ICMP ping packets are apparently dropped as expected, but not TCP packets. >Fix: This has to be fixed in the kernel. As a workaround, ipfw may be used to limit non-IPsec traffic. >Release-Note: >Audit-Trail: >Unformatted: