Slashdot Mirror
Microsoft -- Designed for Insecurity
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),
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
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?
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
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.
-- Who is the bigger fool? The fool or the fool who follows him? --
sorry to rain on yer parade but :
;see here MS ENGINEERS: BUFFER OVERFLOW
/_vti_bin/_vti_aut/dvwssr.dll?";
.dll to /msadc directory, and with
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
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
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
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.)
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
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?
"All the things one has forgotten scream for help in dreams". Elias Canetti
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
~zero
insert clever line here
sig?
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.
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...