Re: Cooments on the dvwssr.dll vulnerability threads

[dleblanc () MINDSPRING COM (David LeBlanc)]

At 10:25 PM 4/17/00 -0300, Iván Arce wrote:

> So these seems to be quite precise WRT possible attackers and impact,
> the hype derived from the media coverage does not seem to be part of
> RFP's agenda.

This is what happens when something is just put out in front of everyone
with no notification - it takes a little while to figure out just exactly
what is going on, and in the meantime, there is going to be a bit of
confusion. In my personal experience, getting the facts straight before I
go telling the whole net has saved me considerable embarassment.  There
have been times I've gone to the vendor with something that turned out to
be entirely bogus due to some horrible error on my part.

> > I was told by MS that only individuals with web authoring
> > permission can use it, which is more than I had originally thought.  

> So, we narrow the attacker's profile to 'individuals with web authoring
> priviledges' which does not imply 'System' or 'Administrators'.

This is true.

> > vulnerability, the  component would only comply with the request if
> > the specific file granted read access to the user.

If you can read the file, you can read the file.

> Under what privileges is that code run?

> The latest post from Microsoft (MS00-025 update , April 17th) seems
> contradictory:

Not as I read it.

> > it could be used to cause an
> > affected server to crash, or could allow  arbitrary code to run on the
> > server in a System context.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> so code is run as SYSTEM?

Indeed.  Any DLL run by IIS will end up executing as system at some point.
This is very well documented.

> > By default, the affected component, Dvwssr.dll, resides in a folder
> > whose permissions only allow web authors to execute it.  Under these
> > conditions, only a person with web author privileges could exploit the
> > vulnerability - but a web author already  has the ability to upload
> > and execute code of his choice, so this case represents little
> > additional threat.

> Or is it run with the privileges of the Web author?

Actually, a bit of both.  Refer to the chapter on security in the IIS
Resource Kit.  In order for any user to execute a file on the system, that
user must have execute rights to the file.  The initial file access is
going to always be done as the calling user, and the DLL always has the
choice to impersonate the calling user - it can su to that user if it
likes.  Because it has to be able to su to the context of the calling user,
it needs to be running as system in the first place.  Any basic reference
on how ISAPI DLLs work should be able to clear this question up nicely.

> Or are web author privileges equivalent to SYSTEM privileges?

Only if you can overflow the buffer before it changes user context.  This
is the exact same issue you see with suid executables on a UNIX system.

> The logical answer to this would be, web authors should not
> have the same privileges of SYSTEM, so if the vulnerability permits
> someone to run code as System this is a serious flaw.

Obviously.

> However, if web authors have the same privileges that System  and
> they already have the ability to execute code on the server, the
> flaw represents little additional threat.

This depends on whether things are configured to allow authors to add ISAPI
DLLs.  If you let people add these, then yes, they can install code that
will execute as localsystem, and you certainly want to think about who you
might allow to do such a thing.  This is why it is seldom a good idea to
let end-users just add files directly into their site, unless inherited
permissions on new files do not include the 'X' bit.  If you let them run
something other than static HTML, then there are some other things to worry
about, but somewhat less severe.

> Current work at CORE is directed at providing a working exploit for
> this bug, this will help to find a definite answer to the questions
> above.

I don't see much benefit to this, unless you'd like to encourage people to
break into other people's servers.  IMHO, being able to find the servers by
feeding it 5000 'a's is quite sufficient to demonstrate the problem, and
the advisory clearly states that one can execute code as localsystem.  What
more is there to prove?

> The problem is that there are bugs out there and people is not taking
> appropiate measures to confirm or deny their existence.

IMHO, it is also a problem if you do not allow the vendor any time at all
to come up with a fix, evaluate the problem, or allow admins to take
corrective action.  But that's just how I've always behaved - others
clearly come up with different ways to do things.  Which is better depends
on your point of view.

> Excuse me if im being rude, but in shocked by the fact that our company
> is
> being questioned because we found a bug.

Personally, it doesn't bother me a bit that you found a bug.  People do
that all the time.  This is why we have 3-4 mailing lists dedicated to
alerting people about found bugs.  Nice people tell the vendor before (for
some value of before) they tell the entire world, and really nice people do
not tell the entire world late on a Friday afternoon.  But then again,
that's just my personal definition of nice.  Your definition could be
different. IMHO, it is a good thing to find flaws, get them corrected, and
give people some time to get the patch propogated before half the script
kiddies on the planet are coming after your network.  It is a bit less fun
if you are the one who is still working at 11PM on a Friday evening, which
may account for some of the reasons why my view of the universe seems to be
a little different than your's.

David LeBlanc
dleblanc () mindspring com