Date: Fri, 3 Jul 1998 00:02:35 -0400
Reply-To: Bugtraq List
Sender: Bugtraq List
From: Automatic digest processor
Subject: BUGTRAQ Digest - 1 Jul 1998 to 2 Jul 1998
To: Recipients of BUGTRAQ digests
Message-Id: <19980703040448Z96670-522+9@brimstone.netspace.org>
There are 21 messages totalling 1429 lines in this issue.
Topics of the day:
1. qpopper 2.51
2. Sun libnsl lameness (2)
3. Alert: Microsoft Security Notification service
4. ASP vulnerability with Alternate Data Streams
5. RSI.0005.05-14-98.SUN.LIBNSL (w/ errata)
6. Serious Linux 2.0.34 security problem
7. 1998 USENIX Annual Technical Conference - Call for Papers
8. Port 0 oddities (3)
9. Security vulnerabilities in Win Servers
10. Qpopper
11. ircd 2.9.5 & ircii-pana DNS problems (2)
12. pop_msg in debian/qpopper: core, but no exploit
13. Alert: ASP vulnerability with Alternate Data Streams
14. ::$DATA ISAPI filter
15. qpopper2.52 (2)
16. SECURITY: redhat, the saga continues..
----------------------------------------------------------------------
Date: Wed, 1 Jul 1998 17:31:45 -0700
From: Praveen Yaramada
Subject: Re: qpopper 2.51
We were having some problems with our external ftp servers since Tuesday.
But as of now I was informed the problem is resolved.
The URL should hold good.
Meanwhile we have fixed some compile problems in 2.51 and made it 2.52
Regards
Praveen.
At 01:48 PM 7/1/98 -0700, Jean Chouanard wrote:
>Well... Qualcomm seems to continue to move stuff around :
>ftp://ftp.qualcomm.com/eudora/servers/unix/popper/qpopper2.51.tar.Z could
>not be found on there server but
>ftp://ftp.qualcomm.com/eudora/servers/unix/popper/qpopper2.5.tar.Z is dated
>from the 1 June but is the 2.5 version wo/ the latest fixes/changes.
>
>Does anyone from Qualcomm could confirm the state of there popper server
>*and* the state of there public ftp server?
>
>
>
>At 11:04 AM 7/1/98 -0500, someone using Aleph One's login wrote:
>>Well, it seems Qualcomm was moving stuff around last night. There is a
>>new version of qpopper out. It fixes the bulletins bug and changes the
>>licensing.
>>
>>ftp://ftp.qualcomm.com/eudora/servers/unix/popper/qpopper2.51.tar.Z
>>
>>Aleph One / aleph1@dfw.net
>>http://underground.org/
>>KeyID 1024/948FD6B5
>>Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01
>>
> - jean -
>
------------------------------
Date: Wed, 1 Jul 1998 16:41:58 PDT
From: George Clooney
Subject: Sun libnsl lameness
So, why am I disgruntled? My company recently signed on for RSI's
Member Services. This entitled us to some "unreleased" security
information that had been submitted to vendors and members only.
One advisory in particular dealt with a HUGE problem in libnsl on
various Sun platforms. Subsequently, when we took a look at our own
systems and we realized that our entire network had been owned via this
vulnerability, backdoored, you name it - we were fucked. It's taken a
lot of time to get us back to the point where I can run the networks and
stop worrying about all these security problems that should have been
patched long ago.
I don't fault RSI for this - I'm happy they made us aware of these
problems so long ago. It's just too bad Sun has chosen to ignore them.
I find it absolutely PATHETIC that a company of Sun's size and
resources, who has had the fucking information for almost 2 months,
cannot produce a patch more quickly for a problem of this magnitude.
So, despite my companies agreement with RSI, I am releasing the
information anonymously. Oh, did I forget to tell you that this is not
the only problem Sun is sitting on? I'm hoping with this public
disclosure it will force Sun to throw more resources at the problem(s).
Assholes.
Extremely Disgruntled Sun Admin.
RSI.0003.05-14-98.SUN.LIBNSL
|:::. |::::: |::::. |::::: |::::: |::::.
.. :: .. .. :: .. .. .. ::
|:::: |:::: |:::: :::::: |::::: |:::: |:
|: :: |: |: |:: |: |: ::
|: :: |::::: |: |::::: |::::: |:::::
Repent Security Incorporated, RSI
[ http://www.repsec.com ]
*** RSI ALERT ADVISORY ***
--- [CREDIT] -------------------------------------------------------
Matt Conover: Discovered the vulnerabilities
Mark Zielinski: Author of advisory
---[SUMMARY]--------------------------------------------------------
Announced: May 14, 1998
Report code: RSI.0003.05-14-98.SUN.LIBNSL
Report title: Sun Microsystem's libnsl
Vulnerability: Insufficient bounds checking
Vendor status: Contacted, patch supplied
Patch status: Awaiting patch from Sun Microsystem's
Platforms: Solaris 2.2, 2.3, 2.4, 2.5.1
Vulnerable: Several library functions in libnsl have buffer
overflows
Reference: http://www.repsec.com/advisories.html
Impact: If exploited, an attacker could potentially compromise
both local and remote root access on your server
--- [DETAILS] --------------------------------------------------------
Problem: Several buffer overflows exist in Sun Microsystem's
libnslnetworking library.
While overwriting the buffer, the attacker can
manipulate the stack and execute their own commands,
possibly gaining root access on your server.
Functions we have found vulnerable:
Vulnerable key functions
---------------------------------------------------
extract_secret () : Buffer overflows while
copyingdata into a local
buffer
getkeys_nis () : Buffer overflows if key value
is larger then the buffer
getpublickey () : Calls getkeys_nis ()
getsecretkey () : Calls getkeys_nis ()
Vulnerable RPC functions
----------------------------------------------------
authdes_seccreate () : Calls getpublickey ()
rpc_broadcast_exp () : Buffer overflow if allowed to
specify network protocol type
rpc_broadcast () : Calls rpc_broadcast_exp ()
clnt_create_timed () : Buffer overflow if allowed to
specify network protocol type
host2netname () : Buffer overflow while
specifying hostname.
getnetname () : Calls host2netname ()
clnt_create () : Calls clnt_create_timed ()
rpc_call () : Buffer overflow if allowed to
specify network protocol type
authdes_pk_seccreate () : Calls getnetname ()
Vulnerable NIS functions
----------------------------------------------------
__nis_init_callback () : Calls getpublickey ()
__nis_core_lookup () : Buffer overflow while copying
paramaters into a local
buffer
nis_make_rpchandle () : Calls host2netname ()
nis_dump_r () : Calls nis_make_rpchandle ()
nis_dump () : Calls nis_dump_r ()
__nis_auth2princ () : Buffer overflow while
specifying machine name
__nis_host2nis_server (): Buffer overflow while
specifyinghostname
nis_name_of_r () : Buffer overflow while copying
paramaters into a local
buffer
nis_old_data_r () : Buffer overflow while copying
paramaters into a local
buffer
nis_list () : Calls __nis_core_lookup ()
nis_add () : Calls nis_nameops ()
nis_remove () : Calls nis_nameops ()
nis_modify () : Calls nis_nameops ()
nis_mkdir () : Calls nis_make_rpchandle ()
nis_rmdir () : Calls nis_make_rpchandle ()
Potentially vulnerable programs
----------------------------------------------------
Calls vulnerable RPC functions:
1. nfs mount
2. nfs share
3. rpc.rexd
4. autofs
Calls vulnerable key functions:
1. chkey
2. keylogin
3. setkey
4. newkey
5. keyserv
6. libscheme
Calls vulnerable NIS functions:
1. rpc.nisd
2. rpc.nisdpasswdd
3. nisping
4. nisaddent
5. nisupdkeys
6. nisaddcred
7. sendmail
8. volcheck
9. vold
Calls vulnerable YP functions:
1. vacation
2. ypwhich
3. yppush
These vulnerabilities are present in Sun Microsystem's
Solaris 2.2, 2.3, 2.4 and 2.5.1.
For more information on this type of attack, point your
web browsers to http://www.repsec.com/bofs.html.
--- [FIX] ------------------------------------------------------------
Solution: Refer to the PATCH section.
--- [PATCH] ----------------------------------------------------------
Solution: Wait until Sun Microsystem's can release a official
patch.
----------------------------------------------------------------------
Snail Mail:
Repent Security Incorporated (RSI)
advise@repsec.com
13610 N. Scottsdale Rd.
Suite #10-326
Scottsdale, AZ
85254
[ http://www.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 May 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.
RSI Member Alert Advisories are expressly prohibited from release of any
and all information contained in this advisory, in any and all forms
into the public domain by RepSec Members, their personnel, or other
related or affiliated personnel, to other advisory groups and/or other
security incident response teams (both commercial and non-commercial) -
during the period RSI Member Alert Advisories are released to RSI
Member's only. The material in this advisory alert may be reproduced
and distributed, without permission, only after it has been released by
RepSec, Inc. into the public domain. After release by RepSec, Inc. into
the public domain the material in this RSI Member Alert Advisory may be
reproduced and distributed, without permission in its entirety only,
provided the copyright is kept intact and due credit is given to RepSec,
Inc.
Subject to the timing of release restrictions above, this RSI Advisory
Alert 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.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
------------------------------
Date: Wed, 1 Jul 1998 21:38:09 -0500
From: Aleph One
Subject: Re: Alert: Microsoft Security Notification service
---------- Forwarded message ----------
Date: Wed, 1 Jul 1998 22:30:57 -0400
From: Russ
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: Re: Alert: Microsoft Security Notification service
First, a clarification to the "Disable READ Access" workaround
statement.
You can prevent the ASP's from being viewed by disabling READ access
within MMC for the ASPs. If you disable READ access for your entire site
(or all files, like .gif, .htm, .etc) then those files will not be
displayed at all.
ASPs need execute only, all non-executing files need READ access to
display normally.
Second, Microsoft have been notified. Expect a fix announcement shortly.
Third, I was able to talk to Bob Denny (author of O'Reilly's WebSite
Pro), it is not affected by this exploit. I was not able to find a
contact at Netscape to ask.
Cheers,
Russ
------------------------------
Date: Wed, 1 Jul 1998 21:37:29 -0500
From: Aleph One
Subject: ASP vulnerability with Alternate Data Streams
---------- Forwarded message ----------
Date: Tue, 30 Jun 1998 15:27:32 +0200
From: Paul Ashton
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: ASP vulnerability with Alternate Data Streams
Following on from the last .asp vulnerability which applied to
URLs ending in spaces, and the previous that allowed .asps to
be read if they end in ".", it turns out that there is yet
another due to Alternate data streams.
The unnamed data stream is normally accessed using the filename
itself, with further named streams accessed as filename:stream.
However, the unnamed data stream can also be accessed using
filename::$DATA.
If you open http://somewhere/something.asp::$DATA it turns out
that you will be presented with the source of the ASP instead
of the output. Deja vu?!
It is left as an exercise for the reader to thing of further
implications in other programs running on NT. Obviously,
anything that to tries to restrict access based on filename
instead of ACLs is going to have a hard time after this and
the other recent revelations.
Paul
------------------------------
Date: Wed, 1 Jul 1998 20:31:24 -0700
From: Brian Martin
Subject: RSI.0005.05-14-98.SUN.LIBNSL (w/ errata)
RSI would like to address some errata regarding the recent
post and disclosure of one of our advisories.
1. When mailed to members on 5-14-98, 'libnsl' was scheduled
to be our third release. Delays in obtaining the patch
forced it to be pushed back. As far as public releases,
'libnsl' is #0005 (reference below)
2. Sun is still working on a patch. The only 'patch' that has
been supplied is a single libnsl replacement (in binary
format) for a single version of Solaris (2.5.1). After
further testing, it appears to have fixed the problems. RSI
was waiting for an official patch for all versions before
releasing this advisory.
3. The (now) public release of #0005 (sun.libnsl) is below.
Please reference this copy. The RSI web page (www.repsec.com)
will be updated shortly to reflect the release.
Thank you.
Brian Martin
RSI
-= official advisory =-
RSI.0005.05-14-98.SUN.LIBNSL
|:::. |::::: |::::. |::::: |::::: |::::.
.. :: .. .. :: .. .. .. ::
|:::: |:::: |:::: :::::: |::::: |:::: |:
|: :: |: |: |:: |: |: ::
|: :: |::::: |: |::::: |::::: |:::::
Repent Security Incorporated, RSI
[ http://www.repsec.com ]
*** RSI ALERT ADVISORY ***
--- [CREDIT] --------------------------------------------------------------
Matt Conover: Discovered the vulnerabilities
Mark Zielinski: Author of advisory
--- [SUMMARY] -------------------------------------------------------------
Announced: May 14, 1998
Report code: RSI.0005.05-14-98.SUN.LIBNSL
Report title: Sun Microsystem's libnsl
Vulnerability: Insufficient bounds checking
Vendor status: Contacted, patch under development
Patch status: No patch available
Platforms: Solaris 2.2, 2.3, 2.4, 2.5, 2.5.1
Vulnerable: Several library functions in libnsl have buffer overflows
Reference: http://www.repsec.com/advisories.html
Impact: If exploited, an attacker could potentially compromise
both local and remote root access on your server
--- [DETAILS] -------------------------------------------------------------
Problem: Several buffer overflows exist in Sun Microsystem's libnsl
networking library.
While overwriting the buffer, the attacker can manipulate
the stack and execute their own commands, possibly gaining
root access on your server.
Functions we have found vulnerable:
Vulnerable key functions:
---------------------------------------------------
extract_secret () : Buffer overflows while copying
data into a local buffer
getkeys_nis () : Buffer overflows if key value
is larger then the buffer
getpublickey () : Calls getkeys_nis ()
getsecretkey () : Calls getkeys_nis ()
Vulnerable RPC functions:
----------------------------------------------------
authdes_seccreate () : Calls getpublickey ()
rpc_broadcast_exp () : Buffer overflow if allowed to
specify network protocol type
rpc_broadcast () : Calls rpc_broadcast_exp ()
clnt_create_timed () : Buffer overflow if allowed to
specify network protocol type
host2netname () : Buffer overflow while specifying
hostname.
getnetname () : Calls host2netname ()
clnt_create () : Calls clnt_create_timed ()
rpc_call () : Buffer overflow if allowed to
specify network protocol type
authdes_pk_seccreate () : Calls getnetname ()
Vulnerable NIS functions:
----------------------------------------------------
__nis_init_callback () : Calls getpublickey ()
__nis_core_lookup () : Buffer overflow while copying
paramaters into a local buffer
nis_make_rpchandle () : Calls host2netname ()
nis_dump_r () : Calls nis_make_rpchandle ()
nis_dump () : Calls nis_dump_r ()
__nis_auth2princ () : Buffer overflow while specifying
machine name
__nis_host2nis_server (): Buffer overflow while specifying
hostname
nis_name_of_r () : Buffer overflow while copying
paramaters into a local buffer
nis_old_data_r () : Buffer overflow while copying
paramaters into a local buffer
nis_list () : Calls __nis_core_lookup ()
nis_add () : Calls nis_nameops ()
nis_remove () : Calls nis_nameops ()
nis_modify () : Calls nis_nameops ()
nis_mkdir () : Calls nis_make_rpchandle ()
nis_rmdir () : Calls nis_make_rpchandle ()
Potentially vulnerable programs:
----------------------------------------------------
Calls vulnerable RPC functions:
1. nfs mount
2. nfs share
3. rpc.rexd
4. autofs
Calls vulnerable key functions:
1. chkey
2. keylogin
3. setkey
4. newkey
5. keyserv
6. libscheme
Calls vulnerable NIS functions:
1. rpc.nisd
2. rpc.nisdpasswdd
3. nisping
4. nisaddent
5. nisupdkeys
6. nisaddcred
7. sendmail
8. volcheck
9. vold
Calls vulnerable YP functions:
1. vacation
2. ypwhich
3. yppush
These vulnerabilities are present in Sun Microsystem's
Solaris 2.2, 2.3, 2.4, 2.5, and 2.5.1.
For more information on this type of attack, point your
web browsers to http://www.repsec.com/bofs.html.
--- [FIX] -----------------------------------------------------------------
Solution: No fix available.
--- [PATCH] ---------------------------------------------------------------
Solution: Sun Microsystem's has not released an official patch.
---------------------------------------------------------------------------
Repent Security Incorporated (RSI)
advise@repsec.com
13610 N. Scottsdale Rd.
Suite #10-326
Scottsdale, AZ
85254
[ http://www.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 May 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: Wed, 1 Jul 1998 17:07:15 +0100
From: Alan Cox
Subject: Re: Serious Linux 2.0.34 security problem
> > fcntl(0,F_SETOWN,p);
> > s = fcntl(0,F_GETFL,0);
> > fcntl(0,F_SETFL,s|O_ASYNC);
> > printf("Sending SIGIO - press enter.\n");
> > getchar();
> > fcntl(0,F_SETFL,s&~O_ASYNC);
> > printf("SIGIO send attempted.\n");
> > return 0;
> > }
>
> Well, that looks like one of the class of security problems described
> by www.openbsd.org/advisories/signals. Hasn't anyone else fixed those
> problems yet?
Of course Theo if you actually bothered to look back at the Linux sources
you'd see thats an error that crept in and we had SIGIO right way before
the old advisories that predate OpenBSD.
Alan
------------------------------
Date: Wed, 1 Jul 1998 10:14:18 -0700
From: Jackson Dodd
Subject: 1998 USENIX Annual Technical Conference - Call for Papers
USENIX 1999 Annual Technical Conference
June 7-11, 1999
Monterey Conference Center
Monterey, California, USA
For the full call for submissions, see
http://www.usenix.org/events/usenix99
Papers due: December 2, 1998
Author notification: January 20, 1999
Camera-ready final papers due: April 27, 1999
Registration materials available: March, 1999
The 1999 USENIX Technical Conference Program Committee seeks
original and innovative papers about the applications, architecture,
implementation, and performance of modern computing systems.
As at all USENIX conferences, papers that analyze problem areas
and draw important conclusions from practical experience are
especially welcome. Some particularly interesting application
topics are:
Availability
Distributed caching and replication
Embedded systems
Extensible operating systems
File systems and storage systems
Interoperability of heterogeneous systems
Mobile code
Mobile computing
Multimedia
New algorithms and applications
Personal digital assistants
Quality of service
Reliability
Security and privacy
Ubiquitous computing and messaging
Web technologies
TUTORIALS
We are also accepting proposals for tutorials. USENIX's well-respected
tutorial program offers intensive, immediately practical tutorials on
topics essential to the use, development, and administration of advanced
computing systems. Skilled instructors, who are hands-on experts in
their topic areas, present both introductory and advanced tutorials
covering topics such as:
System and network administration
Java and Perl topics
High availability, scalability, and reliability
Programming tools and program development
Portability and interoperability
System and network security
Client-server application design and development
Sendmail, DNS, and other networking issues
GUI technologies and builders
WWW and CGI technologies
Performance monitoring and tuning
Freely distributable software
INVITED TALKS
The Invited Talks coordinators welcome suggestions for topics and
requests proposals for particular talks. In your proposal state
the main focus, include a brief outline, and be sure to emphasize
why your topic is of general interest to our community. Please submit
via email to ITusenix@usenix.org.
For the full call for submissions, see
http://www.usenix.org/events/usenix99
====================================================================
USENIX is the Advanced Computing Systems Association. Since 1975,
USENIX has brought together the community of engineers, system
administrators, and technicians working on the cutting edge of the
computing world. For more information about USENIX:
1. URL: http://www.usenix.org
2. Email to office@usenix.org
3. Fax: 510.548.5738
4. Phone: 510.528.8649
------------------------------
Date: Wed, 1 Jul 1998 18:04:28 +0100
From: Simon Halsall
Subject: Re: Port 0 oddities
I've been off bugtraq for a couple of weeks but I just saw these messages. I
have recently been putting logging into our cisco's rule set so that I can see
what traffic is being passed through our network. I spotted traffic that
appeared to be missed by the rules as it had src port 0 and dst port 0.
Further investigation showed that it was ssh that was causing this. I have
looked at the packets using tcpdump and they look find and what I would expect
but the cisco is still reporting packets from 0 to 0.
I will trawl back through the logs to find out if we have had any other
anomalies with port 0 before but I don't recall any. The rules for allowing
port 22 through seem to work fine for the initial connect but then it over to
port 0. We are using IOS 11.2. Anyone else seen anythin odd like this ?
Simon Halsall
In message <199806182027.PAA04739@home.dragondata.com>,
Kevin Day writes:
> > 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: Wed, 1 Jul 1998 10:19:02 -0700
From: Nicholas Blasgen
Subject: Re: Security vulnerabilities in Win Servers
Not sure if it was mentioned, but Commerce Builder for Windows 95/NT is also
vulnerable to the Win Server problem. It was said before that only Netscape
and O'Reilly were affected by this problem. I have now noticed I-Factory's
Commerce Bulder, and probaly Mechant Builder.
Nicholas Blasgen
www.refract.com
------------------------------
Date: Wed, 1 Jul 1998 19:11:42 -0700
From: digi
Subject: Qpopper
Today, qpopper 2.52 was installed on saturn. (our primary server). Later
today, it was compromised, the intruders claimed to of used that to gain
root access. Neither of the intruders had access to the system before they
attempted to compromise it, I didnt see any message saying that only one
specific version was patched, so a coworker assumed that it was patched
and installed it. Either 2.52 is insecure, or the intruders are lying.
-- Brian Hourigan
------------------------------
Date: Tue, 30 Jun 1998 13:22:34 +0200
From: Michal Zalewski
Subject: ircd 2.9.5 & ircii-pana DNS problems
--- PREFACE ---
About month ago, I found interesting problem with ircd up to 2.9.5 (I
haven't newer versions). This bug (?) partially affects irc clients,
including nice NULL-pointer fault in BitchX-74p4 (latest release)...
But, let's start from the beginning:
RFC 1035, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION":
[...]
The labels must follow the rules for ARPANET host names. They must
start with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen. There are also some
restrictions on the length. Labels must be 63 characters or less.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The same sentence can be found in RFC 1034, "DOMAIN NAMES - CONCEPTS AND
FACILITIES", and, in fact, 63 characters are host name limit for modern
systems. Unfortunately, ircd is 'not quite' able to handle 63-characters
long hostname.
-- IRCD IMPACT --
You need access to your domain name server to create 63-chars long host
name. Please, check twice if it's extactly 63-chars long, including dots
abnd domain name. NOTE: Setting an alias for your machine won't work. You
should modify primary host name.
Now, propagation of your new host name could take a longer period of time
(usually less than one week) - of course if you're testing ircd outside
your own domain.
When everything is done, you can try to enter IRC from prepared machine.
You'll notice something really funny - ircd crops your real name, hostname
and ident! Typical '/whois nick' should return something like that:
/whois lcamtuf
*** on irc via server genome.ml.org (Genome IRC Server)
*** lcamtuf has been idle 26 seconds
Username and host mask has been stripped by ircd! Pretty nice bug. But
(of course!) that's not all. Other irc users can't guess who are you, ban
you from their channel, nor do anything else, because there's no way to
obtain required informations about your connection. Even /who #channel
returns just a nice junk instead of useful data ('never named...' is my
REALNAME):
#test H@ 0 never@named... (~lcamtuf genome.ml.org lcamtuf )
And now, the game begins...
-- BITCHX IMPACT --
That's probably the most interesting thing. When my test session joined
channel, BitchX (popular irc client by panasync) left irc with
following message from ircd:
*** Signoff: lcamtuf (Read error to lcamtuf[]: EOF from client)
But what happened? That's how it looks from BitchX client's side (gdb
output):
Program received signal SIGSEGV, Segmentation fault.
0x80d2a16 in find_bestmatch ()
Useful stack info:
(gdb) info stack
#0 0x80d2a16 in find_bestmatch ()
#1 0x80d5167 in lookup_userlevelc ()
#2 0x80b55af in add_to_channel ()
#3 0x80c3893 in whoreply ()
#4 0x80c571f in parse_server ()
#5 0x80ca8c9 in do_server ()
#6 0x80a584f in io ()
#7 0x80a5492 in get_line ()
#8 0x80a5ca7 in main ()
Hmm, I'm guessing BitchX dies due to the NULL-pointer when trying to
determine my host name (and user level).
-- VUNERABLE PLATFORMS --
I tested it only on Linux in my local network, because I have no access to
other nameservers, but it seems to be reproductable.
-- FIX --
Nope yet (?).
_______________________________________________________________________
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, 2 Jul 1998 00:44:20 -0500
From: nicholas harteau
Subject: Re: Sun libnsl lameness
it should be noted that ssh and sshd make use of insecure functions as
mentioned below.
[root@squig ~/work/ssh/ssh-1.2.25] nm sshd | egrep 'getnetname|getsecretkey'
[428] | 372268| 0|FUNC |GLOB |0 |UNDEF |getnetname
[527] | 372280| 0|FUNC |GLOB |0 |UNDEF |getsecretkey
[root@squig ~/work/ssh/ssh-1.2.25] nm ssh | grep getnetname
[416] | 356736| 0|FUNC |GLOB |0 |UNDEF |getnetname
George Clooney wrote:
> Functions we have found vulnerable:
>
> Vulnerable key functions
> ---------------------------------------------------
> getsecretkey () : Calls getkeys_nis ()
>
>
> Vulnerable RPC functions
> ----------------------------------------------------
> getnetname () : Calls host2netname ()
--
nicholas harteau
nrh@sfx.com
------------------------------
Date: Thu, 2 Jul 1998 13:57:44 +0200
From: Herbert Rosmanith
Subject: pop_msg in debian/qpopper: core, but no exploit
dear listmembers,
I was curious that debian-popper-2.2 seemed immune to the buffer overflow
in pop_msg(), and I think I've found the reason why. It's not the
function which is handling the overflow correctly, but vsprint(), which,
allthough it *does* overflow the buffer, it does not overflow it far enough
to overwrite the return address as intended.
vsprint() will overflow the buffer and the other stack-variables *and*
even the return adress, but 1) not very much further than that (regardless
of your buffer size) and 2) will only partially overwrite the return
address with the buffer. popper/debian will, however, still coredump.
e.g.: 2k overflow buffer, filled with 0x90919293
pop_msg()
804ccb0: 55 pushl %ebp
804ccb1: 89 e5 movl %esp,%ebp
esp 0xbfffef00 0xbfffef00
after vsprintf:
(gdb) x/x 0xbfffeefc
0xbfffeefc <__ypbindlist+2146652752>: 0x93909192
0xbfffef00 <__ypbindlist+2146652756>: 0x22409192
^^^^
0xbfffef04 <__ypbindlist+2146652760>: 0xbfff002e
^^^^
so you can only overwrite the last 2 byte of the return address,
specifying an offset of 64k with 0x2240XXXX, an address not accessible.
the 40222e00 sequence is the end of the "-ERR Unknown..." string: @".
so it seems, that vsprintf() under debian has some kind of boundary check,
and allthough it will still corrupt the return address, but render any
attempt to overwrite to a specific value useless.
can anyone confirm that ?
regards,
h.rosmanith
------------------------------
Date: Thu, 2 Jul 1998 10:22:23 -0500
From: Aleph One
Subject: Alert: ASP vulnerability with Alternate Data Streams
---------- Forwarded message ----------
Date: Thu, 2 Jul 1998 10:14:58 -0400
From: Russ
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: Alert: ASP vulnerability with Alternate Data Streams
We've had a number of questions and possible solutions suggested in the
past few hours, let me try and summarize.
1. Several people noted that enabling extensions with "::$DATA" added,
i.e. ".asp::$DATA", would cause them to be executed instead of read.
This does work, and is faster than removing READ access from all of the
files you are concerned about. I would still recommend removing READ
access as a matter of course. (credit Somer Bozyel)
2. Someone asked whether or not anything other than $DATA would work.
The only "pre-defined" stream available on any file is the
::$INFORMATION_SECURITY stream. This does not seem to yield any results
when appended to a URL. Other streams might work, but then they would
have to be defined by the person owning the server, and only they would
know the stream names (unless you could remotely execute March's stream
display program).
3. Secondly, a number of people are reporting sites that seem to be
unaffected. There may be a couple of reasons a site appears to be
unaffected (I haven't received a link yet that I couldn't exploit, aside
from http://www.ntbugtraq.com which I fixed up late last night).
Depending on where the ASP code is in the page, a site may appear to
display normally (or almost normally). That's because the HTML is being
interpreted and display while the asp is being quelched due to its
enclosing tags. If you do a "View Source" on such a page, you may very
well see the entire ASP.
If a site really is unaffected then its due to the READ permissions not
being enabled (or they've added the extension with "::$DATA" to their
scriptmappings).
4. Put all executables into a separate directory and make that directory
READ disabled. This may make it easier to know what's at risk, but it
may not be easy to change the location of some files. (credit
jasonw@THECRIB.COM & dave@DATACASH.COM)
5. Cold Fusion .CFM files are visible also, but when READ disabled they
do execute properly, so make sure you consider all forms of executables
and not just ASPs (credit Arron )
Note: I've left Paul's original message attached because it didn't go
out with an "Alert:" at the beginning of the subject line, meaning some
list members did not see it.
Cheers,
Russ - NTBugtraq moderator
-----Original Message-----
From: Paul Ashton [mailto:paul@ARGO.DEMON.CO.UK]
Sent: Tuesday, June 30, 1998 9:28 AM
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: ASP vulnerability with Alternate Data Streams
Following on from the last .asp vulnerability which applied to
URLs ending in spaces, and the previous that allowed .asps to
be read if they end in ".", it turns out that there is yet
another due to Alternate data streams.
The unnamed data stream is normally accessed using the filename
itself, with further named streams accessed as filename:stream.
However, the unnamed data stream can also be accessed using
filename::$DATA.
If you open http://somewhere/something.asp::$DATA it turns out
that you will be presented with the source of the ASP instead
of the output. Deja vu?!
It is left as an exercise for the reader to thing of further
implications in other programs running on NT. Obviously,
anything that to tries to restrict access based on filename
instead of ACLs is going to have a hard time after this and
the other recent revelations.
Paul
------------------------------
Date: Thu, 2 Jul 1998 11:04:48 -0500
From: Aleph One
Subject: ::$DATA ISAPI filter
Christoph Wille from Sofwing has graciously
made available an IIS ISAPI filter that will protect a site from the
::$DATA vulnerability. You can find if at
http://www.softwing.com/iisdev/ddatafix/
BTW, this probably does not only affect IIS.
Aleph One / aleph1@dfw.net
http://underground.org/
KeyID 1024/948FD6B5
Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01
------------------------------
Date: Thu, 2 Jul 1998 13:53:59 -0400
From: Valdis.Kletnieks@VT.EDU
Subject: Re: ircd 2.9.5 & ircii-pana DNS problems
--==_Exmh_1954031104P
Content-Type: text/plain; charset=us-ascii
On Tue, 30 Jun 1998 13:22:34 +0200, you said:
> RFC 1035, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION":
>
> [...]
> The labels must follow the rules for ARPANET host names. They must
> start with a letter, end with a letter or digit, and have as interior
> characters only letters, digits, and hyphen. There are also some
> restrictions on the length. Labels must be 63 characters or less.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
As amended by RFC1123, section 2.1:
Host software MUST handle host names of up to 63 characters and
SHOULD handle host names of up to 255 characters.
So if you're dicking with the code, make sure you get the limit *right*. ;)
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
--==_Exmh_1954031104P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBNZvJNtQBOOoptg9JAQHWwAP/eVao4t25iJzEO6NSTLgUM9vMEBUu90kk
29ta7Wq5uzXgZPzMsGTn0IfFH22qbNtkqqoMCjKlAVlqDlJC2FVUVS15fNdWoZaG
cvEOIAIKTEpGW1MKwQ+7HJBbHwboEeXkEkeFfJkw7+mvl7fkHS2EJapkdCPbDLCq
pe7YsuPVG1Q=
=GyV8
-----END PGP MESSAGE-----
--==_Exmh_1954031104P--
------------------------------
Date: Thu, 2 Jul 1998 12:51:50 -0400
From: Alan J Rosenthal
Subject: qpopper2.52
While diffing the new qpopper distribution with my own modified
qpopper2.41beta directory, I found something interesting in pop_uidl.c
-- interesting to me at least, hopefully y'all on the list will assure me
that it is not, in fact, interesting. I had modified my 2.41beta directory
in accordance with hints on this list, and the diffs found overflow checks
missing in the new pop_uidl.c:
diff -rs qpopper2.41beta1/pop_uidl.c qpopper2.5/pop_uidl.c
60c60
< sprintf(buffer, "%d %.900s", msg_id, mp->uidl_str);
---
> sprintf(buffer, "%d %s", msg_id, mp->uidl_str);
...
153c149
< sprintf(buffer, "%d %.900s", msg_id, mp->uidl_str);
---
> sprintf(buffer, "%d %s", msg_id, mp->uidl_str);
170c166
< sprintf(buffer, "%d %.900s", x, mp->uidl_str);
---
> sprintf(buffer, "%d %s", x, mp->uidl_str);
Are these limits in fact unnecessary, or have the qualcomm folks missed a few?
(This file is the same in v2.52 -- got in this morning and started working on
the 2.5 version before I saw last night's bugtraq mail... arggh)
If these limits are indeed necessary, note that there's also a copy of this
sprintf call on line 76.
regards,
------------------------------
Date: Thu, 2 Jul 1998 21:06:51 -0400
From: twiztah
Subject: SECURITY: redhat, the saga continues..
Security problems have been found in dosemu and libtermcap. These security
problems allow users on your local system to gain root access, and should
be fixed as soon as possible.
Red Hat 5.0 and 5.1
- -------------------
i386:
rpm -Uvh ftp://ftp.redhat.com/updates/5.0/i386/dosemu-0.66.7-7.i386.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/5.0/i386/libtermcap-2.0.8-9.i386.rpm
alpha:
rpm -Uvh ftp://ftp.redhat.com/updates/5.0/alpha/libtermcap-2.0.8-9.alpha.rpm
SPARC:
rpm -Uvh ftp://ftp.redhat.com/updates/5.0/sparc/libtermcap-2.0.8-9.sparc.rpm
Red Hat 4.2
- -------------
i386:
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/i386/dosemu-0.66.7-0.i386.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/i386/libtermcap-2.0.8-4.1.i386.rpm
alpha:
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/alpha/libtermcap-2.0.8-4.1.alpha.rpm
SPARC:
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/sparc/libtermcap-2.0.8-4.1.sparc.rpm
twiztah [twiztah@maxho.com] - phuq you: xaos, vore, dreamwalk
------------------------------
Date: Thu, 2 Jul 1998 19:22:05 +0200
From: Chris Fletcher
Subject: Re: Port 0 oddities
Bob,
> I've been off bugtraq for a couple of weeks but I just saw these
> messages. I have recently been putting logging into our cisco's rule
> set so that I can see what traffic is being passed through our
> network. I spotted traffic that appeared to be missed by the rules
> as it had src port 0 and dst port 0.
> Further investigation showed that it was ssh that was causing
> this. I have looked at the packets using tcpdump and they look find
> and what I would expect but the cisco is still reporting packets
> from 0 to 0.
Hmmm... I suspect that lines like this:
%SEC-6-IPACCESSLOGP: list 100 denied udp 10.0.0.211(0) -> 10.0.0.255(0), 3 packets
with '(0)' for the ports are generated when the router didn't know the
port numbers rather than them actually being 0. If your access-list doesn't
filter on higher level ports I wouldn't expect the router to bother
parsing the TCP/UDP headers so it can't log the port numbers and just
fills in with zeros to keep the format consistent.