Backdoor In Microsoft Web Software?

There's a backdoor in Microsoft Webserver software. The Wall Street Journal article isn't very technical, so we don't know yet exactly which software is affected: IIS, FrontPage, or both. It apparently doesn't affect Windows 2000 or FrontPage 2000. The workaround Microsoft "urges" is to delete dvwssr.dll. And just to make your Friday a little more surreal, the secret backdoor password apparently has something to do with Netscape engineers being "weenies." Update: 04/14 09:02 by J : It's been a busy day for some programmers at Microsoft and elsewhere. The word as of 3:30 EDT, according to Russ Cooper, is 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." (more)

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 JOURNAL

Microsoft 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.

Comments

Actual report - not as bad as it looked

[davew]

Russ Cooper just posted a more educated summary of the problem to NTBUGTRAQ. It's in the archives at this location.

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"

[davew]

Say due to some "bug" in the software, you get locked out of your mission critical system. How do you get back in?

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)

--

Russ Cooper says "NO VULNERABILITY"

[IntlHarvester]

Here's hoping this is high enough on the page that people see it. The /. story should probably be updated.

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

Cheers,
Russ - NTBugtraq Editor
"dot-age" (as in "we're in the dot-age") = senility (source Webster's)

--

Here's the dealio.

[Zico]

Microsoft has a Security Bulletin and a FAQ 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)

[Zico]

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

[stx23]

And from the properties dialog:-
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

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.

Presumably the magic phrase can override permissions to expose the source code. It's ::$DATA all over again.

actually...

[griffjon]

well, what you say actually could be enforced under the DMCA. I'll wager that the FP EULA doesn't allow users to decompile or strings it.

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

[Sloppy]

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

[Evro]

Without having read all these comments, I apologize if these points are redundant. However...

• With UCITA in effect, wouldn't MS be completely within its right by putting backdoors in its software? And wouldn't MS be able to sue the WSJ reporters for exposing this flaw?
  
• Right here we can see why MS will never open their source code. Perhaps they even put this backdoor in on purpose so that they could say to the Justice Department, "Look, if you open the source code up, all these bugs/backdoors will be exposed, and every site running Win2k will be destroyed. So you can't open the source, for the good of the Web." Far-fetched perhaps, but it seems like the kind of tactic they might use.
  

I think this discovery may have much farther-reaching implications that anybody presently realizes.

__________________________________________________ ___

Thus proving...

[Black Parrot]

Thus proving that the closed source model is, in fact, more secure than the open source model?

--

Re:So what does the file do then?

[Black Parrot]

I'm not finding much info. Google only has a couple of useful hits, and they turn out to be essentially the same. Check out t he MS reference page and read the section entitled "Web Application Level". (Read it carefully, because the bit about changing ACLs is apparently not the function of the .dll in question.)

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 .dll's location for systems running NT with NTFS, so that's all I can deduce about who's exposed.

Oh, and I can't resist this quote from the linked page:

Security for Web applications is a complicated subject because it can be set at several levels in several different ways.

One more level and one more way than it was supposed to, eh?

--

(OT) how were DES S boxes picked?

[Tau Zero]

They might have been classified at first, but the reasons have been rediscovered independently. What were rediscovered independently? I'm glad you asked me that. After the discovery of differential cryptanalysis by academic cryptographers, an investigation of DES found that the S boxes were highly resistant to this technique. The original IBM scheme, using 64-bit keys, would have also allowed many weak keys to be used. The S boxes were designed by the NSA, proving that the NSA's cryptographers knew of differential cryptanalysis and how to make cyphers resistant to it years before the technique was discovered by people working in the public sphere.

"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

[Bob Ince]

We've got three reports from newspapers, two of which are re-runs of the original one

Update: here's another re-run, this time from The Register.

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:

• have extensions to let me upload pages through HTTP; FTP is perfectly good for that thank you very much.
• do authentication; my scripts can handle that perfectly well thanks, and I don't appreciate servers fiddling with my headers and messing it up by trying to take control. IIS and Apache both think their own authentication methods are sufficient, but for any web application involving dynamic users, it's not. IIS is particularly amusing in this regard, using the NT userbase.
• listen to any kind of protocol that isn't HTTP or HTTPS.
• include by default all kinds of esoteric features, like IIS's selection of ASP, HTR, IDC filters, which have proved to harbour exploitable bugs.
• include by default examples, documentation and administration tools as live, publically accessible web sites. (IIS putting its documentation in a format that needs IIS to be actively running and in full working order to be able to read is particularly good.)
• have custom error pages set up by default that prevent authentication and redirection from working.
• think it can handle cache control better than me.
• non-optionally install a bunch of system utilities without giving any idea what they do.

Bloat begets bugs. I just want a simple web server.

--
This comment was brought to you by And Clover.

Heaven's Gift?

[wouter]

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?

[Raindeer]

If you can delete the file dvwssr.dll this easily, without any repercussions, I wonder what it did there in the first place.

Re:So what does the file do then?

[Guru Meditation]

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

Re:First time for nothing.

[Kmon]

Oh yeah, like this hasent happened before. I hear that microsoft has a deal with the CIA to install remote servers on all computers. So now the CIA can steal our porno!

No way, we'd catch on once we see a Linux box with a blue screen!

Well done

[heikkile]

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.

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"

[jamused]

If you can get locked out of a mission critical system, and yet there is a way to fix the system, that way should be made available through a "front door" with proper, user configurable, security. There is no problem for which a secret way into your mission critical system is the proper solution.

Re:Now that's professional...

[Ron Harwood]

Actually, the more I think about this, the more it irritates me.

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

[Anonymous Coward]

Actually, at offset 0xe00 in dvwssr.dll you will find something like "Netscape engineers are weenies!" in reverse. And also the filename "/global.asa" which I have no idea what it means since I don't use windows. (I found dvwssr.dll using ftpsearch, just to take a look at it.)

/AC

Risk, Accountability, and Interstate Commerce

[Effugas]

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

haha..

[FORTYoz]

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.

Re:Windows 98

[Orlando]

"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...

Re:Not MS policy

[Black Parrot]

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

--

Affects "almost every Web-hosting provider."

[nhowie]

So M$'s bug affects Apache then? ;-P
--

ESR is wrong??

[EasyTarget]

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..'

Windows 98

[vbrtrmn]

I heard that if you install Windows 98 backwards, it works.

--

Ye gods.

[Bob Ince]

we don't know yet exactly which software is affected: IIS, FrontPage, or both.

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

[Anomalous Canard]

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!!),

The plaintext is encrypted by writing it backwards in the .dll. By decrypting this copyrighted text, you have violated Section 1201 of the DCMA. Come along quietly and no one will get hurt.

Anomalous: inconsistent with or deviating from what is usual, normal, or expected

Heres the offending dll

[cheekymonkey_68]

Heres a link to the file dvwssr.dll for those who still think its a belated April Fool