Slashdot Log In
Backdoor In Microsoft Web Software?
from the joshua dept.
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.
Closed code sux. Now, how were DES S boxes picked? (Score:3)
Re:Heaven's Gift? -- Nope (Score:3)
There are scary implications here. When you cannot trust software made by one of the world's largest software companies, what do you do when if[sic] comes to all the little homebrew progams that are available?
This is exactly the mentality that keeps open-source from advancing. As strange as it may seem, the corporate world does not see open-source software go through the same sort of rigorous QA that (they assume) corporate products go through. An event such as this is only going to serve to make people doubt more software in general and that has a negative effect on open-source software which already has to face the FUD about its quality.
No, this isn't Heaven's Gift, it's Satan's Blessing. Too many people see Microsoft as the sort of God of software and when your God fails you, where do you turn? Certainly not to the meek.
AP article on this (Score:3)
http:// wire.ap.org/APnews/main.html?FRONTID=TECHNOLOGY&S
Sorry to weasel into a reply to the first comment here with this...
--
Audio Interview with Rain Forest Puppy (Score:3)
has an audio interview (April 14, 2000) with Rain Forest Puppy who discovered and was able to exploit the backdoor.
Note: Available as an MP3!
Re:actually... (Score:3)
Absolutely. And don't forget to further fortify it by XOR'ing it a few times with a long string of zeroes.
Security through marketing (Score:3)
One of the biggest endightments of proprietary commercial software is the fact that when a problem is doscovered the first people to move into action from the the company concerned are the marketing department, usually in full denial mode.
What users need is an immediate alert that a problem exists, followed by a fulfilled promise to get a technical team on it until its resolved, after which a release will be made ASAP. What they get is 'There is no problem' then 'Ok, theres a problem, but its not that bad' followed belatedly by 'Alright, it was a major issue, but look the fix is here now. Just pay for the upgrade'
With open source the answer might be 'We'll work on it as soon as we can' but at least theres no denial phase.
Usually there are all sorts of get out clauses in software licenses to excuse a company from any liability for problems that bugs might cause, but what about the case where a problem is discovered by the company that could be potentially fincancially damaging to its clients but it refuses to issue notice of the problem in a timely fashion?
ZamZ
Re:Backdoors in "secure software" (Score:3)
Secrets get leaked at a rate proportional to both the number of people who know it and the value of the secret. In the MS case, the secret is potentially known by several thousand MS employees with source code access, and the value of the secret is incredible, since it allows access to thousands if not millions of Web servers. In contrast, passwords rarely leak because they are known by only one person and can only be used to attack one site.
To handle the case of getting locked out of your own system, you use a well-documented, well-protected service entrance. A perfect example is the OS itself, be it NT, Unix, or whatever.
If you lock yourself out of your OS (lost the root password or something), the service entrance is to boot from CD or floppy, which gives you superuser priveleges and allows you to change the superuser password(s). The security of the service entrance is due to teh fact that said devices are physically connected to the machine. That is, you need physical control of the machine, the ability to touch the case, before you can exploit this. And if such a machine needs to be secure, the competent admin will put it under lock and key. We can't protect you against incompetent admins.
If the system you are locked out of is an application rather than an OS, you can build a service entrance that requires superuser priveleges. Since you can always gain superuser priveleges with physical access (see above), no back door is needed.
Don't be too complacent. (Score:3)
On the other hand, I don't think open source is completely immune to this either -- after all, don't they have code reviews at Microsoft? Nothing really prevents a Red Hat engineer from doing something equally stupid. For that matter, the backdoor in question is not necessarily in the official source, is it? It could have been slipped in in binary form.
You can't be absolutely complacent, unless you both compile everything on your system from source and review all the source code before compiling. Even then you can't really be sure without dumping the object code (remember the old Unix password hack built into the C compiler?).
If you consider most root exploits such as the one that came out in bind last year, most of them are bugs. It wouldn't be too hard to deliberately introduce such bugs so they would pass casual inspection. Another proof that whoever did this was an idiot.
Open source's advantages over closed source for security are relative, not absolute. As in bug fixes, things can be disocvered faster and fixed faster.
Just found another story... (Score:3)
Odd? (Score:3)
Questions arise: 1) Why was it there? 2) What will removing it break? and 3) What the heck kind of bugfix is deleting a file in the first place?
"My kernel is panicking on boot!" "Delete
I will never fully understand Microsoft Corp., its methods, or its software.
Microsoft: bringing you yesterday's technology tomorrow.
Could this "discovery" be deliberate? (Score:3)
According to the stories [theregister.co.uk], Frontpage 2000 on Windows 2000 isn't affected.
As The Register puts it, per the link above:
The problem isn't there in Win2k servers with FrontPage 2000 extensions, so an upgrade might be a good idea. But not necessarily to Win2k.
Hrm.
Ok, Windows 2000 isn't jumping off the shelves. Problems are grounding it. So... maybe its time to "leak" a old backdoor, so that people would upgrade to 2000 ASAP?
Granted, those who thought would be saying "What problems will we have there" - but by and large - the people who think aren't running NT (especially for webserving).
(Not an NT bash, BTW. I'm talking about the vast majority of tossed-up NT servers who fill needs, and then massive effort is spent _fixing_ problems, performance, etc, rather than sitting down, building a good solution, and doing it right. (Personal opinion, NT shouldn't be there, but in those cases, some valid cases can be made for NT).
I just... Surely not. Surely this is just a coincidence. But... I've *got* to wonder..
Addison
Uh ... (Score:3)
Not MS policy (Score:3)
Okay, this is a truly bad hole in Microsoft's server software, and one which should never have been there in the first place. And while many people here may scream conspiracy, I don't think that it was. Rather I think this was a case of coders doing something without the knowledge of the designers / policy makers or whatever.
Think about it. Why would Microsoft want this put into their software, when if it was found out, which would be likely, would lead to a massive publicity scandal, and possible legal action? This wouldn't be in their best interests at all, especially given the current events.
Rather, this sounds like the sort of thing coders would do, especially the part about Netscape employees being "weenies". Given that MS employees are loyal to MS, this kind of thing sounds like something they would choose on their own, just because they thought no-one would notice it.
spectacular (Score:3)
!seineew era sreenigne epacsteN
You think they could've, I dunno, ENCRYPTED IT? I mean, its one thing (unscrupulous as it is) to put a backdoor in software, but its just plain stupid to store the p/w in cleartext on every machine that runs frontpage in the world.
Re:If it were open source ... (Score:3)
Re:Down right criminal... (Score:3)
I see stories like this, the NSA scandal, and reading bugtraq, and I just shake my head as to why these people use MS products and smile, feeling all warm and gooshy inside, when they pay enormous amounts of money for something that is proven not to work and is insecure. WTF is going on?
Re:What took so long? (Score:3)
Why was it discovered now? Maybe the recent release of Win 2000 has something to do with it. If I ran a business with NT or '98 this would sure be an incentive for me to buy their new backdoor-free software! Yessire Bob!
What I find odd is that the article says the perpetrator is as yet unknown. Does MS allow anonymous submissions to its core products? That is truely astonishing.
First time for nothing. (Score:3)
Re:Affects "almost every Web-hosting provider." (Score:3)
It is, in fact, this blindness that makes corporatism (a) so evil and (b) so futile in the long run. There are values that are not economic values, and they do have the strength to compete.
Actual report - not as bad as it looked (Score:4)
Russ Cooper just posted a more educated summary of the problem to NTBUGTRAQ. It's in the archives at this location [ntbugtraq.com].
It's NOT as bad as first reported. Russ says that his comment that it affects "almost every web hosting provider" was based on the info that it was some sort of Front Page issue. It's not that simple, and it seems that it's only exploitable by users who have already been granted web authoring permissions on the box.
Have fun,
Dave
--
Re:Backdoors in "secure software" (Score:4)
You send a tech to let you back in through a well known and documented procedure that allows full access from the console, a feature you knew about and chose not to disable.
The fact that backdoors can be useful does not excuse one being placed silently in a piece of software that is then marketed as secure. You may approve of having a remote back door; you may believe that the risk is sufficiently small to justify the potential cost savings. That's great. But that is a decision for each customer to make, and not every customer will agree.
Separately, it's my opinion that a common remote backdoor, no matter how well hidden, will turn round and bite you on the arse eventually. This software is too well deployed; too many people are auditing it and probing it. If an engineer puts 100 hours of work into hiding it, it only takes 100 people 1 hour of searching to equal that effort. How before someone makes that discovery? And how long after that before it is widely reported anywhere other than IRC?
Dave
(posted with Mozilla 2000041316 [mozilla.org])
--
Russ Cooper says "NO VULNERABILITY" (Score:4)
From: Windows NTBugtraq Mailing List [NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM]
on behalf of Russ [Russ.Cooper@RC.ON.CA]
Sent: Friday, April 14, 2000 12:33 PM
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: Re: DVWSSR.dll Vulnerability in Microsoft IIS 4.0 Web Servers
Ok, here's a breaking update.
Latest reports say that there is
NO VULNERABILITY IN DVWSSR.DLL
Yup, that's right, different again from what I said earlier, and even more
different than what I said yesterday to WSJ.
Please accept that I have followed the story published elsewhere and tried
to keep you abreast of everything I knew. Also appreciate that the amount of
time given to verify and research the claims made by others has been
extremely short. I've had probably 30 interviews today by orgs pressing for
information on the story as the feeding frenzy occurs after the first one
goes to press (WSJ in this case).
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).
Decide for yourself whether we were better served by (more) immediate
disclosure or not. I've stood where I stand for a reason, despite the
loathing of others for my stance...
In the end, it turns out that unless you actually have permissions for the
file you are requesting, you'll get an error message when you follow the
procedures outlined by RFP in his RFP2K02 advisory.
That said, understand that sites that allow connections by Front Page may
very well provide you with source asp if you request it. BUT THAT WILL
HAPPEN with or without the
across virtual servers on a given box, site leakage or manipulation by
others will always be possible in myriad ways.
>From what I've heard/seen/been told, permissions on the test servers must
have either been non-existent, incorrectly applied, or permissioned the user
across multiple virtual sites (i.e. incorrectly applied).
I had someone claim that they could get into an FP98 site using
"Netscapeengineersareweenies!" as a userID and no password...making them
think it was a backdoor userID. Fact is they could get into the same sites
using "TomDickandHarry" as a userID too. If the permissions aren't set
correctly, anything is possible.
This info may change again before its finalized. It may well be that there
is some way to use this
appear to be this one. On a box where multiple sites have not been
individually permissions, or permissions are lax or non-existent...anyone
permissioned to execute the
to simply open the other sites and manipulate them directly (i.e. no need to
do this junk with the dvwssr.dll)
Finally, to my point out the string not being a password. Elias Levy of
SecurityFocus.com and Mark Edwards of NTSecurity.net have both correctly
pointed out that using the term password to apply to that string is not
beyond the realm of understanding. The client component mtd2lv.dll and the
server component dvwssr.dll both need to know this value, and use it
correctly, for communications to work. If you try and talk directly to
dvwssr.dll and don't obfuscate your communication with the correct "key", it
won't understand you. Of course if you don't already have permissions,
knowing this value gets you nothing...hence my observation that its not a
password. Whatever it is, it appears to be meaningless junk text used as
data.
Cheers,
Russ - NTBugtraq Editor
"dot-age" (as in "we're in the dot-age") = senility (source Webster's)
--
Here's the dealio. (Score:4)
Microsoft has a Security Bulletin [microsoft.com] and a FAQ [microsoft.com] about the problem. Although it's limited, there is a vulnerability -- nothing like those password scenerios that have been bandied about, however.
Quick summary: If multiple web sites are hosted on a NT4/IIS4 server with FrontPage 98 extensions installed, then webmaster A with web authoring permissions on his own site could potentially inappropriately read the .asp (and possibly the global.asa, but no others) files of webmaster B's web site if he knew where they existed on the same server. Note that to be able to do this, user B would have had to have granted user A read permissions (explicitly, or by giving read access to "Everyone") on those files -- otherwise, user A would be unable to read the files.
Soooo, this looks like a tremendously smaller problem than everyone originally thought, although there definitely is a vulnerability for the scenario I mentioned above. Corrections welcomed if I munged any of that explanation.
Cheers,
ZicoKnows@hotmail.com
Looks like there never was a backdoor (read below) (Score:4)
This was posted to the NTbugtraq list by Russ, the owner. If true, there are a whole damn lot of Slashdotters who made fools of themselves jumping to conclusions today. That's all I'll say about that, so, on with the post (sorry for the bold, and the entire repost, but it needs to be seen):
======= BEGIN MESSAGE =========
Ok, here's a breaking update.
Latest reports say that there is
NO VULNERABILITY IN DVWSSR.DLL
Yup, that's right, different again from what I said earlier, and even more different than what I said yesterday to WSJ.
Please accept that I have followed the story published elsewhere and tried to keep you abreast of everything I knew. Also appreciate that the amount of time given to verify and research the claims made by others has been extremely short. I've had probably 30 interviews today by orgs pressing for information on the story as the feeding frenzy occurs after the first one goes to press (WSJ in this case).
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).
Decide for yourself whether we were better served by (more) immediate disclosure or not. I've stood where I stand for a reason, despite the loathing of others for my stance...
In the end, it turns out that unless you actually have permissions for the file you are requesting, you'll get an error message when you follow the procedures outlined by RFP in his RFP2K02 advisory.
That said, understand that sites that allow connections by Front Page may very well provide you with source asp if you request it. BUT THAT WILL HAPPEN with or without the .dll. Without proper and full permissions applied across virtual servers on a given box, site leakage or manipulation by others will always be possible in myriad ways.
From what I've heard/seen/been told, permissions on the test servers must have either been non-existent, incorrectly applied, or permissioned the user across multiple virtual sites (i.e. incorrectly applied).
I had someone claim that they could get into an FP98 site using "Netscapeengineersareweenies!" as a userID and no password...making them think it was a backdoor userID. Fact is they could get into the same sites using "TomDickandHarry" as a userID too. If the permissions aren't set correctly, anything is possible.
This info may change again before its finalized. It may well be that there is some way to use this .dll in a way that's not intended...it just doesn't appear to be this one. On a box where multiple sites have not been individually permissions, or permissions are lax or non-existent...anyone permissioned to execute the .dll in the first place would have the ability to simply open the other sites and manipulate them directly (i.e. no need to do this junk with the dvwssr.dll)
Finally, to my point out the string not being a password. Elias Levy of SecurityFocus.com and Mark Edwards of NTSecurity.net have both correctly pointed out that using the term password to apply to that string is not beyond the realm of understanding. The client component mtd2lv.dll and the server component dvwssr.dll both need to know this value, and use it correctly, for communications to work. If you try and talk directly to dvwssr.dll and don't obfuscate your communication with the correct "key", it won't understand you. Of course if you don't already have permissions, knowing this value gets you nothing...hence my observation that its not a password. Whatever it is, it appears to be meaningless junk text used as data.
===== END MESSAGE ======
Cheers,
ZicoKnows@hotmail.com
Re:haha.. (Score:4)
Microsoft Design Tool - Link View
It's installed by Front Page Server Extensions 3.0. 'The FrontPage Extensions manage design-time Web permissions using the underlying security model of the host operating system on the server.'
From MSDN [microsoft.com]
Presumably the magic phrase can override permissions to expose the source code. It's
actually... (Score:4)
And really, it wasn't JUST encrypted backwards, it had a full double-ROT13 encryption applied before that, so even after de-backwardsing it, you still would have to take it through two rounds of ROT13 before it was readable.
Re:actually... (Score:4)
Two rounds of ROT13 is still incredibly weak, though. All the crypto experts recommend at least 16 rounds, and with processors being so fast these says, I usually do 64 rounds.
---
Two Points... (Score:4)
I think this discovery may have much farther-reaching implications that anybody presently realizes.
__________________________________________________ ___
Thus proving... (Score:4)
--
Re:So what does the file do then? (Score:4)
dvwssr.dll is described as a "gatekeeper" for browsing, which would make sense if it is where the backdoor code lies. It is apparently part of the "FrontPage Server Extensions". The table at the link gives the
Oh, and I can't resist this quote from the linked page:One more level and one more way than it was supposed to, eh?
--
(OT) how were DES S boxes picked? (Score:4)
"Not cracked yet" happens to be the acid test for cryptosystems. Anything which has been open to public scrutiny and attack for years without being cracked is more trustworthy than something which has not. DES is losing usefulness because hardware is now fast enough to do brute-force attacks at reasonable cost, but that's something we knew would happen. If you have secrets you need to protect for the ages, you don't use DES anyway. The tradtional way of protecting these things is to use bullets, though the US government is a little bit more sophisticated; to protect some secrets known by a dying CIA director, he was scheduled for neurosurgery which destroyed his speech centers before his scheduled Congressional subcommittee appearance. Not exactly subtle, but clever.
(Is there anyone who doesn't shiver when they think of the stuff like this that spooks do?)
--
Re:Jkatzman (Score:4)
Update: here's another re-run, this time from The Register [theregister.co.uk].
They include an attribution of identification to .rain.forest.puppy, who has, as they state, successfully indentified other NT hacks (most recently problems with RDS). So it seems this problem is probably real.
Shit.
However the code got there... if this didn't get spotted my QA, I am flabbergasted at the incompetence. If this did get spotted and was let through, I am flabbergasted at the unprofessionalism. Either way, MS are going to receive a whole bowlful of flabbergast.
I'd just like to make this point again: what I want from a web server is the ability to read HTTP requests and either read a file or call a CGI script. It should support SSL, and chunked transfer-encoding, and be fast. That is all I need.
I do not want a web server to:
Bloat begets bugs. I just want a simple web server.
--
This comment was brought to you by And Clover.
Heaven's Gift? (Score:4)
This seems as a heaven's gift to me for all those "security through obscurity doesn't work" advocates. We know they're right, but this event - if it is entirely true, and gets headlined in many media - would certainly help management understand that something might be wrong with their perception of how to handle security.
Surely, this event won't mean that suddenly every company will switch to an open source solution, but i firmly believe that this event is one of the many steps that happen in the evolution of perception of software and its uses.
This won't result in a sudden increase in the usage of Linux, FreeBSD or any other open source solution... It's just all matter of evolution...
... If it is solid... I mean, this sounds too good to be true, not?
Anyway, i'm on my way telling my manager "told you so!" :)
So what does the file do then? (Score:4)
Re:First time for nothing. (Score:4)
No way, we'd catch on once we see a Linux box with a blue screen!
Well done (Score:4)
Here's my theory: Not everyone at MS is happy working there, and some may even be friendly to Open Source. Instead of (or just before) leaving the Evil Empire they decide to leave a small present. Once safely out, they tip off a journalist in one of the papers that can hurt MS the most.
If nothing else, this shows a clear hole in MS quality control procedures. If this sort of feelings are common inside MS, they may well be running into more serious problems than anything DOJ can give them...
Re:Backdoors in "secure software" (Score:4)
Re:Now that's professional... (Score:4)
Believe it or not, using Visual Interdev is a pretty standard thing with not UNIX web-dev shops... and to come along and say - "oh yeah, we screwed this up because it was funny" is just insane. I cannot fathom what the programmers at MS are thinking.
And to say that "well, it doesn't affect 2000" is no better. I have to ask at that point, "Why? Did you come up with something even funnier for 2000?"
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.
If there was even one iota of external peer review, this "feature" (and you can't call something that was placed there on purpose a bug) would never have seen the light of day.
Re:I know the phrase... (Score:5)
Risk, Accountability, and Interstate Commerce (Score:5)
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
haha.. (Score:5)
... 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.
Re:Windows 98 (Score:5)
"You think that's bad, if you play it forwards it installs Windows NT!"
orlando...
Re:So what does the file do then? (Score:5)
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
----------
Re:Not MS policy (Score:5)
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.
--
Affects "almost every Web-hosting provider." (Score:5)
--
ESR is wrong?? (Score:5)
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 [cmu.edu] (Capability Maturity Model) from the SEI [cmu.edu]. 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..'
Windows 98 (Score:5)
--
Ye gods. (Score:5)
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.
Put down the mouse and step away from the keyboard (Score:5)
The plaintext is encrypted by writing it backwards in the
Anomalous: inconsistent with or deviating from what is usual, normal, or expected
Heres the offending dll (Score:5)