Cooments on the dvwssr.dll vulnerability threads

[core.lists.exploit-dev () CORE-SDI COM (Iván Arce)]

Sorry if make the wrong thing crossponsting to several lists, i believe
that some clarifications (technical and other) are needed and i'll
try to summarize the posts on differents lists first.

The initial report from RFP on April 14th said:

> I've been told that dvwssr.dll is a component of the NT 4 Option Pack, to
> be used with InterDev 1.0.  Therefore deleting it will affect InterDev
> 1.0's 'View Links' function.  Also, the default permissions don't allow
> for anonymous users to use the .dll--however, anyone with web authoring
> can, and I've seen few sites that have allowed permission (which is more
> due to a misconfiguration on their part).  As Microsoft has told me, the
> immediate problem is moreso the fact that any developer of one particular
> virtual site can download the .asp code of other virtual sites on the same
> system.

 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.

Further more...
> Luckily, from my auditing, this is not included with any other versions of
> FrontPage (including Unix), and in the versions I found it on, ACLs
> prevented its use (only System and Administrators were allowed full
> access); I was told by MS that only individuals with web authoring
> permission can use it, which is more than I had originally thought.  But
> it's not as widespread as, say, RDS. ;)

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

Microsoft's original post, MS00-025, April 14th:

> Issue
> =====
> Dvwssr.dll is a server-side component used to support the Link View
> feature in Visual Interdev 1.0. By design, it provides  .asp files to
> clients who have web authoring privileges on the server. However, it
> does not properly restrict the files that  a web author can request,
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

To me this seems to be acknowledging the existence of a bug

> with the result that a user who has web authoring privileges on one
> web site could request .asp  files from anywhere on the server,
> including other web sites hosted on it. However, even with this
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
And here is the impact of exploiting the bug

> vulnerability, the  component would only comply with the request if
> the specific file granted read access to the user.
>
> There are some significant restrictions to this vulnerability:
>  - Only servers hosting multiple web sites could be affected by it
>  - Only a user who has web authoring privileges for a site on the
>    server could request a file. He would need to know the name and
>    location of the file on the server.
>  - The files would only be sent if their permissions granted read
>    access to the particular user who requested them. In most cases,
>    this would mean that the files granted read access to the
>    Everyone group
>  - Only .asp files (and global.asa, which is a special-case .asp
>    file) could be retrieved.

And above, the constraints to doing such exploitation.

So, so far everything seems clear enough, despite whatever media has
to say about it. IMHO the relevant part is quoted above, the fact
that the 'weenie algorithm' is used to obfuscate file names is a
different issue.

Now, Russ Cooper's post to NTBugtraq (April 14th) stated:

> Ok, here's a breaking update.
>
> Latest reports say that there is
>
> NO VULNERABILITY IN DVWSSR.DLL

And

> MS have had people working on this thing like madmen, trying to verify the
> claims and investigate all of the possible pieces of code that may be
> affected. As that research progressed, different observations were made and
> so the story came out in various stages (with varying levels of
> "correctness"). Had they been given a reasonable amount of time to respond,
> nobody would have been in a tizzy about anything (i.e. the press would not
> have cared to run this story anywhere).

 That triggered Gerardo's curiosity (since there was two different
stories
 about this, posted the same day, with a 4hour period between them).
 So Gerardo took a peek at DVWSSR.DLL, without taking into consideration
 who uses it and under what circunstances. The question here was:

 Is there a bug in the DLL or not?

 Microsoft's first post seems to imply there is, yet 4 hours later Russ
says
 there is not, and hes been in touch with Microsoft and, even more, as
he said
 MS engineers have been working on it as madmen.. so whats going on?

 The answer came 10 minutes later:
 Yes, there IS a bug in DVWSSR.DLL, its a buffer overflow, and IT IS NOT
 directly related to the 'weenie algorithm' issue.
 So, onto Gerardo's findings:

 An exploitable buffer overflow is present in the DLL,
 it allows anyone with execution priviledges to DVWSSR.DLL to
 execute arbitrary code on the server.
 This implies, for example, a remote CMD.EXE.
 The question now is:

 Under what privileges is that code run?

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

> Issue
> =====
> Dvwssr.dll is a server-side component used to support the Link View
> feature in Visual Interdev 1.0. However, it contains an  unchecked
> buffer. If overrun with random data, 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?

> 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?

 Or are web author privileges equivalent to SYSTEM privileges?

 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.
 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.
 (as MS states in the last paragraph)

 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.

 It is important to note that a solution for this problem has been
 already provided by Microsoft:

> Remediation
> ===========
> To eliminate this vulnerability, customers who are hosting web sites
> using any of the affected products should delete all  copies of the
> file Dvwssr.dll from their servers. The FAQ provides step-by-step
> instructions for doing this. The only  functionality lost by deleting
> the file is the ability to generate link views of .asp pages using
> Visual Interdev 1.0.

 This is from the April 17th post, and it is exactly the same solution
 suggested on the original April 14th post.

 Those interested in the technical aspects of the bug can stop reading
 now, our next post wil be a proof of concept exploit and some
 explanations on how it works.

 Now for the boring part...

 I do not intent to go further down the full disclosure vs. mediated
 realease of information discussion here, however Russ Cooper's
 post on NTBugtraq regarding CORE's work requires some clarifications
 on our side.

Russ Cooper in reply to our post said:
NTBugtraq
April 17th, Message-ID:
<E9A01F52DC939448BBDE44ED2E1C468F0697DE () muskie rc on ca>

> The vulnerability that CORE-SDI has uncovered appears to be totally
> unrelated to that "issue", beyond it being in the same .DLL. If CORE-SDI

 Indeed, that is exactly what we were looking for, an answer to the
question
 Is there a bug in DVWSSR.DLL?
 It is unrelated to the weenie issue.

> requires the names of .DLLs to investigate to be prompted to look into them,
> I can start a questionable-DLL-of-the-day program to prompt them/others. If
> the philosophy is that if there is one potential problem in a .DLL there are
> likely exploits, then they should take the manifest for any Service Pack and
> go through those "fixed" programs looking  for other exploits.

 Well, yes we could do that, i believe the charter for the vuln-dev list
 is quite similar to what Russ proposes.
 So i encourange people to use that list for what it was created...

> I still say that if there had been more time for MS to investigate the issue
> before it went public the original hype wouldn't have happened.

Hmm apparently the hype had nothing to do with what RFP and MS published
in their
advisories, but with the use of the provided information by the media
and
the comments of the security experts on the issue.
And as far as i can remeber CORE had nothing to do with this, we have
not
been contacted by the press prior to our post and had not made any
statement
with regards to the 'secret password backdoor'.

> If that
> meant that CORE-SDI wouldn't have looked at DVWSSR.DLL, and therefore
> wouldn't have found the buffer overrun, then I think that's a problem with
> how some investigators decide what they'll investigate rather than a
> disservice to the community as a whole. If we're going to yell "Fire", then
> there should at least be a real fire to point at.
Well, I do consider missinformation in terms of information security
issues a
serious threat. If someone yells 'FIRE' and that appears to be
reasonable, i'd
would be very careful in my methodolody and editorial policies before
yelling
"NOT TRUE! NOT TRUE! EVERYTHING IS FINE!".

I'd like to point out that CORE's methodology and how some of our
investagators
decide what they'll investigate is not the problem here and sincerely,
how is
that related to the issue at point??.
The problem is that there are bugs out there and people is not taking
appropiate
measures to confirm or deny their existence.

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

-ivan

--
"Understanding. A cerebral secretion that enables one having it to know
 a house from a horse by the roof on the house,
 It's nature and laws have been exhaustively expounded by Locke,
 who rode a house, and Kant, who lived in a horse." - Ambrose Bierce

==================[ CORE Seguridad de la Informacion S.A. ]=========
Iván Arce
Presidente
PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836  B25D 207B E78E 2AD1 F65A
email: iarce () core-sdi com
http://www.core-sdi.com
Pte. Juan D. Peron 315 Piso 4 UF 17
1038 Capital Federal
Buenos Aires, Argentina.              Tel/Fax : +(54-11) 4331-5402
Casilla de Correos 877 (1000) Correo Central
=====================================================================

--- For a personal reply use iarce () core-sdi com