Slashdot Mirror
Backdoor In Microsoft Web Software?
Here are the basic details from the article (expensive reg. req.), because I can't find this story anywhere else. Strange that the WSJ should have the scoop on a security issue.
Microsoft Acknowledges Its Engineers Placed Security Flaw in Some Software
By TED BRIDIS
Staff Reporter of THE WALL STREET JOURNALMicrosoft Corp. acknowledged Thursday that its engineers included in some of its Internet software a secret password -- a phrase deriding their rivals at Netscape as "weenies" -- that could be used to gain illicit access to hundreds of thousands of Internet sites world-wide. [...]
The company planned to warn customers as soon as possible with an e-mail bulletin and an advisory published on its corporate Web site. Microsoft urged customers to delete the computer file-called "dvwssr.dll"-containing the offending code. The file is installed on the company's Internet-server software with Frontpage 98 extensions.
While there are no reports that the alleged security flaw has been exploited, the affected software is believed to be used by many Web sites. By using the so-called back door, a hacker may be able to gain access to key Web-site management files [...]
Russ Cooper, who runs the popular NT Bugtraq discussion forum on the Internet, estimated that the problem threatened "almost every Web-hosting provider." [...]
And, Black Parrot passed along this link to a CBS Marketwatch story, which is free but short on detail.
You know, it's funny. BugTraq recently posted news of a covert backdoor(obfuscated code, etc.) embedded in some minor commercial CGI out there. I considered posting it to Slashdot, but since once of the core magnifiers of a security breach is its universality(and I really didn't think that many people were using the script), I didn't think it'd get through the submission queue.
Looks like Microsoft solved *that* problem for me, eh?
They'll try to spin it, but there's really no good way to announce that there's a mission critical backdoor distributed in what appears to be an otherwise useless file. Assume the normal best case scenario: Some temp checked in the code on a lark.
So, that basically means some temp that checks in code on a lark can insert a mission critical security hole that will affect hundreds of thousands of businesses and millions of consumers.
Move up the chain. If it was a low grade employee who did it...if it was a small group of humorists angry about their easter egg being quelled...if Bill Gates himself did it and only he knew...worst case scenario, if Microsoft itself has no idea where this came from, but it got there...
Then anyone sufficiently powerful can insert a globally available backdoor.
The only defense? Microsoft was merely building in functionality allowing it to exercise its rights under UCITA to deny service to EULA violating customers(like websites that provide benchmarking statistics!).
Now, I'm no Congressman, but when a company in Washington State is backing state bills that let it shut down a company in New York State, that sure sounds to me like a rather inappropriate regulation of Interstate Commerce. Say what you will about the abuse of federal powers vs. state rights; UCITA's one scheme that would have been used to hold Microsoft's portion of the Internet Economy hostage to a humorously named but cryptographically bare passphrase that any 14 year old with half a brain could find.
If they've got a right to shut down software remotely, they've got a right to put in the backdoor that does it. That's how they were planning to get out of this disaster, which I'm sure they've known about for quite some time.
We need federal protection against those who would sell us malicious code by pushing corrupt state laws through the legislatures. UCITA was born when it failed to pass congressional muster; it failed to pass for a very good reason. In an age when the Interstate Commerce clause has been abused to no end, millions of Americans must now worry about billions of dollars of their money being stolen by anyone running a Microsoft server. The company will put on a valiant show, but while one face is talking customer protection, the other is lobbying as hard as it can to eliminate any rights customers might have against such attacks.
Microsoft is no longer invincible; fighting its legislative agenda is no death sentence. This intentionally released security hole clearly illustrates just what kinds of dangers UCITA opens up to the American consumer, for beyond even the simple analysis that Microsoft could claim this to be their legally protected implementation of a granted right...UCITA also bolsters Microsoft's right to sue whoever even looks for such a security hole, on the basis of a signed away right to reverse engineer.
You can't find the bugs. You can't demand the bugs be removed. You can't even tell anyone about the bugs. If this isn't a restriction of Interstate Commerce--among several other well cherished rights--I don't know what is.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
david@cold:~ > strings dvwssr.dll ..
... bunch of crap..
/global.asa
.asp
!seineew era sreenigne epacsteN
HTTP/1.0 404 Object Not Found
.. more crap
see the hidden message? hint.. its backwards.
"Apparently if you play the Windows NT CD backwards you hear satanic messages"
"You think that's bad, if you play it forwards it installs Windows NT!"
orlando...
-= This is a self-referential sig =-
The .dll in question is part of the Frontpage extensions:
The FrontPage Extensions manage design-time web permissions using the underlying security model of the host operating system on the server. Here we consider only the case where this operating system is Windows NT 4.0 with the NTFS file system.
FP manages administer and author access to a web using the same technique. In the web's root directory, FP creates a directory named _vti_bin. Within this directory it creates two sub-directories, _vti_adm and _vti_aut. Within _vti_adm FP places a file, admin.dll, and within _vti_aut it places two files, author.dll and dvwssr.dll. These DLLs are ISAPI extensions. During design-time, client requests arrive over HTTP at the server and are routed to one of these ISAPI DLLs.
A request to perform an administrative function, for example, change permissions on a web, is handled by that web's admin.dll.
A request to perform an authoring function, for example, open a web, is handled by that web's author.dll.
A request to fetch the source code for an ASP file without processing, for example, to view the links in that file, is handled by that web's dvwssr.dll.
In the request, the client provides credentials that identify the user who is logged in to the client workstation. This user must have read permission (equivalent to read and execute individual permissions) for the DLL handling the request, otherwise the request is denied. Thus FP restricts who may perform a given request by controlling read permission on the directories in _vti_bin. Whenever a change is made to a web's permissions via the Web Permissions dialog box, the FP Extensions on the server modify the ACLs on the directories _vti_adm and _vti_aut in that web's _vti_bin directory accordingly. Note: FP does not change ACLs on content files to manage design-time security; it only changes ACLs on the directories which contain the gatekeeper files admin.dll, author.dll, and dvwssr.dll. FP manipulates content file ACLs to manage run-time security.
----------
'We have no choice in what we are. Yet what are we,
but the sum of our choices.' --Rob Grant
----------
'We have no choice in what we are. Yet what are we,
but the sum of our choices.' --Rob Grant
> Rather I think this was a case of coders doing something without the knowledge of the designers / policy makers or whatever.
Perhaps so. But does that make MS look better, or worse?
The MS web documentation (see link in my top-level post) indicates that this file is the "gateway" that decides what incoming HTTP connects are allowed to look at. If a rogue programmer can slip a backdoor into a security module, what else is going on in other parts of the system?
With this landing in the middle of the investigations/accusations of spyware that are now going on in France, the EU, and elsewhere, I suspect that history will refer to this as the Easter Revelation that killed closed source software.
To a French diplomat, it does not matter whether a backdoor was planted by the NSA, Microsoft, or a rogue employee. What matters is whether there are any backdoors in his software at all.
--
Sheesh, evil *and* a jerk. -- Jade
So M$'s bug affects Apache then? ;-P
--
Eric S. Raymond said just this week that the open source model has one strength that closed source truly lacks, and can never have - peer review. All other "professional" endeavours of this magnitude have it (civil engineering was his example) and those professions are all the better for it.
Closed source development where quality is a focus does have quite a lot of review, by peers, and others. And the whole process (architecture, design, code and test) is fully reviewed in a structured method that ensures that everything is covered, not just the 'gee wizz' bits.
HOWEVER, this is not how Micro$oft and most other 'software houses' work.. It is used by places that truely care about software quality (NASA for instance). I used to work for Motorola developing for safety-critical systems, and peer review was very strong. I was a sysadmin and I was subject to review!
Check out the CMM (Capability Maturity Model) from the SEI. Compare it with the list of things that most of us consider open source strengths, you might be surprised. If done right, it allows bug free (and I do mean free, as in no signifigent bugs at all!) development.
Just because the likes of Micro$oft cannot be bothered to use this stuff, does not mean that closed source can -never- deliver quality or security. It just costs more.
EZ
-'Press Ctrl + Alt + Delete to log on..'
"Oops, I always forget the purpose of competition is to divide people into winners and losers." - Hobbes
I heard that if you install Windows 98 backwards, it works.
--
it's a sig, wtf?
The CBS article makes this clearer: it is the IIS FrontPage extensions.
I'm really, really having trouble believeing this.
That Microsoft's developers could be so recklessly dumb as to add a backdoor that will surely be discovered eventually (unencoded plaintext in a DLL, FFS!!), thus playing right into the hands of the open-source-is-good-for-security argument, and no-one at MS noticed it... the mind boggles.
There's nothing up on microsoft.com about it yet either, which also strikes me as strange. Is this really true? If so, it must be the security howler of the year.
I personally can't check if it works as a backdoor, since on the NT web server here I deliberately de-installed all the crap IIS wants you to have (unnecessary script mappings, example sites, web admin, FrontPage extensions...). Contrary to what some sysadmins seem to think, security does not lie in keeping all the Microsoft default settings.
Jesus wept. Prepare for a lot of defaced web sites.
--
This comment was brought to you by And Clover.
That Microsoft's developers could be so recklessly dumb as to add a backdoor that will surely be discovered eventually (unencoded plaintext in a DLL, FFS!!),
.dll. By decrypting this copyrighted text, you have violated Section 1201 of the DCMA. Come along quietly and no one will get hurt.
The plaintext is encrypted by writing it backwards in the
Anomalous: inconsistent with or deviating from what is usual, normal, or expected
Anomalous: deviating from what is usual, normal, or expected
Canard: a false or unfounded repor
Heres a link to the file dvwssr.dll for those who still think its a belated April Fool