Date: Sat, 20 Jun 1998 00:03:03 -0400
Reply-To: Bugtraq List
Sender: Bugtraq List
From: Automatic digest processor
Subject: BUGTRAQ Digest - 18 Jun 1998 to 19 Jun 1998
To: Recipients of BUGTRAQ digests
Message-Id: <19980620040508Z97506-14936+22@brimstone.netspace.org>
There are 14 messages totalling 915 lines in this issue.
Topics of the day:
1. IRIX mail(1)/rmail(1M)/sendmail(1M) Security Vulnerabilities
2. Security problems on SCO's lp subsystem (3)
3. Word 98 Insecurity
4. protocol 191 clarification
5. Solaris 2.5.1 patch not effective?
6. Port 0 oddities
7. another remote pine vunerability (4)
8. Re : Bind 4.9.6 ~ Current | X86 Exploit
9. talkd vulnerability in patched RH 5.0?
----------------------------------------------------------------------
Date: Thu, 18 Jun 1998 15:04:25 -0700
From: SGI Security Coordinator
Subject: IRIX mail(1)/rmail(1M)/sendmail(1M) Security Vulnerabilities
DISTRIBUTION RESTRICTIONS - NONE - FOR PUBLIC RELEASE
-----BEGIN PGP SIGNED MESSAGE-----
______________________________________________________________________________
Silicon Graphics Inc. Security Advisory
Title: IRIX mail(1)/rmail(1M)/sendmail(1M) Security Vulnerabilities
Title: CERT CA-96.20
Number: 19980604-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 ---
- ------------------------
This advisory covers two security issues that were publically reported as
two different issues. Both these issues have been addressed together
as one issue by Silicon Graphics.
The first security issue involves mail(1)/rmail(1M) programs.
The mail(1) program, also know as mail_att, is used to read or send email.
The rmail(1M) program is usually invoked by uux(1C) to receive email
via UUCP(1C).
Several security vulnerabilities were discovered in mail(1)/rmail(1M) that
allow any local user with access to mail(1) and rmail(1M) programs to access
or modify any file that is owned by the mail group(4).
The second security issue involves sendmail(1M).
The sendmail(1M) program is used to deliver and receive email.
On a fully patched IRIX system, the default version of sendmail is 8.6.12.
Several vulnerabilities have been found in sendmail 8.7.5 and lower which are
referenced and documented in CERT CA-96.20 and can be found at:
http://www.cert.org/advisories/CA-96.20.sendmail_vul.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 mail(1)/rmail(1M)/sendmail(1M) programs are installed by default on IRIX.
A user account on the vulnerable system is required in order to exploit
mail(1)/rmail(1M) locally and remotely.
A local user account is not needed to exploit the sendmail(1M) program locally
and remotely.
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 vulnerability by removing
the setgid permissions of the mail(1)/rmail(1M) programs.
There are no workarounds for sendmail 8.6.12 vulnerabilities.
The sendmail(1M) program must be disabled or the patches need to be installed
to upgrade it to sendmail 8.8.8.
1) Become the root user on the system.
% /bin/su -
Password:
#
2) Remove the setgid permissions on the vulnerable programs.
# /bin/chmod 555 /usr/bin/mail
# /bin/chmod 555 /usr/bin/rmail
4) Verify the new permissions on the program.
Note that the program size may be different depending on release.
# ls -al /usr/bin/mail /usr/bin/rmail
-r-xr-xr-x 1 root mail 53024 Feb 12 1996 mail
-r-xr-xr-x 1 root mail 14216 May 16 1996 rmail
5) Disable the vulnerable sendmail(1M) program.
# chkconfig sendmail off
# /etc/init.d/mail stop
5) Return to previous user level.
# exit
%
- -----------------
- ---- Solution ---
- -----------------
These patches fix the rmail(1)/mail(1M) security vulnerabilities and upgrade
sendmail(1M) to version 8.8.8.
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 2309
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 2231
IRIX 6.3 yes 2310
IRIX 6.4 yes 2310
IRIX 6.5 no
NOTES
1) Upgrade to currently supported IRIX operating system.
2) See "Temporary Solution" section for a workaround.
3) Unsupported by SGI, "freeware" sendmail distributions can be found at
http://www.sendmail.org/
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.2231
Algorithm #1 (sum -r): 29635 8 README.patch.2231
Algorithm #2 (sum): 61238 8 README.patch.2231
MD5 checksum: 93F6B8811CE2576475316A2B4642FFA5
Filename: patchSG0002231
Algorithm #1 (sum -r): 52080 2 patchSG0002231
Algorithm #2 (sum): 7506 2 patchSG0002231
MD5 checksum: 513D5729D2356C79D5E397863803F5D5
Filename: patchSG0002231.eoe_man
Algorithm #1 (sum -r): 31776 69 patchSG0002231.eoe_man
Algorithm #2 (sum): 10533 69 patchSG0002231.eoe_man
MD5 checksum: A6E76331FE9611319D137B260CF0D76E
Filename: patchSG0002231.eoe_sw
Algorithm #1 (sum -r): 13889 687 patchSG0002231.eoe_sw
Algorithm #2 (sum): 24064 687 patchSG0002231.eoe_sw
MD5 checksum: 8228192A12048ACD78AB8F262A006A33
Filename: patchSG0002231.idb
Algorithm #1 (sum -r): 07552 6 patchSG0002231.idb
Algorithm #2 (sum): 29565 6 patchSG0002231.idb
MD5 checksum: 4B4CA561990D6CCE21C322650DB5E4D6
Filename: README.patch.2309
Algorithm #1 (sum -r): 32975 9 README.patch.2309
Algorithm #2 (sum): 60467 9 README.patch.2309
MD5 checksum: 5848AB770B8EA81FA196FFCC12082056
Filename: patchSG0002309
Algorithm #1 (sum -r): 56282 4 patchSG0002309
Algorithm #2 (sum): 42072 4 patchSG0002309
MD5 checksum: 14649EBE949F464B28E17FA03F001AC8
Filename: patchSG0002309.eoe1_man
Algorithm #1 (sum -r): 57312 69 patchSG0002309.eoe1_man
Algorithm #2 (sum): 39389 69 patchSG0002309.eoe1_man
MD5 checksum: 7DA3680EC4CBB635265E349E9603C58B
Filename: patchSG0002309.eoe1_sw
Algorithm #1 (sum -r): 28257 688 patchSG0002309.eoe1_sw
Algorithm #2 (sum): 30302 688 patchSG0002309.eoe1_sw
MD5 checksum: 250B98DC7C4207094818C2C2F2C37254
Filename: patchSG0002309.idb
Algorithm #1 (sum -r): 53181 6 patchSG0002309.idb
Algorithm #2 (sum): 30341 6 patchSG0002309.idb
MD5 checksum: 57CFB3DE7EACE6CEC75A8C1EECBE6E6D
Filename: README.patch.2310
Algorithm #1 (sum -r): 30227 8 README.patch.2310
Algorithm #2 (sum): 53644 8 README.patch.2310
MD5 checksum: 109285169451B313A39E157801EF77A5
Filename: patchSG0002310
Algorithm #1 (sum -r): 52429 2 patchSG0002310
Algorithm #2 (sum): 57083 2 patchSG0002310
MD5 checksum: A7FD0C1AEDD8D2F75FE72232E71B6483
Filename: patchSG0002310.eoe_man
Algorithm #1 (sum -r): 07011 69 patchSG0002310.eoe_man
Algorithm #2 (sum): 10532 69 patchSG0002310.eoe_man
MD5 checksum: F0003330AB4E323744B6015182E0F68A
Filename: patchSG0002310.eoe_sw
Algorithm #1 (sum -r): 64113 692 patchSG0002310.eoe_sw
Algorithm #2 (sum): 13768 692 patchSG0002310.eoe_sw
MD5 checksum: DA6870AD18DBC691424B5E52B32DF18B
Filename: patchSG0002310.idb
Algorithm #1 (sum -r): 07855 6 patchSG0002310.idb
Algorithm #2 (sum): 28233 6 patchSG0002310.idb
MD5 checksum: 6836E4720A7F7779681EB0486D8AAD5C
- -------------------------
- ---- Acknowledgments ---
- -------------------------
Silicon Graphics wishes to thank the CERT Coordination Center and the users
of the Internet Community at large 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
iQCVAwUBNYmJybQ4cFApAP75AQFY4QP/SZhh4+kREQsLq5UomklA6JxTeGK4RNDC
UJAN5p3kvDHZokC/aMKUPsweA5wry904tM0BefDmxtEqWClF8X5okGnAQrPNjxXv
lwEKrx08lY1Wxi0zqq48YkR9Z4WXapRRlu3rzdOHxQ4yz8T7DmA9MBAmKaz7w4FG
9icf4mHTRyg=
=79In
-----END PGP SIGNATURE-----
------------------------------
Date: Thu, 18 Jun 1998 21:02:46 -0400
From: "Michael L. Wilkerson Jr."
Subject: Re: 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.
Okay, I've tested these both. My box is:
SCO 5.0.4 Enterprise
(also) Plain Vanilla Intel
as root...
echo "test" > /tmp/rootfile
and the perms thereof are...
drwxrwxrwt 2 sys sys 1024 Jun 18 20:26 tmp
and
-rw-rw-r-- 1 root sys 5 Jun 18 20:26 rootfile
okay. now as a normal, unprivileged user, I run...
lpr -d lp -R /tmp/rootfile
...and to my displeasure, but as expected, the root-owned tempfile is
removed. (BTW, this normal user is NOT a member of the group, sys --of course).
>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.
One more time!
running "touch /var/spool/lpd/lock"
yields:
-rw-rw-r-- 1 root sys 0 Jun 18 20:41 /var/spool/lpd/lock
...now as the same normal user I run (with rootfile being an as of yet
non-existing file)
lp -L live=/tmp/rootfile
Okay, then I enter whatever text I choose...and a ^D and bingo!
now "ls -l /tmp/rootfile" yields:
-rw------- 1 root lp 21 Jun 18 20:45 rootfile
Of course, the same normal user which created the file can now not even read it.
Okay, now to a previously existing /tmp/rootfile with perms
-rw-rw-r-- 1 root sys 5 Jun 18 20:52 rootfile
...I append, as a normal user, using the same lp exploit, whatever text I
choose. Now, ls -l /tmp/rootfile yields:
-rw-rw-r-- 1 root sys 28 Jun 18 20:53 rootfile
so, the perms didn't not become 600. But the new text has completely
overwritten the original text.
One thing to note is that file /var/spool/lpd/lock did not previously exist
before root touched it into existence.
>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.
actually the perms on /usr/bin/lp are:
---x--x--x 1 bin lp 2472 Jun 18 20:10 /usr/bin/lp
and of course, lpr is a symlink to /usr/bin/lp.
Looks dangerous!
======================== Mike Wilkerson ==========================
"You cannot go on 'seeing through' things forever. The whole point
of seeing through something is to see something through it."
C.S. Lewis, "The Abolition of Man"
PGP Public Key: http://www.talleytech.com/~mwilkers/mypubkey.asc
==================== mwilkers@talleytech.com =====================
------------------------------
Date: Fri, 19 Jun 1998 13:48:48 -0500
From: Mike
Subject: Word 98 Insecurity
When fooling around with Word 98 on the Macintosh, I found the following
SEVERE insecurity.
1. Open a few documents, work on your Macintosh for a while.
2. Open word 98 and compose a message, then save it to your dirve.
3. Attach the document to an email, and send it.
4. open the resulting document from the email when you receive it in BBEdit.
The file can be read plain text with all sorts of juicy information like
passwords, URLS, document locations, etc, all from the origionating
computer. We have been able to successfully gleam passwords and logins
from the file, IN PLAIN TEXT. It contains information that is MONTHS old
from the orginating computer.
This was tested only on the Macintosh version of Word 98, and the emails
were sent via Eudora.
NOTE: This is not specifically an email problem. If you open the saved
document on your harddrive - you get the same results!
Could someone please confim this problem occurs on a PC as well.
Microsoft has not yet been notified (hopfully they are on the list :)
It seems (not that I know too much about this sort of thing) that when the
word document is saved, for some reason it is grabbing buffer informtion
from the computer to fill up space in the file. I guess you can figure out
what kind of insecurity this could be!!!!
Cheers
Mike
--------------------------------------------------
| Mike Morton DXStorm Geek Team Leader |
| |
| mike@dxstorm.com | DXShop ...Open For Business! |
--------------------------------------------------
| Quality Developers of Above Quality Solutions |
| http://www.dxshop.com |
--------------------------------------------------
------------------------------
Date: Fri, 19 Jun 1998 12:42:46 -0700
From: Bela Lubkin
Subject: Re: Security problems on SCO's lp subsystem
Thanks to Marco Paganini & Michael L. Wilkerson Jr. for this report.
I've verified these two problems. Note that both of them require
special enabling conditions, which I describe below.
SCO OpenServer includes two spooling subsystems: the System V spooler
and the Berkeley spooler. Berkeley spooler support is split into client
and server support. By default, only SysV client support is active.
Berkeley client support is activated by root running `mkdev rlp`; or
through `scoadmin printer manager` (I haven't tested, but I believe the
option is "Printer -> Add Remote -> UNIX...").
Activating Berkeley client support causes certain binaries to change;
for instance, /usr/bin/lp changes from:
---x--s--x 1 bin lp 91044 Dec 16 1997 /usr/bin/lp
to:
---x--x--x 1 bin lp 2472 Jun 19 11:09 /usr/bin/lp
Exact dates and sizes will vary by release, but the general pattern will
be the same. The Berkeley client version is a simple wrapper program
which actually execs /usr/lpd/remote/lp:
-rws--s--x 1 root daemon 36116 Dec 16 1997 /usr/lpd/remote/lp
If a Berkeley client destination hasn't been specified, that in turn
execs the original SysV lp client, which has been saved aside in
/usr/lpd/local:
---x--s--x 1 bin lp 91044 Jun 19 11:09 /usr/lpd/local/lp
Also, in general, /etc/printcap will exist if and only if Berkeley
client support has ever been activated.
Both of these exploits require Berkeley client support to be active,
although the details are different.
#1:
> SCO 5.0.4 Enterprise
> (also) Plain Vanilla Intel
>
> as root...
> echo "test" > /tmp/rootfile
>
> and the perms thereof are...
>
> drwxrwxrwt 2 sys sys 1024 Jun 18 20:26 tmp
>
> and
>
> -rw-rw-r-- 1 root sys 5 Jun 18 20:26 rootfile
>
> okay. now as a normal, unprivileged user, I run...
>
> lpr -d lp -R /tmp/rootfile
>
> ...and to my displeasure, but as expected, the root-owned tempfile is
> removed. (BTW, this normal user is NOT a member of the group, sys --of course).
This exploit only works if the destination is a Berkeley lpd client. In
practice this means that (1) /etc/printcap must exist, (2) it must have
an entry for the destination ("-d lp"), and (3) the spool directory
mentioned in the printcap entry must exist. These conditions normally
exist only if Berkeley client support has deliberately been activated by
root.
#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.
>
> One more time!
>
> running "touch /var/spool/lpd/lock"
> yields:
> -rw-rw-r-- 1 root sys 0 Jun 18 20:41 /var/spool/lpd/lock
>
> ...now as the same normal user I run (with rootfile being an as of yet
> non-existing file)
>
> lp -L live=/tmp/rootfile
>
> Okay, then I enter whatever text I choose...and a ^D and bingo!
> now "ls -l /tmp/rootfile" yields:
> -rw------- 1 root lp 21 Jun 18 20:45 rootfile
>
> Of course, the same normal user which created the file can now not even read it.
Again, this depends on the Berkeley client support being enabled.
The actual "-L=live" support is in the SysV client. However, it looks
for a file (/usr/spool/lpd/lock -- /var/spool is a symlink to
/usr/spool) which exists only when the Berkeley client is enabled.
Specifically, the directory /usr/spool/lpd is created by the Berkeley
client install; and /usr/spool/lpd/lock is created temporarily by
Berkeley client actions. The permissions on /usr/spool don't allow
users to create subdirectories; and /usr/spool/lpd's permissions do not
allow users to create the lock file, except as a temporary byproduct of
client actions.
Even if you deliberately create /usr/spool/lpd/lock while the Berkeley
client isn't enabled:
# mkdir /usr/spool/lpd
# touch /usr/spool/lpd/lock
`lp -L live=filename` can only attack files writable by group "lp". The
root attack works because of the changed flow of control when Berkeley
client support is enabled. /usr/bin/lp execs /usr/lpd/remote/lp,
gaining setuid-root privileges. That then execs /usr/lpd/local/lp,
which is the original SysV lp client.
I would summarize these bugs as:
1. Berkeley `lp` client doesn't give up setuid/setgid privileges when
removing a file according to "-R" flag.
2. Berkeley `lp` client passes on setuid/setgid privileges to SysV
`lp` client, when a Berkeley lpd destination hasn't been specified.
3. SysV `lp` client doesn't give up setuid/setgid privileges before
opening target file for "-L live=file" flag.
4. "-L live=file" flag appears to be archaic, perhaps shouldn't exist
at all?
Not a pretty picture. I'll look into getting these fixed, and checking
for other related issues in these subsystems.
>Bela<
------------------------------
Date: Thu, 18 Jun 1998 13:24:46 -0700
From: Il Oh
Subject: protocol 191 clarification
I've received a number of messages telling me that it's Prospero Directory
Service. I should clarify that I didn't mean port 191. It was protocol
191, like how protocol 6 is TCP and 17 is UDP.
------------------------------
Date: Fri, 19 Jun 1998 14:19:31 -0700
From: Bela Lubkin
Subject: Re: Security problems on SCO's lp subsystem
I forgot to explicitly state the perhaps-obvious workaround: do not
enable the Berkeley lpd client. It should be sufficient to move aside
/etc/printcap and /usr/spool/lpd, then run `mkdev rlp`, tell it to
"remove remote printing". The SysV spooler can do remote printing with
any available remote command processor (rcmd (nee rsh), etc.), which
could be used to shunt jobs to a different system's lpd client.
I'm working on fixes for the whole mess.
>Bela<
------------------------------
Date: Fri, 19 Jun 1998 13:06:42 -0600
From: Pete Ashdown
Subject: Solaris 2.5.1 patch not effective?
Tom Perrine said once upon a time:
>At least one of the sites reports that patch 104490-05 (Solaris 2.5.1,
>sparc arch) was applied on a system that was compromised (presumably
>via this method).
The 2.5.1 system that I just reported success with the exploit had
104490-05 applied.
------------------------------
Date: Thu, 18 Jun 1998 15:27:54 -0500
From: Kevin Day
Subject: Re: 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...
>
I'm seeing 200-5000 packets a day, either with the source 0 or the dest 0.
They're usually source 0, then a well-known port #... (sendmail, named,
whatever). Nothing has crashed yet, and I haven't seen any exploits, or any
trace of an exploit yet. At first I just logged the packets, now i'm
dropping them, since apparently people *think* they can crash something with
it.
Also, for those interested in what attempted exploits are being used most
often...
In a 7 day period:
3171 packets with a source address of one of my class C's.
12 packets from the 10.x.x.x reserved ranges
732 packets from 172. reserved ranges
56 packets from 192.168.x.x reserved ranged
18 packets with a destination address of x.x.x.255
3 packets with a destination address of x.x.x.0
3095 packets to port 139, when there's no reason for anyone to connect
there.
4390 packets with a source port 0
204 packets with a destination port 0
431 packets to port 111, when there's not reason for anyone to connect
there.
I'm leaving out other stuff i'm filtering, so I don't give the entire world
my list of filters, but it's interesting...
Kevin
------------------------------
Date: Thu, 18 Jun 1998 23:29:09 +0200
From: frank@SUN01.CCII.UNIPI.IT
Subject: Re: another remote pine vunerability
On Thu, 18 Jun 1998, Phillip R. Jaenke wrote:
>
> 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.
I just downloaded this message with fetchmail, so I assume it isn't
affected by the same bug of popclient.
afrodite[40]:~> fetchmail -V
This is fetchmail release 3.8 pl 0
regards.
Francesco Messineo frank@ing.unipi.it
PGP public key: http://sirius.ccii.unipi.it/~frank/public.asc
KeyID 1024/2937E1A5
Key fingerprint = 5B 41 DC 7C 06 90 29 CA 39 05 59 F5 B3 CC 9A 9D
------------------------------
Date: Fri, 19 Jun 1998 10:16:09 -0600
From: Theo de Raadt
Subject: Re: Re : Bind 4.9.6 ~ Current | X86 Exploit
> Solution : static named compilation & chrooted execution.
The next openbsd release will ship with a chrooted named environment
as part of the system by default. If you enable named, it will go into
it's chroot space, and revoke it's priviledges.
i don't trust that code.
------------------------------
Date: Fri, 19 Jun 1998 08:31:53 -0400
From: Ken Williams
Subject: talkd vulnerability in patched RH 5.0?
hi,
while engaged in a talk session with a local user on an RH 5.0 box with
2.0.34 kernel that has all recommended patches, the user was able to
execute a command in my cwd. he executed a '\rm *' command in another
xterm window and then inadvertently pasted the command into the xterm
running the talk session just as i '-C'ed' out of the talk session.
all of the files in my cwd were rm'ed. i looked through all of my
.history files and could not find any command executed on my end.
btw, i checked the bugtraq archives and redhat.com, and read about the
long history of talkd vulnerabilities and security risks, but did not see
anything specifically about this event with patched RH 5.0. sorry if this
post happens to be irrelevant or old news.
Ken Williams
VP of E.H.A.P. Corp. http://www.ehap.org/ ehap@ehap.org, tattoo@ehap.org
Packet Storm Security http://www.Genocide2600.com/~tattooman/index.shtml
NC State Comp Sci Dept http://www4.ncsu.edu/~jkwilli2/
PGP DSS & RSA Keys: http://www.genocide2600.com/cgi-bin/finger?tattooman
------------------------------
Date: Thu, 18 Jun 1998 18:07:23 -0400
From: Olivier Crete
Subject: Re: another remote pine vunerability
>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.
>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.
I had the same problem using fetchpop with procmail.
Olivier Crete
tester@videotron.ca
Sillery, Canada
------------------------------
Date: Thu, 18 Jun 1998 18:39:39 -0500
From: "Jason H. Reeves"
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:
I tried this on pine 3.96 on Solaris 2.5.1 and had no problems. I
used your bogus address, put it as the From: field in a bogus test
message, and appended it to /var/mail/jhr and tried to read it. I read it
without any problems.
----------------------------------------------------------------------------><>
Jason H. Reeves (KC5TTQ) jason.reeves@mail.state.ar.us
Arkansas Department of Information Systems Little Rock, AR
<><----------------------------------------------------------------------------
------------------------------
Date: Fri, 19 Jun 1998 08:35:08 +0200
From: Joan Garcia i Silano
Subject: Re: another remote pine vunerability
On Wed, 17 Jun 1998, Michal Zalewski wrote:
> From: Michal Zalewski
> ....and any attempt of reading this mail will cause:
>
> Program received signal SIGSEGV, Segmentation fault.
And when you try to take the address from the e-mail it crashes too.
So don't press "t" in this e-mail :-)
Joan
( )( )________ Joan Garcia i Silano
/OO \ _ URL: http://personal.redestb.es/joangs
O_\\--mm---mm /______) PGP: http://personal.redestb.es/joangs/pgp
------------------------------
End of BUGTRAQ Digest - 18 Jun 1998 to 19 Jun 1998
**************************************************