[29232] in bugtraq
ezmlm warning
daemon@ATHENA.MIT.EDU (bugtraq-help@securityfocus.com)
Sat Mar 8 06:52:39 2003
Date: 8 Mar 2003 11:43:49 -0000
Message-ID: <1047123829.4507.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:
8424
8411
--- Enclosed is a copy of the bounce message I received.
Return-Path: <>
Received: (qmail 19752 invoked from network); 24 Feb 2003 18:48:37 -0000
Received: from unknown (HELO mail.securityfocus.com) (205.206.231.9)
by lists.securityfocus.com with SMTP; 24 Feb 2003 18:48:37 -0000
Received: (qmail 14822 invoked by alias); 24 Feb 2003 18:15:27 -0000
Received: (qmail 13885 invoked from network); 24 Feb 2003 17:36:57 -0000
Received: from outgoing3.securityfocus.com (205.206.231.27)
by mail.securityfocus.com with SMTP; 24 Feb 2003 17:36:57 -0000
Received: by outgoing3.securityfocus.com (Postfix)
id 109C1A48BA; Mon, 24 Feb 2003 10:34:46 -0700 (MST)
Date: Mon, 24 Feb 2003 10:34:46 -0700 (MST)
From: MAILER-DAEMON@outgoing3.securityfocus.com (Mail Delivery System)
Subject: Undelivered Mail Returned to Sender
To: bugtraq-return-8424-bugtraq-redist=mit.edu@securityfocus.com
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="3F813A30DD.1046108048/outgoing3.securityfocus.com"
Message-Id: <20030224173446.109C1A48BA@outgoing3.securityfocus.com>
This is a MIME-encapsulated message.
--3F813A30DD.1046108048/outgoing3.securityfocus.com
Content-Description: Notification
Content-Type: text/plain
This is the Postfix program at host outgoing3.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>: host PACIFIC-CARRIER-ANNEX.mit.edu[18.7.21.83] said:
501 <bugtraq-return-8424-bugtraq-redist=mit.edu@securityfocus.com>...
Sender domain must exist (in reply to MAIL FROM command)
--3F813A30DD.1046108048/outgoing3.securityfocus.com
Content-Description: Delivery error report
Content-Type: message/delivery-status
Reporting-MTA: dns; outgoing3.securityfocus.com
Arrival-Date: Mon, 24 Feb 2003 09:47:10 -0700 (MST)
Final-Recipient: rfc822; bugtraq-redist@mit.edu
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Postfix; host PACIFIC-CARRIER-ANNEX.mit.edu[18.7.21.83]
said: 501 <bugtraq-return-8424-bugtraq-redist=mit.edu@securityfocus.com>...
Sender domain must exist (in reply to MAIL FROM command)
--3F813A30DD.1046108048/outgoing3.securityfocus.com
Content-Description: Undelivered Message
Content-Type: message/rfc822
Received: from lists.securityfocus.com (lists.securityfocus.com [205.206.231.19])
by outgoing3.securityfocus.com (Postfix) with QMQP
id 3F813A30DD; Mon, 24 Feb 2003 09:47:10 -0700 (MST)
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 6534 invoked from network); 23 Feb 2003 21:47:12 -0000
From: "Oliver Lavery" <oliver.lavery@sympatico.ca>
To: "'Drew'" <dcopley@eeye.com>, "'Timo Sirainen'" <tss@iki.fi>
Subject: RE: Bypassing Personal Firewalls
Date: Sat, 10 Aug 2002 00:27:57 -0400
Message-ID: <000501c24026$4d9572d0$3c00a8c0@Oliver>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <001d01c2da29$88d722b0$0100a8c0@stlhmntr>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Hi Drew,
Thanks, yet another really well informed and thoughtful response. I
sure am happy to have twigged all this good thinking.
>As for Unix and the potential impracticality of sandtrapping system
calls... I might note that=20
>Unix already has some effective solutions for these issues, as Dave =
Ahmad
pointed out to me several >months ago (and has held me fascinated ever
since):
>Unix has similiar systems of this kind, which Provos links to. Window's =
has
a few applications of=20
>limited capability which trap NT api calls.=20
hoglund's rootkit demonstrates this (I mentioned another, different,
rootkit in a earlier post, hoglund traps calls using a kernel mode =
driver,
whereas that one patches API functions in user mode)
>dealing with the problem... they make a signature of the firewall =
tester
itself and ban it based on=20
>that signature.
Which is clearly bullshit, and something consumers should be aware
of, and not stand for. Period.
>But, maybe someone has a better solution for a strong Application =
Firewall
out there, besides the=20
>ones we have mentioned (varieties hashing of in process memory and =
gating
system calls).
Another possible solution would be to hook relevant API calls in
system DLLs, and then disable the use of VirtualProtectEx to enable =
writing
over the memory occupied by those functions. It would still be possible =
to
execute the first few instructions of the API call yourself, and then =
JMP
into the call below the hook, though. I think this is generally a =
problem
with hardening system calls in user-mode ... Ultimately you can just
implement everything up to the transition into kernel mode and bypass =
any
user-mode hook.
Hashing all of a process's code pages seems like a very hard thing
to do. Anyone got a suggestion along these lines?
Cheers,
~ol
--3F813A30DD.1046108048/outgoing3.securityfocus.com--
