Date: 	Sat, 4 Jul 1998 00:02:29 -0400
Reply-To: Bugtraq List 
Sender: Bugtraq List 
From: Automatic digest processor 
Subject:  BUGTRAQ Digest - 2 Jul 1998 to 3 Jul 1998
To: Recipients of BUGTRAQ digests 
Message-Id: <19980704040446Z80877-15031+11@brimstone.netspace.org>

There are 3 messages totalling 115 lines in this issue.

Topics of the day:

  1. ALERT: Microsoft IIS ASP - $DATA issue update
  2. Sun libnsl lameness
  3. Followup to MetaInfo vulnerabilities

----------------------------------------------------------------------

Date:    Thu, 2 Jul 1998 22:05:01 -0500
From:    Aleph One 
Subject: ALERT: Microsoft IIS ASP - $DATA issue update

---------- Forwarded message ----------
Date: Thu, 2 Jul 1998 16:24:24 -0700
From: Karan Khanna 
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: ALERT: Microsoft IIS ASP - $DATA issue update

Microsoft has posted a hotfix for IIS 3.0 as well as a procedure for a
workaround on its security web site.
(http://www.microsoft.com/security/bulletins/ms98-003.htm
 ).  We will
update this advisory with the location for the IIS 4 hotfix shortly.

------------------------------

Date:    Fri, 3 Jul 1998 16:09:42 +0200
From:    Andy Polyakov 
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
>
I'm the one who is responsible for these calls:-) Hello, everybody!

First of all I want to point out that mentioned functions in both ssh
*and* sshd cases are called at least at caller's, a.k.a.  none-root,
effective uid. Observe that when called at none-root euid 'getnetname'
does *not* call 'host2netname', but 'user2netname'. In addition it
should be mentioned that in ssh case call to 'getnetname' is performed
in separate process context at *both* effective & real caller's uid. So
that the way I see it it's *not* possible to exploit 'getnetname' to
gain root privileges in neither ssh nor sshd case.

Now let's look at 'getsecretkey' in sshd... First of all it looks like
the information provided in RSI bulletin is not accurate. 'getkeys_nis'
looks quite innocent to me, but not 'getkeys_nisplus'... I don't
believe buffer overflow in 'getkeys_nisplus' ever takes place in sshd
case, because arguments can not be manipulated by the intruder (as he's
not logged in yet!) by e.g. setting NIS_PATH environment variable. Bad
news is that all 'getkeys_*' call 'extract_secret' which in turn
does look like "come and get me"...  But what would it take to exploit
it? The way I see it intruder would have to have access to or forge
answers from NIS/NIS+ server in order to feed the victim with unusually
long key-pairs. Well, I have to conclude that 'getsecretkey' in sshd is
exploitable. Again! Provided that intruder has access to or capable
of imitating NIS/NIS+ server.

Should I think of a patch, people? The only thing one can do is to
fetch key-pair before calling 'getsecretkey' and make sure it's not
longer than 1K or something:-)
>
>
> George Clooney wrote:
> >                Functions we have found vulnerable:
> >
> >                Vulnerable key functions
> >                ---------------------------------------------------
> >                getsecretkey ()         : Calls getkeys_nis ()
> >
> >
> >                Vulnerable RPC functions
> >                ----------------------------------------------------
> >                getnetname ()           : Calls host2netname ()
>
Andy.

------------------------------

Date:    Fri, 3 Jul 1998 10:08:08 -0500
From:    Jeff Forristal 
Subject: Followup to MetaInfo vulnerabilities

Shortly after releasing the public bugtraq post, I was contacted by
MetaInfo regarding the problem and was told that they had just put a patch
online, available, with instructions, at www.metainfo.com/download.

While this patch corrected the problem of transversal into higher levels
of the filesystem, it was still open to another kind of DoS attack. If an
attacker was to send a GET request to MetaWeb server that contained around
8K of characters, the MetaWeb server process would spike to 100% CPU
utilization, and stay there indefinately.

Example:

http://mail.server.com:5000/index.htm?

This would put the server in an unstable state; now, a regular request
will cause to to spike and hang:

http://mail.server.com:5000/

MetaInfo was contacted about this problem as well; they released a patch
to fix this problem. You can download a copy from www.forristech.com, or
check to see if it's available on MetaInfo's site yet.

-Jeff Forristal

------------------------------

End of BUGTRAQ Digest - 2 Jul 1998 to 3 Jul 1998
************************************************