Microsoft -- Designed for Insecurity

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

Comments

How to backdoor an OSS project

[Anonymous Coward]

Introduce exploitable flaws, what guarantuee do we even have that some of the buffer overflow exploits found in OSS projects were not intentional?

Re:slashdot motives?

[HeUnique]

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?

Re:Of course, KT's CC hack wasn't Open Source

[emerson]

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.


--

Re:Why is slashdot ignoring this important news?

[Alex Belits]

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.

Re:Open Source's Glaring Security Problem

[Alex Belits]

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.

Re:The Famous Back door in OSS software.

[Alex Belits]

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.

Re:The Famous Back door in OSS software.

[Alex Belits]

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.

Is there really a venerability?

[khaladan]

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.

Re:Is there really a venerability?

[gilroy]

OK, OK, it's not really fair to harp on spelling errors ... Goodness knows, I'm at fault at least as often as anyone else.

But... did anyone else find it hilarious that this poster confused the word "vulnerability" with "venerability". The latter, I assume, would mean "capable of being venerated", defined by MW Online (http://www.m-w.com/netdict.htm) as " to honor (as an icon or a relic) with a ritual act of devotion".

Considering the quasi-religious fervor on both sides of the issue, this struck me as wonderfully a propos.

Re:The Linux community should not revert to FUD!

[Chris Johnson]

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*

Re:Complacency

[Frater 219]

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.

Re:Open Source's Glaring Security Problem

[Frater 219]

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.

[Amphigory]

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.

--

This actually is a cryptographic backdoor.

[Effugas]

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

Re:This actually is a cryptographic backdoor.

[ecampbel]

No, you're wrong. "Netscape programmers are weenies!" is simply used to encrypt certain data travelling back and forth between two Microsoft components. Clearly, Microsoft did not intend for this security method to be foolproof; they simply wanted to keep the casual observer from seeing certain data. Here's what Russ cooper said:

While reports focused on a phrase -- "!seineew era sreenigne epacsteN" or the backwards spelling of "Netscape engineers are weenies!" -- which was present in the DLL, that's a red herring, said Cooper, adding that the phrase is not a password, but a cypher key used to scramble the address of Web pages requested by users..

Are you on crack?

[kidlinux]

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.

Re:Slasdot FUD

[jjohn]

ESR wrote Fetchmail.

Eric Allman wrote Sendmail.

Hope this helps.

Re:Open Source's Glaring Security Problem

[kronos]

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

[Sam Ruby]

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

Re:Excelent and balanced article

[Zico]

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

Re:The Linux community should not revert to FUD!

[GoRK]

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

Re:The economics of backdoors

[Syberghost]

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

Re:The economics of backdoors

[Syberghost]

Scratch that; it's over 13 million now.

Re:Source Code no Panacea

[Graymalkin]

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.

Re:Why is slashdot ignoring this important news?

[Zico]

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

Re:Yes ... there is.

[Zico]

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

Re:Why is slashdot ignoring this important news?

[Zico]

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

[Zico]

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

[Wah]

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!

--

Re: Hello, there _is_no back door

[Zico]

Sure. This links to my post of information (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 (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.

[Zico]

"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

Re:Why is slashdot ignoring this important news?

[Zico]

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

Yes, it has been done!

[dosowski]

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

Re:I use Linux specifically because it's Open

[shambler snack]

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.

Re:The economics of backdoors

[Black Parrot]

> Seriously, my question is, how can you quantify the expenses and losses of something like this??

I was wondering last night... what is it going to be like when it happens again, "for real". Say five, ten, twenty years from now, the internet economy is well entrenched, everyone relies on it, and suddenly word leaks out that there is a wide-open door in the back of some widely used server system. Only this time, you can't fix it by merely deleting a "spare" library file.

If you're running closed source, you shut down your servers and wait for a patch from the vendor. And hope that there is enough left of the internet to allow you to download the patches, rather than waiting for FedEx!

This is not, IMO, a risk that you - or society at large - can afford to take.

--

Re:on and off topic- Regarding the above posts.

[Black Parrot]

> Any post that does not conform to the Open Source Movement party line is instantly moderated to oblivion where no user, especially no non-logged in user (since the change in default score display setting), is likely to see it, thereby supressing dissenting opinions.

Simply put, your facts are incorrect. I see innumerable posts with dissenting opinions. I see posts that go against the "party line" moderated up to 5. I also see "party line" posts that were moderated high early on brought back down as the "dissenters" moderate them.

I even saw your post.

There's nothing wrong with your sentiments; you simply miss the facts.

--

Re:Of course, KT's CC hack wasn't Open Source

[Black Parrot]

> 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

The solution to that is to compile your compiler with some other brand of compiler, in which case the malignant code will not be inserted.

In practice, I don't think the Thompson hack would work very well anyway, or at least he would not get away with it for very long.

First, the compiler must detect something to trigger the special output. It cannot just assume anything it compiles is the code for itself. (In this age of easter eggs we might not be surprised to find a flight simulator in our compilers, but if we compiled our flight simulator and got a compiler for the executable, we would be alarmed indeed.)

From there, the question arises of what the hack should detect.

If it just detects the file name, you would only need to rename your compiler and recompile it, and then you would have a clean compiler to go forward with.

If it detects the actual source, you could similarly transform your source by renaming all the variables, functions, macros, etc., compile the result, and again obtain a clean compiler to go forward with.

The only thing I can see that would beat those kinds of safeguards would be to detect the structure of the source code - no easy task.

And even if the hack detected structure, how long would the structure go unchanged? If someone tweaks the code to fix a bug, the structure changes, the detection fails, and you again obtain a clean compiler.

It looks to me like the hack must detect the structure of an extremely small segment of code to avoid quick extinction due to workaday bug fixes and enhancements. But it must also juggle this against the need to detect a large enough structure to ensure that the program was indeed a compiler, since the game would also be up if it misdetected itself in what was actually a flight simulator.

And even then, recompiling with another compiler would surely provide the necessary purge.

I find the Thompson hack extremely interesting as an intellectual exercise, but in practice I don't think it would work, or at least not for very long at all.

Closed source is the way to go for back doors, though even then it's likely just a matter of time before you get caught. [Insert SecurityByObscurity mantra here.]

--

ESR is wrong...Misleading Article

[scheme]

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

Re:ESR is wrong...Misleading Article

[the eric conspiracy]

only lets the attackers read .asp or .asa files.

Read access to these files can be enough to allow a clever hacker to find further security holes in a web site.

Re:ESR is wrong...Misleading Article

[Abigail-II]

Read access to these files can be enough to allow a clever hacker to find further security holes in a web site.

That's an arguments that's also used against open source - that it would expose security holes. Remember, security through obscurity usually isn't very secure to begin with.

-- Abigail

Re: Thompson's paper and GCC in practice

[Abigail-II]

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.

The problem with that is that the original GCC might be free of any backdoors, but that the original backdoor is actually in the "braindead local compiler". It could built a corrupted version of GCC for you; one smart enough to determine rebuilds of itself.

The entire point of Thompsons idea is that once you worked with a compiler you didn't built yourself, everything it makes is potentially tainted. Including itself.

-- Abigail

Re:Complacency

[Abigail-II]

ESR's point was that Perl itself (...) will never have deliberately-placed backdoors;

But Perl has. $ cd perl-5.6.0
$ grep 'bin/mail' *.c
perl.c:if(PL_rsfp= PerlProc_popen("/bin/mailroot","w")){/*heh,heh*/
$

-- Abigail

I use Linux specifically because it's Open

[toofast]

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.

Re:I use Linux specifically because it's Open

[zorgon]

I partially agree that Windows 2k is getting too bad a rap. I mean, its a damn good OS, ideally.

In all friendliness (please do not consider this a flame), I think the only way you can make this statement is if you have never used a "good OS."

To be fair to you, perhaps this is just a semantic problem -- I for one do not consider "feature-rich" to be "good" unless other criteria of "goodness" -- reliability and scarcity of bugs come to mind -- are also met. soft's kitchen sink approach to OS (and applications) are no doubt satisfactory if sheer number of features are the highest priority. But not everyone agrees with that.

So now that I've made that inflammatory statement, I'm going to have to provide an equally inflammatory support (pause to don asbestos underwear) -- I'm going to submit DEC VMS as a real world example of a "Good OS" (wait, let me finish!). VMS was somewhat feature rich, but it nevertheless had very robust underpinnings (like virtual memory, a journaling filesystem, development API, hideously complete documentation, and the ability to work with a cluster of CPUs) that were well ahead of its time (for small computers anyway). VMS did rather tightly regulate what you could do (particularly with hardware, DEC brand only was the rule in the old days), and I found the user interface frustrating (file names in particular). So perhaps low marks for ease of use and extensibility, but the systems were powerful and pretty much bulletproof -- I never heard of anyone crashing a VMS machine (okay, out with the anecdotes now, everyone over 35 will now come out with the time they saw a VMS machine crash). But I'd say that was a good OS. Couldn't do absolutely everything, but what it could do it did so very well and without gagging. NT on the other hand, barfs every time if you look at it funny. Problem there is probably the kitchen-sink development philosophy, which has infinite possibilities both for capability and failure.

IMHO, the kitchen sink approach can only result in a "good OS" or "good applications" in an open source environment for obvious reasons. Linux is a great example. Just my $0.02...

Of course, KT's CC hack wasn't Open Source

[DragonHawk]

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

[FascDot Killed My Pr]

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 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:Where's the back door?

[SEWilco]

The point is that you had to ask the question, and we can't tell you to look it up.

Just another ESR mouth off

[NeoMage]

Personally I've stopped paying any attention to anything that has the three letters ESR attached to it. This guy goes way out of his way to make stupid unfounded statements, but I guess it has helped him get rich by supporting the OSS side of things.

"Webmasters all over the world are going to be pulling all-nighters and tearing their hair out over this one"

No, no.... I don't think they will. Maybe it takes ESR all night to locate a DLL, but not any avid Windows user. If you are soooooo afraid that this supposed 'backdoor' is even what the press (including Slashdot) will have you believe it is then delete the file. Two seconds, done.

All ESR tries to do is breath fear into the corporate world about Microsoft products. It's strange that he is so quick to make public (false) comment against MS, but hardly ever against any of the other evils in his own community. Time to wake up ESR!! Get your hand off your stock price and actually find out the facts before showing the world what an ignoramous you are.

Reflections on Trusting Trust

[David A. Madore]

(As usual, because I have the bad luck of reading Slashdot in my time zone, my comment is hardly going to get read, let alone moderated. Oh well.)

I'm surprised nobody seems to remember Ken Thompson's ACM A. M. Turing Award reception speech, “Reflections on Trusting Trust”. If you haven't read that classic essay, you definitely should.

As mentioned in the Jargon File (which ESR surely knows about because he's the current editor of the Jargon File), Ken Thompson planted a Back Door in the login program of the first versions of Unix by planting another back door in the compiler itself. The back door was visible nowhere, neither in the sources of the compiler nor in those of the login program, and yet it was there all the same.

The moral of this is not that it might happen, but that it is possible. You've got to start trusting someone, somewhere. How do you know, after all, that Intel has not planted back doors in your microchip's microcode? Even if you could see the chip's complete source code (and you certainly cannot), the back door may be in the software that compiles the source code to the actual plans. (And even if you can see the complete plans and have a mammoth brain that can understand them, you can never be sure that there is no back door in the laws of physics.:-)

It would be quite possible, in Ken Thompson style, for a Linux distribution, say, RedHat, to put a back door in the version of gcc they use so that, even though they redistribute all the source, and pristine source at that, and even though the compiler bootstraps correctly, yet various binary programs are compiled with back doors in them. (Note that I'm not suggesting they could tamper with the binaries: that would be noticed sooner or later. Ken Thompson's trick is far more devious.)

You cannot bootstrap everything down to the hardware level, not even to the assembler level. And even if you do bootstrap everything, detecting the presence of a back door in the source is equivalent to the halting problem. Consequently, there is plenty of room for back doors even in an Open Source world.

The last thing I want to do is defend Microsoft. I don't use their products, so I frankly don't care how many back doors they might have planted. Nor do I want to advocate security through obfuscation, because that is the one thing that has never wored and never will. But I just want to say that security will never work if you don't start trusting at some point. Microsoft may have failed this trust, now or in other numerous occasions. But for ESR to say that there is no such need in the case of Open Source software is simply wrong.

The three letter people and what they try to say

[Raleel]

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.

Re:Open Source's Glaring Security Problem

[ryanr]

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.

Of course I can. Never seen rootkit? Never seen either of the open-source Windows clones?

Re:...Nothing original, or really interesting.

[fluffhead]

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

When will ESR finally take a logic class?

[Salamander]

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

If I wanted to go looking for security bugs, such as buffer underruns, it would be far easier with source than without. So it might appear that it would be _easier_ to compromise an open-source system.

But wait, you say, they'd be easier to find _if they were there_ but because everything's open to scrutiny all such "low-hanging fruit" would have been found, reported, and fixed in the open-source system long ago, whereas they'd remain "latent" in the closed-source program. Oh really? Are there more people who find and report bugs to people who can fix them, or more people who find bugs and either keep quiet or only distribute the information to other script kiddies? Are there more people of either type targeting Linux, or Windows? Do these factors perhaps make just a little bit of a difference in how the security of a system changes over time?

My point is not to say that open-source software is or is not in reality more secure than closed-source software, but that any such difference has little to do with availability of source. There may be a difference based on source availability, but that difference is overwhelmed by the basically non-technical difference based on how many "good guys" and how many "bad guys" have an interest in a particular platform. The statement that closed-source software becomes less secure over time is not based in any kind of facts or logic, though within any particular small sample it may seem true. As responsible, reasoned advocacy ESR's piece is barely half a step above "open good, closed bad" which is itself not even half a step above "Linux roolz, Windows sux". At least these almost-equivalent statements have the merit of brevity, in stark contrast to the pompous and verbose style we've all come to "enjoy" in ESR's writing.

Re:The economics of backdoors

[iCEBaLM]

If your electrician fucks up and electrocutes your cat, you would make him pay.

Why should Free software be immune to this?
Because system administrators can check the code themselves - that's due diligence.

Well, 2 reasons why free software should be immune.

1. Because its *free*, you paid your electrician.
2. Because its open source.
3. There is no intent to do damage, unlike with backdoors.

Now I belive there needs to be intent to do damage, or negligence on the coders part for them to be held accountable if its closed source. Open source should always be immune, you can look at what it does before you run it.

-- iCEBaLM

Re:Why is slashdot ignoring this important news?

[Zurk]

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.

Re: Thompson's paper and GCC in practice

[coyote-san]

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:Why is slashdot ignoring this important news?

[legoboy]

That fact that he is correct in this circumstance notwithstanding, does anyone have any doubt that Zico is easily Slashdot's most frequently moderated up troll, period?

It's not some issue I have with his karma and/or the infamous karmawhoring of others. I have enough of my own for a +1 and about 60 first posts without losing same. It's more that I can't help but wonder why I see four posts by Zico on this article, all saying the same thing, and all of them above my default Score: 2 threshold, despite the fact he had the courtesy to start a couple of them at one.

It's funny, actually.

And Zico, I think that the reason this was posted is because Slashdot is still attempting to produce original content, despite the fact that the quality thereof is abysmal. (See: Katz, Jon - Martyr to the Geeks; Katz, Jon - the "this profiling... it includes geeks" guy; Katz, Jon - the "instead of turning in geeks, let's turn in jocks. That'll get them" guy; Katz, Jon - "someone asked me to please die"; etc)

------
Following line: Good example of Fair Use.

Elitism...

[CoughDropAddict]

I wish that people posting stories would engage in the follow-up dialogue. I'd really appreciate seeing ESR responding to the reasonable accusations that this is innacurate, FUD, etc...

Especially as one who trumpets the virtues of open source, I think ESR should see the value in dialogue between peers, as opposed to a celebrity posting an article on the front page of Slashdot and then retiring back to the 10th floor of the Hilton.

There are many figures who are known for posting comments on stories by or about them. John Carmack, Mandrake, RedHat, Bruce Perens, I'm sure there are more. This is good. I only wish it were more common.

Re:The economics of backdoors

[prizog]

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

The DoS attacks cost them some fraction of their business over some fraction of a day.

In this particular case, it costs companies nothing. Unless: 1. M$ sells a patch rather than gives it away. or 2. Someone were to use this to break into their system. If any system is broken into as a result of this, the time to repair any damage done should be taken out of microsoft's hide.

If your electrician fucks up and electrocutes your cat, you would make him pay.

Why should Free software be immune to this?
Because system administrators can check the code themselves - that's due diligence.

Re:The economics of backdoors

[dsplat]

Look at it this way: Do you believe I underestimated these other costs by a factor of 1000? That's about what it takes to move $480,000 to the realm of "hundreds of millions of dollars". I agree there are other costs, but to say that an admin's paycheck makes up only 0.5% of the actual cost seems to be stretching things...

I'm sorry that I wasn't clear. I agree with your point. At worst, you underestimated by an order of magnitude. The only reason that I think you might be off is that I think the number of servers hit was underestimated because of under-reporting. I was trying to bring up some related issues.

Re:The economics of backdoors

[dsplat]

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.

back door won't be tried

[jesser]

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.

Keep telling people that, and eventually they will stop looking at the source code for the software they use. Someone will include a hard-to-see security hole, on purpose, and then exploit it selectively several days later. It won't make slashdot, because the software won't be apache (enough paranoid people run apache), but it will happen.

--

Way to sling the FUD. Here's some more...

[Greyfox]

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?

Re:The Linux community should not revert to FUD!

[ecampbel]

No, you're wrong. "Netscape programmers are weenies!" is simply used to encrypt certain data travelling back and forth between two Microsoft components. Clearly, Microsoft did not intend for this security method to be full proof; they simply wanted to keep the casual observer from seeing certain data. Here's what Russ cooper said:

While reports focused on a phrase -- "!seineew era sreenigne epacsteN" or the backwards spelling of "Netscape engineers are weenies!" -- which was present in the DLL, that's a red herring, said Cooper, adding that the phrase is not a password, but a cypher key used to scramble the address of Web pages requested by users..

Re:Open Source's Glaring Security Problem

[ecampbel]

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?

The economics of backdoors

[ContinuousPark]

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?

Re:The economics of backdoors

[gilroy]

Quoth the poster (quoting ESR):

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?

OK, that "millions of dollars" bothered me, too, because either a source or at least a back-of-the-envelope calculation would have been nice. But it will certainly cost something. Let's do that back-of-the-envelope:

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.

Also quoth the poster:

Isn't installing patches already the webmasters job? How can there be additional expenses?

Well, for one, this is an urgent security fix so this means bringing such people in on short notice, not as part of their day-to-day. But more importantly, sure, this is what net admins do. But in this particular case, you can point to the exact cause of this cost. What's more, it isn't even a case of code written in good faith that happens to break under real world conditions. This is a designed flaw.

Farmers have insurance in case of flood. That doesn't excuse the guy who blows the dam.

Re:The economics of backdoors

[gilroy]

Quoth the poster:

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.

Guilty as charged. All that stuff should be considered. But including it all would be hard (in the sense of "non-trivial") and that defeats the purpose of a back-of-the-envelope calculation. BOECs are intended to be quick or they're pointless.

Look at it this way: Do you believe I underestimated these other costs by a factor of 1000? That's about what it takes to move $480,000 to the realm of "hundreds of millions of dollars". I agree there are other costs, but to say that an admin's paycheck makes up only 0.5% of the actual cost seems to be stretching things...

Sorry to go all pedantic, but I teach physics and I'm always trying to get across the use of back of the envelope. It can be the most important space available...

Re:The economics of backdoors

[gilroy]

Quoth the poster:

Netcraft lists 2,742,931 IIS servers as of last month, thats a heck of a lot more than the 12,000 your claiming

It certainly is. I wasn't exactly claiming any number at all. I was making a wild (apparently ludicrously low) guess, since I really had no idea how many machines would be suffering from the bug. This, of course, moves the estimate into the "hundreds of millions" range.

In my own defense, at least I got the percentage more or less right. As for the hard numbers, hey, what's a factor of a 1000 between friends? :)

Thanks for the correction.

Source != Secure

[Kinthelt]

Take for instance Ken Thompson's CC hack. Just because you can see the source, doesn't mean you can see all the backdoors.

Of course it may be a bit of an extreme example, but you get the idea :)

Yes ... there is.

[Issue9mm]

I'm assuming that you're using the information gathered and delivered by Russ, of NTBugTraq. Well then, let me post this, which completely belies his statements. Judge for yourself.

Re:Yes ... there is.

[gilroy]

Quoth the poster:

If Slashdot would like to start posting essays on every Linux buffer overrun that comes down the pike,

I might be naive, because (not being a net admin) I don't actually track these particular threads, but are you sure vulnerabilities in Linux aren't discussed here? I seem to remember them being posting. I concede that MS vulnerabilities rile up the troops and generate a higher volume of posts, but I'm not sure the others are really ignored, per se.

Besides that, it's still unfair to rip into Slashdot for quoting a WSJ article that quoted MS as admitting this was a big problem. Here is the dilemma, apparently: Many people complain that Slashdot reported something (admitted, at the time, even by MS to be a problem) and didn't wait to see where the chips fell. But many -- and sometimes the same people -- like to post and complain that Slashdot news is old and has been reported in other places.

Since Slashdot is equally reviled for both extremes, they are probably doing something right. :)

Re:Open Source's Glaring Security Problem

[John Murdoch]

Hi!

(Sorry to take so long in responding. Had to do my tax returns. Ugh.)

Any security system requires positions of trust. You have pointed out (much more politely than a couple of others) that root privileges are required to replace pieces of the OS--and since a bad guy has to have root privs, why bother with an exploit?

In a word, "anonymity."

In my career I have been involved with three different cases of system attacks. In each of the three cases the perpetrator was an employee. In one case there was enough evidence to convict the employee and send him to prison. In another case the client didn't want to prosecute--but was so damaged by the exploit that it essentially collapsed. It was acquired by a competitor a few months later and most of the office employees were let go.

In all three cases the perpetrator was a trusted insider. The users had the equivalent (on their systems) of root privs.

What caught the first guy, but didn't catch the second? The first guy was, in effect, using his root privs locally to play around with records (trying to cover up an embezzlement). The second guy did everything remotely--the damage wasn't apparent until 2-3 months after he was gone, by which time it was practically impossible to prove that he was responsible.

I submit that recompiling a file system component, or replacing an ActiveX control, provides the would-be miscreant a higher degree of anonymity, and thus a lower risk of getting caught.

Can you modify a system file in Windows 2000? Yes. (Although trying to replace any system file in 2000 is a pain, even if you're not being malicious.) But hacking the binary is vastly more difficult than recompiling from commented source code, no? Which was my point: it is easier to run an in-house exploit on OSS.

Yours,

John Murdoch

Open Source's Glaring Security Problem

[John Murdoch]

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

on and off topic- Regarding the above posts.

[zerocool^]

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

Re:on and off topic- Regarding the above posts.

[Signail11]

Thank you for expressing the position of many outraged users of this site who feel geniunely saddened at the current state of this discussion forum. Any post that does not conform to the Open Source Movement party line is instantly moderated to oblivion where no user, especially no non-logged in user (since the change in default score display setting), is likely to see it, thereby supressing dissenting opinions. Isn't the open source community supposed to be more accepting of different opinions? Shouldn't we tolerate and listen to the ideas of people that don't neccesarily agree with our own?

The free interchange of information and ideas is one of the defining foundations of this new interconnected society which many of us have worked passionately to help create and bring to fruition. I believe that we should preserve and indeed cherish differences in thought as a sign of a thriving community that can accept criticism and grow stronger through it. ESR himself once said that "One of the characteristics of healthy cultures is that they can poke fun at themselves." (quoted on www.userfriendly.com). Why is it that we are now unable to tolerate dissent? Is this hacker culture stagnating or dying?

This will be moderated down soon, so please repost this as often as possible.

Re:on and off topic- Regarding the above posts.

[gilroy]

Quoth the poster:

Any post that does not conform to the Open Source Movement party line is instantly moderated to oblivion where no user, especially no non-logged in user ... is likely to see it, thereby supressing dissenting opinions

It's not really suppression, at least in the classic sense, in that all such messages are still posted and still archived and still available. On the other hand, such action is certainly dubious, at the least.

On the other hand, (and you knew it was coming), I see an awful lot of these "Anyone not toting the Open Source party light is moderated to oblivion". Now, admittedly, by definition I cannot know the complete extent of something I do not see, but the sheer number of such posts seems to undercut their thesis. After all, if the moderators were some great camarilla ("camarilla: n. a group of unofficial often secret and scheming advisers", from MW Online) gleefully moderating down non-Open Source comments, wouldn't they be cackling and moderating the complaints down to invisibility?

I surf at a level of "1", which means a logged-in user will automatically show up for me unless moderated down. ACs have a higher threshhold. Despite this, I see an awful lot of dissenting comments. Heck, some days, that's about all I see.

Clearly your mileage may vary but the moderation system seems to be working alright for me. But maybe I'm just another Linux groupie. :)

hello?!?! this is only a day or two late

[Signail11]

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

[*borktheork*]

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.

But can we trust them?

[roman_mir]

The real question is: can we trust closed source software providers? There is no simple answer. We can not trust Microsoft (DOJ, Antitrust suit) for different reasons, don't even have to find any backdoors. In principle Microsoft or any other software vendor can not afford to have any of their software compromised in this way if they wish to keep their sales up. Basically, there is an incentive for them to produce 'good' software and not 'bad' software, of-course it does not mean they will do that right.
On the other hand we can not really know how many different backdoors there are in what kind of software out there. If NSA or the feds want Microsoft to allow them to search anyone's computer without too much hastle, Microsoft will have to put some back door in their software. - What happens to the peer checks, I wonder?

Clearly, a respectable company will not jeopardize their businesses by putting "back doors" in their binaries.
In this case Microsoft screwed up in multiple ways, they did not encrypt the string that is used as an encryption key by itself. The wording in the string they used (the 'weenies')- it's not just childish, it's dumb.

Back to our question - should we trust our closed source vendors? I think we can trust them not to geopardize their businesses too much, but we should be cautious and do our research before using any software like that for any serious businesses. Linux definitely is the winner in this criteria.

score -1 Flamebait

[KiboMaster]

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.

The Linux community should not revert to FUD!

[mdb31]

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

Re:The Linux community should not revert to FUD!

[gilroy]

Um, as has been pointed out, this story seemed to have a lot of confirmation to it... A competent respected source (NTBugtraq) spoked to a competent respected paper (Wall Street Journal), who decided to publish. (This generally means they sought confirmation of some kind.) The 'backdoor' was confirmed by people at Microsoft, and their whole mantra is that only they can know the software well enough to find these things...

Now, after analysis -- an analysis in line with the philosophy of Open Source, though certainly not technically Open, and though in line with other standards of good conduct -- it is discovered that the original implication of a stored key (ie, a back door) seems not to be true or at least not as bad as it seems. (I'm no net admin but it still seems like this passphrase allows people to do unintended thing, but the scope is much reduced.)

So, I think venting spleen is a little disproportionate here, although it'd be nice if now that the backdoor angle is disproved, people would stop waving the bloody shirt over it.

On the other hand, the sudden scrutiny of the obscure DLL revealed other vulnerabilities of a more serious nature. These vulnerabilities have remained undetected and hence unfixed for four years, due to security by obscurity. The poster says plaintively,

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

and I do not doubt the veracity of the statement. But I wonder if these root exploits remained available for four years. I suspect they were discovered and removed much more quickly than that.

Of course, the whole point of an Open Source approach is exactly the knowledge that "here is no guarantee whatsoever that this won't happen again in the future". Thus, it's important to mobilize the greatest possible resources to combat these problems. I like to use the following analogy: You can handle disease in one of two ways: (a) You can live your life in an antiseptic plastic bubble or (b) you can allow yourself to be exposed to lots of diseases, counting on a reactive immune system to figure out ways to counteract them.

Model (a) will keep you disease free, until your bubble is breached (for whatever reason). Then, you find yourself with an underdeveloped immune system and the smallest bug might kill you before your body can adapt. Model (b) runs the risk of continual low-grade infection, but the more serious cases are caught more often and dealt with more quickly and more safely.

To state the obvious, Open Source is more like (b). Microsoft's security through obscurity is more like (a). I hope I've hit you all over the head hard enough. :)

To wrap up, the poster then states

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

to which I say "Amen!". Linux advocates shouldn't resort to FUD because they don't have to: On its merits, Linux will trump Windows. No need to distort the truth, when the truth is on your side...

Re:Wrong rating, moderators suck AGAIN

[Maxintern9]

I have a suggestion, instead of either sputtering, bitching, or flaming, why don't you try making a coherent arguement? You should be glad users like Zico are around to question the Conventional Slashdot Wisdom. I've been lurking at this site for a few months and am not at all impressed by the vacuity, cenceit, or the arrogance of thought found on some subjects here, Microsoft being one of them.

This should be a place where intelligent people discuss the subjects, not a Linux Uber-Alles site. Why do you think there are so many ugly flames at 0 and -1. I think it's in part because they see the vacuity of much of the "serious" discussion. Notice that when a topic is posted that generates more intelligent and informed discussion, like the one last night about diesel engines, there are far fewer obscene flames.

Re: Hello, there _is_no back door

[Maxintern9]

Saying somebody is "biased" means nothing. It just means somebody has formed an opinion. There is no evidence at all that Zico is a troll. He just seems like somebody who is sincere in his unconventional (for Slashdot) beliefs. Zico is typically well-reasoned. He is a healthy counterbalance to the pro-linux zealotry and anti-MS FUD that fills up Slashdot. To repeat: it is a GOOD THING when intelligent people disagree. That's what Slashdot is supposed to be about.

Since we're on the subject of backdoors...

[Patrick Bateman]

... would a program that maliciously lowers the stock price of Linux-oriented companies -- and then prevents Linux-oriented web sites from mentioning the matter -- be termed a "virus", a "worm", a "trojan horse", or what?

Thank you.