Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Microsoft

Backdoor In Microsoft Web Software? 445

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.

This discussion has been archived. No new comments can be posted.

Backdoor In Microsoft Web Software?

Comments Filter:
  • by Anonymous Coward
    Hrmmm... Russ Cooper barely acknowledges the true source of this.

    Much better to go have a look at RFP's post to BugTraq [securityfocus.com].

    One other comment is that M$ products frequently have reports of security holes at least as serious as this, and sometimes a lot more so. I guess this just gets the attention because it was engineered in. But, it is certainly not the only backdoor found in software. Here is a nice one here [securityfocus.com].

    Parting thought, is anyone going to read this?

  • by Anonymous Coward
    .. more crap ..

    The crap you omitted was "XWebScope Source Retriever". Maybe it is a string which a client needs to send to microsoft's server to be able to retrieve files? Maybe in combination with the Netscape-weenies string?

    I have a feeling that the entire dll is just a tiny "webserver plugin".

    The system functions the dll uses are stuff like strcmp, ReadFile, CloseHandle, strlen and so on. Just enough to check for the secret passphrase and send some files. :-)

  • According to one source I read [ntbugtraq.com], the only use of the file is for ASP support for Visual Interdev version 1.0. Deleting the file will break Visual Interdev 1.0 support, not in and of itself a big deal, most people have either run away from Microsoft authoring tools, or upgraded to a recent version of FrontPage.

    On the other hand, knowing Microsoft I wouldn't be surprised if the manner in which Visual Interdev support is broken is by the server crashing when a Visual Interdev 1.0 client makes a request for ASP info. This would replace the security hole with a denial of service attack.

    ----
  • Don't blame me -- I don't even touch their software, leave alone run it.
  • It forces me to look at my assumptions, and this casts some light on the matter. Anyone who has read my essays section at airwindows.com knows I've acutely distrusted Microsoft for _years_, and in fact written things that at the time could have seemed paranoid until Microsoft went and made all of it a reality.

    This is why I am NOT SURPRISED that Microsoft would put in a really _dumb_ and arrogant backdoor key to their software and maintain it through ALL LEVELS of code checking, on purpose- presumably not because they were really actively planning to be able to break into their own customers' computers anytime they wanted, but 'just in case' they might want or need to do that sometime! I fail to see any other possible reason for this. Conceding that they are not the Illuminati or competing with the NSA- the only possible conclusion is that right to the highest levels, Microsoft wanted to leave their options open about someday _becoming_ like that, and so hubris leads them to stick really _stupid_ backdoors in, correctly assuming that their customers would not figure even this out (it's been how many years to figure this one out?)

    The thing is, I am not surprised, so I am startled and astonished when this is suddenly getting so much attention. To me it's just another Bugtraq 'issue' because I already _thought_ Microsoft wanted to supplant the government and lay the groundwork for surveilllance and remote control of its own customers. It's old news to me- though this feeling of mine was based on intuition, as I'll happily admit, so there was no real evidence, as I would also admit.

    Now there is- it's a 'smoking gun' type of revelation- and while for me it's an 'Ah, I thought so', for many people it's like waking up and realising their mother is not their mother, like she is a bloodsucking Arcturan weasel in a cheap mask. I can sympathise with their shock to some extent even though I never had much patience with their pathetic trustingness in the first place. Sorry guys. New rules.

  • This isn't a flaw - it's deliberate. It's no more a flaw than the flight simulator in Excel 97.


    ...phil
  • Hell yes, it's intentional. How does a text string that says "Netscape engineers are weenies!" wind up in a system DLL and make it through quality assurance checks without being intentional?


    ...phil
  • If you want to create a second way in, man, go ahead. Write a CGI script to exec sshd or something. But you don't need the maintainers of Apache to do that for you; you don't need that capability hidden from you; and you sure as hell don't need that capability being discovered in someone else's system on the other side of the globe and then exploited in yours while you are taking your first holiday in 2 years...

    Backdoors, done properly, have their place. That place is not implemented unknowingly in thousands and thousands of installations worldwide where such a backdoor would be wholly unsuitable anyway.

    Make no mistake. Whatever this is, it's not a feature.

    Dave
    (Still using mozilla 2000041316)

    --

  • I'm not trying to downplay the significance of this. But the arrogant statement by whoever (in the Wall St. Journal article) had the gall to imply that this would affect "every web-hosting provider" has forgotten that MOST web-hosting providers aren't dumb enough to use IIS in the first place. Just check the Netcraft Survey [netcraft.co.uk] of websites to see that Apache whose developers probably don't think of Netscape engineers as "weenies", holds a 60% (+/- 5% I'm guessing) market share in that area.

  • you're assuming "corporate" software goes through a lot of QA, or for that matter adequate QA. As someone who has spent years of his life DEEP in the trenches in a software QA role at a "very corporate" software concern, let me assure you that often, the all-important bottom line trumps the QA process. Often.

  • I run Linux at home, several co workers do, the head of ops runs it. I have personally seen linux boxes cracked in 3 seconds. Net BSD seems quite possible though.

    Any box that isn't set up properly can be cracked in 3 seconds. Unfortunatly, many distros are not set up correctly. NetBSD is a good choice though.

  • If, for some reason, the ssh daemon dies, I'm fucked.

    If at all possable, I would set the web server up with a serial console to a second system on the site. The second system should also have a relay to trigger the reset line on the server. Nearly all problems that don't require a hardware ficx can then be handled remotely.

    There's also the Weasel card that was a story here a while back.

    As far as a backdoor goes, A private one that you put there yourself may be a good thing, but a global one that many people know how to access, the odds that you'll have to take a trip to the server increase rather than decrease.

  • Which one is going to be cheaper in the long run?

    I'd say that Linux/*BSD with Apache is cheaper in the long run. Once set up, Apache is not at all difficult or time intensive to maintain. The same is true of Linux and *BSD. In the real world, I have found that with the same hardware, a Linux system will handle at least 1.5 times the load of an NT system. I don't have much experiance with *BSD, but I understand that it will similarly outperform NT.

    The real issue is Frontpage. It is possable to set up Apache with Frontpage, but you are then open to any security flaws it may introduce in it's binary only parts.

    As for justifying the money spent on MS licensing: To put it plainly, I cannot think of a justification for that unless some of your customers insist on an NT based server or on features unique to the MS 'solution'.

  • The source code for the MS FrontPage extensions for apache is here:
    See for yourself.
  • you're assuming "corporate" software goes through a lot of QA, or for that matter adequate QA.

    I am not assuming this. I specifically stated that people assume this. I have a very good idea how QA general software goes through, but the mass market does not (since they still believe that the product they get is the final, highest quality version). You can mouth off all you want about how much you know, but the fact that Microsoft sells so much product and that everyone uses it tells people in general that they make a good product that everyone can use, thus when they have a screwup, it raises doubts on all of software in general
  • So if this isn't present in Windows 2000/IIS2000, or whatever it's called this week, then they went over the old code, found it, deleted it, and told nobody.
    Unless they're claiming they wrote IIS from scratch now too.
  • Are .dll's checksummed? If not, you could just overwrite the "Netscape" message with some gibberish of your own.
  • This happened in FrontPage 98. Maybe there are some plaintext backdoors in FrontPage 2000. Does anyone with that product wanna run "strings" on a few of the .dll's?
  • Here's an associated press article on this:

    http:// wire.ap.org/APnews/main.html?FRONTID=TECHNOLOGY&ST ORYID=APIS73RF7J80 [ap.org]

    Sorry to weasel into a reply to the first comment here...


    --
  • My site subsribes to newscast today (today.newscast.com), which is a fee-based news service that collects articles from several sources and gives you a common interface. I searched for "dvwssr.dll" and found only 3 stories, all from the WSJ. The one quoted above, and two copies of another article from April 14, "Microsoft Acknowledges Security Flaw". A couple of fair-use quotes:

    Microsoft Corp. acknowledged yesterday that its engineers included in some of its Internet software a secret password ... that could be used to gain illicit access to hundreds of thousands of Internet sites world-wide.

    The manager of Microsoft's security-response center, Steve Lipner ... described such a backdoor password as "absolutely against our policy" and a firing offense for the as yet unidentified employees.

    ... The company planned to warn customers as soon as possible with an e-mail bulletin and an advisory published on its corporate Web site.

    ... One of the experts who helped identify the file is a professional security consultant known widely among the Internet underground as "Rain Forest Puppy."

    ...

  • Comment removed based on user account deletion
  • Forgot to mention that the above is quoted from TechNet April 2000, Visual InterDev technical notes.

    ----------
    'We have no choice in what we are. Yet what are we,
    but the sum of our choices.' --Rob Grant
    ----------
  • Isn't it ironic that in an attempt at insulting another software company, MS engineers demonstrate how unprofessional they themselves are?
  • Nope, I just exploited it on a site that I have no rights on...

    http://www.wiretrip.net/rfp/p/doc.asp?id=45&ifac e=2

    Try it yourself....
  • This post (http://slashdot.org/comments.pl?sid=00/04/14/0619 206&cid=540) [slashdot.org] has the information on the vulnerability for those curious to know what the deal is. I shoulda posted it as a reply here to begin with, but am posting this link to it because there probably aren't too many people who will make it down to the 540th post where it got buried. Sorry!

    Cheers,
    ZicoKnows@hotmail.com

  • I don't think it was the Slashdotter's who made fools of themselves. Keep in mind that this story was carried on numerous major news sites, including WSJ and C|Net, and included the phrase "Microsoft confirmed" along with other quotes from Microsoft management. I really don't think you can blame people for believing the story when it appears that Microsoft itself believed it to be true. Take this quote from the C|Net article about the bug:

    "This is a vulnerability because it allows an author on one Web site on a shared server to see anything on another server," said Steve Lipner, manager of Microsoft's Security Response Center. "That's the extent of the vulnerability."


    Skepticism is always a healthy thing, but I don't think it's unreasonable to believe that a security hole exists in a Microsoft product when Microsoft says that there is a hole! I mean, do we all have to go install IIS and verify the existence of the hole ourselves to avoid acting "foolish"?

  • "Backdoors aren't always a bad thing. Hypothetical situation...

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


    Yup, and if your users don't upgrade as quickly as your marketing plan demands (They lose an entire cycle of revenue and a chink of marketing numbers if you skip from v.1 to v.3)...

    and in a couple of year the backdoor might be leaked^h^h^h^h^h^h^h discovered, and many users of your existing products will upgrade. After all, it is the fastest and simplest way to quick-fix this problem (and others that may come later)

    Pretty soon, you'll have them trained: BUY THE NEW VERSION ON RELEASE. True, they may not want to install it yet (until the 'gamma testing' is over -- v2.1 or 2.2), but at least they'll have it on hand when v1.x goes up in smoke.

    In this case, InterDev 1.0 *requires* the affected DLL (so the MS official fix won't work for InterDev users) and a lot of people will move to Frontpage 2000, when FP 98 (or 97) met their needs quite well until now.

    If a licit and deliberate 'front door' password and verification scheme were compromised, MS would clearly be legally liable for failing to protect the password (just as you are liable if you let your corporate password get into the wrong hands) -- but if a "back door" is discovered, then they can blame it on 'evil hackers', even if their own service engineers use it routinely.

    BTW, a legal front door would demand that they do more work -- e.g. verify EngineerID by modem to MS HQ or time-varying encryption -- while a back door can be a simple password, since it is never acknowledged. Any company that deliberately uses a password backdoor is guilty of negligence in today's corporate/legal environment. Do they think no service engineer will ever quit or be fired?.

    __________

  • The string also appears in the DLL Mtd2lv.dll, which is installed in C:\Program Files\Common Files\Microsoft Shared\MSDesigners98\. I think is installed by Visual Studio Enterprise Edition, but this DLL is a lot bigger, namely 514Kb over 7Kb.
    Does anyone know how to exploit it yet, though?
  • Why didn't they go over to the excel team and learn how to do easter eggs right. Replacing the 404 page with "Netscape blows goats!" would have been cool. This is moronic.
    --Shoeboy
  • All code should have code reviews. Where were their code reviews? Who missed this? Did somebody let it go buy?

    I'm not surprised so many IIS sites have been hacked. I'm wondering what other gems are in their web server.

    Before you think that this problem dosen't effect you, consider the web sites you frequent and buy from.

  • Some fast and lose numbers...

    Data from the Netcraft Web Server Survey [netcraft.com]. Of a total of 13,106,190 servers surveyed about 21% are Microsoft based, or 2,742,931 servers (actual March count). Figuring an average of 2 minutes to login and delete each file at an average pay+overhead rate of $50 an hour for the web admins deleting the .dll you get a cost of about $4,571,552 just to delete the files.

  • The more I think about this the more I feel it is down right criminal to stick a backdoor like this into code. This can lead to massive problems for both individuals and businesses that have data stollen. Look at the trouble that was caused to the credit card companies with the stollen credit card number lists from web servers. Add on top of that the fraudlent charges to peoples credit cards. Deliberate backdoors like this and others make it all that much easier for a cracker or script kiddy to break into a system. Who knows if this was the exploit used in any of the previous security breaches. I'd bet that some used it. maby not all, but some.

    Ponder this: Would you accept a security system for your house if you knew it could be bypassed by anybody with a standard code?

  • For anyone too lazy to even bother . . .

    skunk:~$
    skunk:~$
    skunk:~$ wget http://www.sivertsen.com/_vti_bin/_vti_aut/dvwssr. dll
    --12:06:28-- http://www.sivertsen.com:80/_vti_bin/_vti_aut/dvws sr.dll
    => `dvwssr.dll'
    Connecting to www.sivertsen.com:80... connected!
    HTTP request sent, fetching headers... done.
    Length: 6,416 [text/html]

    0K -> ...... [100%]

    12:06:28 (59.11 KB/s) - `dvwssr.dll' saved [6416/6416]

    skunk:~$ file dvwssr.dll
    dvwssr.dll: MS Windows PE 32-bit Intel 80386 GUI DLL
    skunk:~$ strings dvwssr.dll
    !This program cannot be run in DOS mode.
    .text
    `.rdata
    @.data
    .idata
    .rsrc
    @.reloc
    >%u:
    D$4h
    D$4j
    ]_^[
    t*;5
    D$4j
    D$<"
    DVWSSR.DLL
    DllMain
    GetExtensionVersion
    HttpExtensionProc
    /global.asa
    .asp
    !seineew era sreenigne epacsteN
    HTTP/1.0 404 Object Not Found
    XWebScope Source Retriever
    _refresh_acls_
    Content-type: text/html
    KERNEL32.dll
    lstrcmpiA
    lstrcpynA
    CloseHandle
    ReadFile
    CreateFileA
    lstrlenA
    lstrcpyA
    GetModuleFileNameA
    lstrcmpA
    1!1-141H1O1
    2q2}2
    `0d0
    dvwssr.dbg
    ssr.dll
    skunk:~$

  • Does Laurie Anderson know you're stealing her material? :)

    Pope
  • After seeing my stock portfolio crash and burn I feel trollish too.

    there is a difference. MS portrays itself as professsional, and Linux is seen as a grand experiment. No one expects Linux not to have some rough edges. Being a work in progress is what Linux is all about. But when you pay several hundred dollars for software, it better work. If a Disc from some guy making Linux copies is a flaky, no big thing, but if some MS bug factory software turns your computer into a paper weight, it is a big thing.

    It is expectations.

  • Anyone remember Firesign Theatre's "I Think We're All Bozos on this Bus"? Remember the backdoor Clem used - "Springhead, this is worker".

    Heck, I used that same sentence as the backdoor into a system I wrote -- but the customers got source and new it was there. (Further and more, you had to be already logged in at a certain privilege level before it'd be recognized.)

    There are some occasions where a system needs to provide some way for a "maintenance worker" (or sysadmin) to expose certain inner workings to manipulation -- that's what the root password is all about, right?

    Mind, in this case it doesn't apply: you don't keep such a hook secret from the customer, you do give them the option of changing it (with suitable warnings), and Front Page is hardly anything mission critical enough as to require that sort of access to a running system. (Plenty of other ways to access it if so.)

    Running 'strings' on that DLL (buried deep within the FrontPage directories) did indeed turn up "!seineew era sreenigne epacsteN". I've found other interesting strings in MS software (eg, a copyright notice from the Regents at UCB in 'ftp.exe'). Might be interesting to run strings on all the W2K stuff, although perhaps they're more careful now about hiding such things (may they rot13'd it.)
  • > OTOH, people here have run strings on the file and it has turned up the phrase... so...?

    Best case it's just a tease and not really a password at all.

    But with MS's recent PR track record, who is going to believe there's not a backdoor even if there isn't? The "NSA key" has been in the news again lately. There's a long flamewar going on in the newsgroups right now.

    This could hardly come at a worse time for Microsoft.

    --
  • You'd think that corperations, seeing the projects within thier very own company go through little QA and end up fairly buggy, would run away from anything produced by another corperation.

    But no, time and time again they seek to buy something just because it's produced by another company with a facade of competency (and it's not just Microsoft we are talking about here).

  • There was a space in the URL given - the end should read CiHiliteType=Fill.

    I'll try pasting in the fixed URL:
    http://www.yoursite.com/null.htw?CiWebHitsFile=/yo urfile.asp%20&CiRestriction=none&CiHilit eType=Full

    Nope, /. html munging code strikes again. Oh well, you can fix it by hand.
  • Sorry, make that:

    There was a space in the URL given - the end should read CiHiliteType=Full

    Not "Fill"!!!


  • Ok, sure there's a backdoor in this dll, but what can you do with it? Is it something that can only be accessed from the console? From a webpage somehow? and what rights does the backdoor give you? As funny as I think this is (come on, the fix is "delete the file"?), it remains to be seen just how dangerous the hole really is.
  • No matter what license code comes under, as long as all of the source code is available (even if it's look but don't touch), problems like this will be prevented by simple code auditing and peer review.

    And that's why I'd never trust a piece of Microsoft server software over Apache [apache.org] or Qmail [qmail.org] for example. A lot of Microsoft software is relatively stable now (my win2k install hasnt needed rebooting in a month), but so closed and opaque that there's no way whatsoever to audit or confirm that a million backdoors aren't present. One has been found, how many others?!
  • Anyone care to run checks on more of Microsoft's DLLs? I'm inclined to think that this isn't the only cleartext backdoor in Windows.

    No wonder MS doesn't want DOJ to open-source Windows. It would take them years to clear out all the inside-jokes, bad hacks, broken code, and cleartext backdoors. Yeesh.

  • So `strings d*.dll` produces something you'd find in a dictionary, therefore there's a secret backdoor and all IIS servers are unsafe and if M$loth put the wrong content up on a webserver they could trigger WW3...

    Er. Yeah, right. Next?
    ~Tim
    --
    .|` Clouds cross the black moonlight,
  • The very next part of this reads:

    FrontPage does not change ACLs on content files to manage design-time security; it only changes ACLs on the directories that contain the gatekeeper files admin.dll, author.dll, and dvwssr.dll. FrontPage manipulates content file ACLs to manage run-time security, which is the topic of the next section.

    This file can only be reached and executed if you have -AUTHOR- rights to the web. If you are a smart admin, you would be hosting your sites on NTFS partitions and therefore this is not the big risk that they say it is.

    The 'password' is probably visible in a sniff, or even encoded in the HTTP POST request to the extensions however you CANNOT execute the dll call it without the permissions.

  • Some (VBRUN300.DLL) are, most (SHELL32.DLL, etc) aren't. The checksumming isn't internal to Windows' DLL-loading process, but some DLL's do a checksum of themselves and refuse to run if modified.

    In this case, you could probably make as many changes as you wanted. Just don't change the length of the string unless you're really really good at changing offsets and entry points. :)

  • Wow. Thankfully, I didn't find the same in the Linux Frontpage extensions. I looked in both version 3.0 for Frontpage 98 and version 4.0 for Frontpage 2000.

    I can't tell you how much it drives me nuts to have to load Microsoft software on my Linux web servers. So much so that I don't even trust their setuid wrapper. Each site runs as a dummy user, which owns their files.

  • by Anonymous Coward on Friday April 14, 2000 @04:19AM (#1133592)
    Oh sure, we have the source code for DES, but it's packed with tables and tables and tables of magic numbers. How were they chosen? Why is there a 14 at row 1, column 1, of table S1? The how and why of S box determination is ***still*** classified to this day. Until I know how these numbers were chosen, I have no choice but to assume that it ebtails some sort of back door to let Feds (or some lucky h4xx0r who stumbles upon the back door) quick and easy access to my data. Because of the potential of a very quick unrraveling of DES security, having everyone rely on it (esp. the world's banking systems) is setting the world up for disaster. "Not cracked yet" is not a sufficent proof of a crypto-alg's security. This could be just like Microsoft.
  • by Hrunting ( 2191 ) on Friday April 14, 2000 @02:40AM (#1133593) Homepage
    This is a quote from the leading online gaming source, Blue's News [bluesnews.com].

    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.
  • by Barbarian ( 9467 ) on Friday April 14, 2000 @02:35AM (#1133594)
    Since a link is only been given on the Wall Street Journal (pay site), Here's an associated press article on this:

    http:// wire.ap.org/APnews/main.html?FRONTID=TECHNOLOGY&ST ORYID=APIS73RF7J80 [ap.org]

    Sorry to weasel into a reply to the first comment here with this...


    --
  • by Col. Klink (retired) ( 11632 ) on Friday April 14, 2000 @08:00AM (#1133595)
    InternetNews Radio (http://stream.internet.com/)
    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!
  • by DiningPhilosopher ( 17036 ) on Friday April 14, 2000 @11:52AM (#1133596)

    Absolutely. And don't forget to further fortify it by XOR'ing it a few times with a long string of zeroes.
  • by ZamZ ( 28920 ) on Friday April 14, 2000 @01:05AM (#1133597)
    To my mind the most worrying part about this is that MS discover a possible critical security problem and its users get to hear about it only as a leak to the press.

    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

  • Often, a "service entrance" is needed, a way to access your software when you lose your primary access credentials (like, say, you forget the root password). The term "back door" implies a service entrance accessed by knowing a secret that is common across all machines. If we run the same type of system, we have the same back door. This spells doom for truly secure systems, since such secrets get leaked often.

    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.

  • by hey! ( 33014 ) on Friday April 14, 2000 @03:20AM (#1133599) Homepage Journal
    I pretty much agree with your sentiment, it was incredibly unprofessional.

    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.
  • by Gompers ( 35786 ) on Friday April 14, 2000 @01:41AM (#1133600)
    http://www.nytimes.com/a ponline/f/AP-Microsoft-Password.html [nytimes.com]...still not very in depth..
  • by cdlu ( 65838 ) on Friday April 14, 2000 @01:16AM (#1133601) Homepage
    Doesn't it strike you as odd that removing a file is a bugfix?

    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 /vmlinuz, it'll work after that."

    I will never fully understand Microsoft Corp., its methods, or its software.

    Microsoft: bringing you yesterday's technology tomorrow.
  • by addison ( 80477 ) on Friday April 14, 2000 @04:21AM (#1133602)
    Hrm.

    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
  • by truefluke ( 91957 ) on Friday April 14, 2000 @12:46AM (#1133603) Homepage
    *If* this is true, this is supposed to be representative of a responsible and respected company? And why only one thin report on something so serious? IF this is true, I still don't understand how Microsoft thinks they have any business releasing software with Internet functionality anymore. Intranet, sure. Internet? No way.
  • by spiralx ( 97066 ) on Friday April 14, 2000 @12:51AM (#1133604)

    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.

  • by Kmon ( 105348 ) on Friday April 14, 2000 @12:56AM (#1133605)
    Thrilling. I love it. The greatest thing is that I'm sitting here with dvwssr.dll open in a text editor. The password is stored in cleartext. Backwords, yes, it took me a full thirty seconds to find it. Oh yes here it is:

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

  • by MonkeyMagic ( 118319 ) on Friday April 14, 2000 @01:10AM (#1133606) Homepage
    ...it would never have been there in the first place. Most of us would be embarassed to open up such obvious flaws in our code - peer review would never have let this happen.
  • by fsck ( 120820 ) on Friday April 14, 2000 @05:56AM (#1133607) Homepage
    Or people who run WWW sites could PULL THIER HEADS OUT OF THIER ASS and stop using Microsoft Shitware as a server, when there are proven secure solutions that cost 100% less, such as OpenBSD.

    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?
  • by Masked Marauder ( 148855 ) on Friday April 14, 2000 @06:56AM (#1133608)

    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.

  • by ssooyy ( 151518 ) on Friday April 14, 2000 @12:42AM (#1133609) Homepage
    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!
  • Quoth the poster:
    So M$'s bug affects Apache then? ;-P
    Is it any surprise that the official mouthpeice for corporatism thinks that Microsoft runs "almost all" Web servers? The whole FSOS (Fres Software / Open Source) movement almost necessarily falls below the radar of corporatists. If it doesn't cost anything, and it can't be charged as a loss-leader, then it must not be important.

    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.

  • by Dhericean ( 158757 ) on Friday April 14, 2000 @12:45AM (#1133611)
    we could all see what the password is.
  • by lbrlove ( 164167 ) on Friday April 14, 2000 @01:46AM (#1133612)
    I propose a new backdoor in the Apache code. It would work something like this:

    When the user types "Bill Gates is a fungus covering the streets of the cyber village" to a logged site, the server immediately spawns new processes which scour the Web looking for vulnerable IIS servers.

    Upon finding these sites, it does nothing. Why would you need to do anything to a machine that runs (Af)front Page Extensions?! It already suffers from enough code-bloat to make any amount of bandwidth nearly useless.

    -L
  • by davew ( 820 ) on Friday April 14, 2000 @05:37AM (#1133613) Journal

    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

    --

  • by davew ( 820 ) on Friday April 14, 2000 @01:13AM (#1133614) Journal
    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 [mozilla.org])

    --

  • by IntlHarvester ( 11985 ) on Friday April 14, 2000 @09:49AM (#1133615) Journal
    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)

    --
  • by Zico ( 14255 ) on Friday April 14, 2000 @03:50PM (#1133616)

    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

  • by Zico ( 14255 ) on Friday April 14, 2000 @10:59AM (#1133617)

    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

  • by stx23 ( 14942 ) on Friday April 14, 2000 @01:50AM (#1133618) Homepage Journal
    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 [microsoft.com]
    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.
  • by griffjon ( 14945 ) <GriffJon&gmail,com> on Friday April 14, 2000 @04:45AM (#1133619) Homepage Journal
    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.
  • by Sloppy ( 14984 ) on Friday April 14, 2000 @05:13AM (#1133620) Homepage Journal

    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.


    ---
  • by Evro ( 18923 ) <evandhoffman.gmail@com> on Friday April 14, 2000 @08:39AM (#1133621) Homepage Journal
    Without having read all these comments, I apologize if these points are redundant. However...
    • With UCITA [badsoftware.com] 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.

    __________________________________________________ ___

  • by Black Parrot ( 19622 ) on Friday April 14, 2000 @12:40AM (#1133622)
    Thus proving that the closed source model is, in fact, more secure than the open source model?

    --
  • by Black Parrot ( 19622 ) on Friday April 14, 2000 @01:08AM (#1133623)
    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 [microsoft.com] 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?

    --
  • by Tau Zero ( 75868 ) on Friday April 14, 2000 @04:42AM (#1133624) Journal
    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?)
    --

  • by Bob Ince ( 79199 ) <and@@@doxdesk...com> on Friday April 14, 2000 @04:31AM (#1133625) Homepage
    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 [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:

    • 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.
  • by wouter ( 103085 ) on Friday April 14, 2000 @12:47AM (#1133626) Homepage

    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!" :)

  • by Raindeer ( 104129 ) on Friday April 14, 2000 @12:52AM (#1133627) Homepage Journal
    If you can delete the file dvwssr.dll this easily, without any repercussions, I wonder what it did there in the first place.
  • by Kmon ( 105348 ) on Friday April 14, 2000 @12:58AM (#1133628)
    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!
  • by heikkile ( 111814 ) on Friday April 14, 2000 @01:49AM (#1133629)
    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...

  • by jamused ( 125583 ) on Friday April 14, 2000 @01:03AM (#1133630) Homepage
    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.
  • 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.
  • by Anonymous Coward on Friday April 14, 2000 @12:45AM (#1133632)
    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

  • by Effugas ( 2378 ) on Friday April 14, 2000 @02:40AM (#1133633) Homepage
    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
  • by FORTYoz ( 5393 ) on Friday April 14, 2000 @12:48AM (#1133634) Homepage
    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.
  • by Orlando ( 12257 ) on Friday April 14, 2000 @02:54AM (#1133635) Homepage
    "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...
  • by Guru Meditation ( 12823 ) on Friday April 14, 2000 @01:43AM (#1133636)
    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
    ----------
  • by Black Parrot ( 19622 ) on Friday April 14, 2000 @03:41AM (#1133637)
    > 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.

    --
  • by nhowie ( 38409 ) on Friday April 14, 2000 @12:40AM (#1133638) Homepage
    So M$'s bug affects Apache then? ;-P
    --
  • by EasyTarget ( 43516 ) on Friday April 14, 2000 @01:44AM (#1133639) Journal
    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 [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..'
  • by vbrtrmn ( 62760 ) on Friday April 14, 2000 @01:41AM (#1133640) Homepage
    I heard that if you install Windows 98 backwards, it works.

    --
  • by Bob Ince ( 79199 ) <and@@@doxdesk...com> on Friday April 14, 2000 @12:55AM (#1133641) Homepage
    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.
  • 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 a link to the file dvwssr.dll [sivertsen.com] for those who still think its a belated April Fool

For God's sake, stop researching for a while and begin to think!

Working...