[27656] in bugtraq
ezmlm warning
daemon@ATHENA.MIT.EDU (bugtraq-help@securityfocus.com)
Wed Oct 30 19:55:20 2002
Date: 31 Oct 2002 00:27:00 -0000
Message-ID: <1036024020.24144.ezmlm-warn@securityfocus.com>
From: bugtraq-help@securityfocus.com
To: bugtraq-redist@mit.edu
Content-type: text/plain; charset=us-ascii
Hi! This is the ezmlm program. I'm managing the
bugtraq@securityfocus.com mailing list.
I'm working for my owner, who can be reached
at bugtraq-owner@securityfocus.com.
Messages to you from the bugtraq mailing list seem to
have been bouncing. I've attached a copy of the first bounce
message I received.
If this message bounces too, I will send you a probe. If the probe bounces,
I will remove your address from the bugtraq mailing list,
without further notice.
I've kept a list of which messages from the bugtraq mailing list have
bounced from your address.
Copies of these messages may be in the archive.
To retrieve a set of messages 123-145 (a maximum of 100 per request),
send an empty message to:
<bugtraq-get.123_145@securityfocus.com>
To receive a subject and author list for the last 100 or so messages,
send an empty message to:
<bugtraq-index@securityfocus.com>
Here are the message numbers:
6921
6929
6939
7001
7008
--- Enclosed is a copy of the bounce message I received.
Return-Path: <>
Received: (qmail 4012 invoked from network); 19 Oct 2002 05:42:57 -0000
Received: from unknown (HELO securityfocus.com) (205.206.231.9)
by lists.securityfocus.com with SMTP; 19 Oct 2002 05:42:57 -0000
Received: (qmail 28402 invoked by alias); 19 Oct 2002 05:57:08 -0000
Received: (qmail 31418 invoked from network); 19 Oct 2002 05:33:08 -0000
Received: from outgoing3.securityfocus.com (HELO outgoing.securityfocus.com) (205.206.231.27)
by mail.securityfocus.com with SMTP; 19 Oct 2002 05:33:08 -0000
Received: by outgoing.securityfocus.com (Postfix)
id 46747AF597; Fri, 18 Oct 2002 22:37:42 -0600 (MDT)
Date: Fri, 18 Oct 2002 22:37:42 -0600 (MDT)
From: MAILER-DAEMON@outgoing.securityfocus.com (Mail Delivery System)
Subject: Undelivered Mail Returned to Sender
To: bugtraq-return-6921-bugtraq-redist=mit.edu@securityfocus.com
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="BF447A36C4.1035002074/outgoing.securityfocus.com"
Message-Id: <20021019043742.46747AF597@outgoing.securityfocus.com>
This is a MIME-encapsulated message.
--BF447A36C4.1035002074/outgoing.securityfocus.com
Content-Description: Notification
Content-Type: text/plain
This is the Postfix program at host outgoing.securityfocus.com.
I'm sorry to have to inform you that the message returned
below could not be delivered to one or more destinations.
For further assistance, please send mail to <postmaster>
If you do so, please include this problem report. You can
delete your own text from the message returned below.
The Postfix program
<bugtraq-redist@mit.edu>: Name service error for mit.edu: Host found but no
data record of requested type
--BF447A36C4.1035002074/outgoing.securityfocus.com
Content-Description: Delivery error report
Content-Type: message/delivery-status
Reporting-MTA: dns; outgoing.securityfocus.com
Arrival-Date: Fri, 18 Oct 2002 16:22:55 -0600 (MDT)
Final-Recipient: rfc822; bugtraq-redist@mit.edu
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Postfix; Name service error for mit.edu: Host found but no
data record of requested type
--BF447A36C4.1035002074/outgoing.securityfocus.com
Content-Description: Undelivered Message
Content-Type: message/rfc822
Received: from lists.securityfocus.com (lists.securityfocus.com [205.206.231.19])
by outgoing.securityfocus.com (Postfix) with QMQP
id BF447A36C4; Fri, 18 Oct 2002 16:22:55 -0600 (MDT)
Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm
Precedence: bulk
List-Id: <bugtraq.list-id.securityfocus.com>
List-Post: <mailto:bugtraq@securityfocus.com>
List-Help: <mailto:bugtraq-help@securityfocus.com>
List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com>
List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com>
Delivered-To: mailing list bugtraq@securityfocus.com
Delivered-To: moderator for bugtraq@securityfocus.com
Received: (qmail 10390 invoked from network); 18 Oct 2002 20:41:39 -0000
From: "Alan DeKok" <aland@ox.org>
To: bugtraq@securityfocus.com
Subject: Re: Ambiguities in TCP/IP - firewall bypassing
In-Reply-To: Your message of "Fri, 18 Oct 2002 13:55:15 PDT."
<20021018205515.GA27861@surreal.seattlefenix.net>
Date: Fri, 18 Oct 2002 17:06:23 -0400
Sender: aland@striker.ottawa.on.ca
Message-Id: <E182eK8-0002KW-00@giles.striker.ottawa.on.ca>
Benjamin Krueger <benjamin@seattlefenix.net> wrote:
...
> > RFC 1025 (TCP and IP bake-off) has the following text:
> >
> > 10 points for correctly being able to process a "Kamikaze"
> > packet (AKA nastygram, christmas tree packet, lamp test
> > segment, et al.). That is, correctly handle a segment with
> > the maximum combination of features at once (e.g., a SYN URG
> > PUSH FIN segment with options and data).
> >
> >
> > But it doesn't define what it means by "correctly handle" such a
> > packet.
>
> Identify what the packet should be, and treat it as such? If that is
> the correct way to handle these packets, then these stacks are correct.
So... what should the packet be? As I said, the spec is ambiguous.
If you don't know what the packet is, you obviously don't know how to
treat it.
Sure, the spec *says* to treat packets with the SYN flag in a
certain way. I'm not arguing with that. What I'm arguing with is the
concept that because the spec is MISSING text on what to do in other
situations, that we know what to do in those situations.
The spec is silent on the use of ambiguous or contradictory flags
(SYN+FIN). So what happens when such a packet is received can only be
described as "implementation defined."
This is not the way to have a secure, or inter-operable protocol.
> > The TCP state machine diagram has labels naming the flags on
> > transitions from 'listen' to 'syn received', but it's silent on the
> > topic of which flags are NOT allowed.
>
> It does, however, consistantly refer to packets as "Syn" or "SynAck"
> or "Fin" packets, suggesting that only a specific flag or combination
> of flags should be used during the connection.
So SYN+URG is disallowed. But to me, that combination seems
reasonable. So my implementation may not inter-operate with yours.
At the least, we're making different assumptions, which leads to
security problems.
As I said, the spec is ambiguous.
> One could also make a case for continuing to abide by the cardinal
> rule "Be permissive in what you accept, and strict in what you send".
> Tough call, but its difficult to justify describing stacks that are
> permissive as "highly bogus" or "lazy" given that being permissive in
> what you accept is an established notion.
Well, at least I didn't say that.
> > I believe that all of the implementations you named are "compliant"
> > with the ambiguous TCP specification.
>
> Compliant by the letter, if questionably in spirit. I'm not aware of any
> tcp client systems that would send SynFin in the real world, so a stack
> that responded with RST could arguably be "more" correct (for example).
<g> I may believe otherwise. Who's to say what's compliant, if the
definition of "compliance" isn't written down anywhere?
Alan DeKok.
--BF447A36C4.1035002074/outgoing.securityfocus.com--
