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: <[EMAIL PROTECTED]> > 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 : [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
