Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 2 May 2014 12:16:06 -0400
From:      "David DeSimone" <ddesimone@verio.net>
To:        "Ronald F. Guilmette" <rfg@tristatelogic.com>
Cc:        freebsd-security@freebsd.org
Subject:   RE: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp
Message-ID:  <CAABACD8BCAE7B4B8A7906EEDC9DEBC5024EFDCD@IAD-WPRD-XCHB01.corp.verio.net>
In-Reply-To: <96385.1398973109@server1.tristatelogic.com>
References:  <53629582.9010605@delphij.net> <96385.1398973109@server1.tristatelogic.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Are you perhaps confusing IP Fragment Reassembly with the similar but =
unrelated TCP Segment Reassembly?

My understanding is that TCP stacks normally try very hard not to =
generate IP fragments in a TCP stream.

It appears that this bug report relates only to TCP Reassembly, and has =
nothing to do with IP Fragments.  But perhaps I am misreading it?


-----Original Message-----
From: owner-freebsd-security@freebsd.org =
[mailto:owner-freebsd-security@freebsd.org] On Behalf Of Ronald F. =
Guilmette
Sent: Thursday, May 01, 2014 2:38 PM
To: freebsd-security@freebsd.org
Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp


In message <53629582.9010605@delphij.net>, Xin Li <delphij@delphij.net> =
wrote:
>On 05/01/14 07:19, Karl Pielorz wrote:
>>=20
>>=20
>> --On 30 April 2014 04:35:10 +0000 FreeBSD Security Advisories=20
>> <security-advisories@freebsd.org> wrote:
>>=20
>>> II.  Problem Description
>>>=20
>>> 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.
>>=20
>> Hi,
>>=20
>> 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
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to =
"freebsd-security-unsubscribe@freebsd.org"


This email message is intended for the use of the person to whom it has =
been sent, and may contain information that is confidential or legally =
protected. If you are not the intended recipient or have received this =
message in error, you are not authorized to copy, distribute, or =
otherwise use this message or its attachments. Please notify the sender =
immediately by return e-mail and permanently delete this message and any =
attachments. Verio Inc. makes no warranty that this email is error or =
virus free.  Thank you.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAABACD8BCAE7B4B8A7906EEDC9DEBC5024EFDCD>