From owner-freebsd-security@FreeBSD.ORG  Thu May  1 19:38:42 2014
Return-Path: <owner-freebsd-security@FreeBSD.ORG>
Delivered-To: freebsd-security@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id 8E65D2C2
 for <freebsd-security@freebsd.org>; Thu,  1 May 2014 19:38:42 +0000 (UTC)
Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com
 [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 6F70E1480
 for <freebsd-security@freebsd.org>; Thu,  1 May 2014 19:38:41 +0000 (UTC)
Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1])
 by segfault.tristatelogic.com (Postfix) with ESMTP id CDCDA3AD93
 for <freebsd-security@freebsd.org>; Thu,  1 May 2014 12:38:29 -0700 (PDT)
From: "Ronald F. Guilmette" <rfg@tristatelogic.com>
To: freebsd-security@freebsd.org
Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp
In-Reply-To: <53629582.9010605@delphij.net>
Date: Thu, 01 May 2014 12:38:29 -0700
Message-ID: <96385.1398973109@server1.tristatelogic.com>
X-BeenThere: freebsd-security@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Security issues \[members-only posting\]"
 <freebsd-security.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-security>, 
 <mailto:freebsd-security-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-security/>
List-Post: <mailto:freebsd-security@freebsd.org>
List-Help: <mailto:freebsd-security-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-security>, 
 <mailto:freebsd-security-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 01 May 2014 19:38:42 -0000


In message <53629582.9010605@delphij.net>, Xin Li <delphij@delphij.net> wrote:
>On 05/01/14 07:19, Karl Pielorz wrote:
>> 
>> 
>> --On 30 April 2014 04:35:10 +0000 FreeBSD Security Advisories 
>> <security-advisories@freebsd.org> wrote:
>> 
>>> II.  Problem Description
>>> 
>>> FreeBSD may add a reassemble queue entry on the stack into the
>>> segment list when the reassembly queue reaches its limit.  The
>>> memory from the stack is undefined after the function returns.
>>> Subsequent iterations of the reassembly function will attempt to
>>> access this entry.
>> 
>> Hi,
>> 
>> Does this require an established TCP session to be present? - i.e.
>> If you have a host which provides no external TCP sessions (i.e.
>> replies 'Connection Refused' / drops the initial SYN) would that
>> still be potentially exploitable?
>
>No.  An established TCP session is required.

I also have a question....

If one manages a system where (a) all local user accounts are completely
and 100% trustworthy and where (b) one has in place ipfw rules which reject
all incoming packet *fragments* on all outward-facing interfaces, then is
this security problem (relating to the reassembly queue) an issue at all
for said system?  Or is it rather a non-event in such contexts?


Regards,
rfg