Slashdot Mirror
On The Costs of Full Security Disclosure
sasha328 writes "I found reference to this email on the LWN.NET site which was sent to the SecurityFocus mailing list. It asks a very valid question about how much you can disclose before malicious virii can be possible."
I am going to get flamed here but, whatever. Microsoft provided a patch in this case, its just getting millions of users/sysadmins to download it. I do fault them for security problems with IIS. It seems at least once a week there is some issue on bugtraq about IIS..Half those infected probably dont even know what IIS is or that they are running it.
So, since releasing a security patch is equivalent to giving the blackhats full disclosure, no software should ever be patched again. Instead it should be understood that anytime anyone finds a security hole, they need to be quiet forever.
-f
www.blackant.net
I don't think I mentioned eEye's behavior at all. My response was to the e-mail referenced in the posting. I didn't mention how anyone does it now, only how I think it should be handled. I don' really have any knowledge of "how it's done today." Perhaps you can let us know what you are baseing that statment on so the rest of us will know as well.
--Ty
You can argue that eEye did the right thing by publicizing this vulnerability, but I personally am getting a little tired of them adding weapons to hackers' arsenals.
I could equally argue that security is a choice; would you use or endorse a product that has had a bad rep with regards to security and the necessary actions required to correct security flaws?
Considering that the vulnerability that Code Red exploits could have been fixed months before, I as a system administrator myself have to ask the following...
If you were to survey those affected by Code Red, you would probably get a lot of "NO" responses.
These are probably the same individuals or companies that don't take security seriously. Security is a lot more than just applying patches whenever vulnerabilities are found. It should influence how your network is designed, how the services are partitioned on that network, and what information is allowed to travel in and out of your network, etc.
<plug for egress filtering>
If people actually took the time to look at their network architectures, they probably would be hard pressed to find a valid reason as to why their web servers would need to initiate a connection to another web server outside of their network.
</plug for egress filtering>
I therefore submit that full disclosure of the IIS vulnerability had no real influence as to the spread of Code Red. This problem could have been avoided by applying a fix, but some parties made a choice to do nothing. The spread of Code Red is a realized consequence of that choice.
Yeah, but how much time?
The shortest turnaround I've seen is about 12 hours for someone else to figure out a hole that didn't have all the details published initially.
These many arguments that "full disclosure pushes Microsoft along in releasing the fix" have no grounded basis in reality.
Sure they do. That is how it happened. Microsoft used to be one of the companies that would hide bugs, slipstream fixes, try to hide details, etc.. this was about 3-4 years ago. They are much better now. Guess why.
Besides couldn't it be possible to rile up the media hype necessary WITHOUT giving information as to how the exploit occurs?
Nope. The reporter wouldn't do a story with no details. There is no story without details. And the bug has to be sexy enough, too.
The only thing the average user needs to know is "it's a security hole, it's bad".
No, they also need to know if it affects them, and what does "Bad" mean. If they don't believe that it is really bad, average users won't bother.
If anyone, I blame Microsoft - they wrote buggy software
To be fair, do you blame the Open Source community for writing buggy software?
I'm all in favor of full, detailed exposure of exploits - how they're done, why they're possible, and possible steps to fix them.
Just because the exploit only hits MS systems doesn't mean that ONLY MS and "blackhats" should know the details. The more people that know the details of HOW these exploits are possible, the better - as these people will not only put more pressure on MS to actually FIX the problem, but they will also be exposed to the reasons WHY the MS product was vulnerable in the first place.
Some of them might even suggest ways of improving the situation. But that's in a perfect world, and this world is far from perfect.
Just telling people "There's an exploit in IIS that allows malicious intruders to use your system(s) to infect others, install a backdoor, and potentially use your system(s) for other purposes" isn't enough. I know as a system administrator, I'd want to know what port the backdoor was put into, so I could secure it at the firewall. I'd want to know how the exploit was executed, so I could potentially filter out the infection requests. I'd want to know exactly WHAT was making my system insecure, and where, so that in the absence of an official fix, I could work my own fixes, to secure my own system(s) against known intrusions.
Microsoft already fixed the problem when eEye released their press release.
.ida and .idq mappings on your web site, etc.
;P
So exactly how did this "pressure" help?
In this specific instance not at all - as there was already a patch to fix the problem - but what if this had been an unpatched vulnerability? *That* is where the pressure *can* help.
I was arguing a generic point, while you're dealing with a single specific instance =)
Furthermore, I don't think you understand what Full Disclosure really means, verus Responsible Disclosure.
Full Disclosure, IMHO is making all the details surrounding your findings available to the public (in this case, "the public" would probably only consist of sysadmins smart enough to read security bulletins, as Joe Consumer probably wouldn't know the right sites to visit, but the point is that if he did, he could read about it.).
Now, this "Responsible Disclosure" *seems* to mean not telling "the public" ANYTHING about the exploit - even the fact that it exists - and only telling the manufacturer about it. Now, admittedly, in a proprietary piece of software, the only fixes *internal* to that program could possibly come from the manufacturer, but when dealing with networking issues, there are other steps that can be taken by competant sysadmins. Under the "Responsible Disclosure" policy, these sysadmins wouldn't be able to protect their systems until the manufacturer decided to release a patch. Often, by that time it's far too late.
Of course, I could be wrong. =)
Nobody is saying that they won't release info telling you what piece is broken, what port the information is coming in, or some sort of tag identifying the issue. (For instance the query string clearly showing up in everybody's web logs)
They're also going to tell you that it's the index ISAPI filter, and you know you are vulnerable because you have the
Good. That's the sort of information we need in order to take action to protect ourselves. Where the problem lies. What the earmarks of it are. What issues it raises for your network's security. How to combat it.
What they don't need to do is give out a detailed description of how you would write Assembler to take advantage of the hole.
I consider this to be the proof of the theorem, myself. In order to prove the vulnerability exists, you need to show how to exploit it -- if an exploit exists, dissecting it's workings can provide a solution. Sort of like the process of finding an antivenom for a new strain of poisonous snake generally starts with a sample of the venom itself.
Know thy Enemy.
And lastly, what exactly do you think "Security through Obscurity" actually means?
Basically "If we don't publicize the details of a possible exploit, noone will exploit it" -- collary to not disclosing a found vulnerability to the public, instead keeping it a secret, told only to the manufacturer.
The simple act of keeping the workings of an exploit a secret won't stop "blackhats" from using it. People seem to forget that "they" have an information network too -- one that includes code, examples, and no restrictions on who has access to them. In order to keep the damage minimal, ours needs to be as good, if not better. Throwing up walls and saying "You can't know about this" doesn't help anyone -- sure, it may prevent a few kiddies from finding what they need to make an exploit on "whitehat" security sites -- but it won't prevent them from picking it up at easily accessible "underground" sites - and most of all, it won't stop them from using or deploying worms or viruses - they're going to do it anyway.
Keeping the details of how an exploit works a secret only hurts those who would use that information to protect themselves.
people can be unaccountable.
actions are neither accountable nor unaccountable.
Uh, continuing with the same analogy, I would hardly put the eEye exploit in the same difficulty level as "staring at the door".
I'm a believer of a grace period. However, my only hesitation, is this: say you give a big vendor, perhaps Microsoft, notice that there is a serious hole in one of their products, and that you will give them a fixed amount of time to do something until you post full disclosure to Bugtraq.
Microsoft has enough lawyers that seem to have plenty of free time on their hands, that my bet would be that they'd try to shut you down, and prevent you from making the promised disclosure.
These tactics scare the bejesus outta me, as far as their implications for security information distribution between professionals.
The crackers and virii folk have, or will have, the information sooner than the admins. Anything that further delays getting me information about potential threats to my network, I regard as irresponsible.
Um, the word "viri" in Latin means "men." (Plural of vir, "man"). The *English* plural of virus is *viruses*. Try again next time, nitwit.
And you actually believe what this guy says? He's a security consultant, and he can't punctuate?
So that the NSA (and microsoft) had a secret backdoor into all IIS servers around the planet. Quite a nice little deal the two have made. </conspiracy theory>.
My hunch is that, given the fall in the overall level of opinions posted in Slashdot over the last months, Hemos is dilligently bringing up such absurd questions so as to educate people who, although misinformed, can spot good advice when exposed to it. :)
Arguments against full disclosure are like arguments against sex education. Sure, there is this thing called 'sex', but we aren't going to tell you how to do it, or how to protect yourself. The whining about eEye overlooks one important aspect: CodeRed was not written by a script-kiddie. It may have been deployed by a script-kiddie, but it definitely was not written by one.
Let's say that eEye just released an advisory that said there was an overflow in the processing of default.ida. No more information than that. It would not take a skilled hacker very long to find the buffer overflow, and then exploit it. It doesn't matter if eEye says little or everything. The skilled hackers are going to find the hole themselves.
I believe the current system works as well as it can and should. When somebody finds a bug, they usually report it to the company, let them play with it for a week or so, work up a patch or workaround, and then it is posted publically on Bugtraq or some such list. Then somebody might write a proof-of-concept or an exploit, but will leave one part intentionally broken here or there so only people that can read the code and understand what is going on can fix it and use it. Bugtraq keeps companies accountable for their products security. Without it, there would definitely not be the same diligence at most companies responding to security concerns.
If you are going to teach sex, don't just say 'save it for marriage'; teach about condoms so people aren't caught with their pants down.
I admit I don't personally have such a story. However, you have to admit that this result is unlikely - why would Microsoft announce that they're not going to fix the problem? Much more likely is just silently ignoring it.
Doesn't this go against the other point you were making, though? In a way, the writing of exploits prevents Microsoft's having to spend so much money on determining which ones are "real" - if there's an exploit publicly available, it's definitely real.
I metamoderate all Redundant and Offtopic moderations as Unfair.
I think that if people are willing to accept the limited amount of info about the inner workings of commercial software that companies like Microsoft provide, they should be happy with nothing more than an explanation of "here is the latest update, apply it". Even ISC.org is getting to a point where they will limit the info they give out immediately on fixes for BIND because the admins couldn't get the fixes in place in time before the hackers got word and started breaking into numerous sites. IIS administration would devolve into applying the patch of the week...oh, never mind it already has.
If you don't demand more from their software, you deserve less. In all honesty, there are heaps of people who compile and install Apache and barely know what the code is really up to, making them no better than script kiddies. However, if you so choose to see what the inner workings of Apache are, it's no trade secret. The difference between the blind Microsoft installers and the blind Apache installers is that the Apache developers swarmed to fix the trouble when they got hit, where Microsoft wonders how many people noticed the bug to see if it's worth their royal while to fix it. True, the patch for this problem had been out a while, but many complained that it did not do the trick for them, and more is surely on the way.
"Beware of he who would deny you access to information, for in his heart, he dreams himself your master."
...compared to total non-disclosure. However, by considering only those two possibilities you fall prey to the fallacy of the excluded middle. Partial disclosure - e.g. of risks and countermeasures but not of mechanics, or preferentially to trustworthy security professionals - can provide the same benefits vis a vis total non-disclosure without total disclosure's problem of teaching the bad guys how to exploit a vulnerability.
Slashdot - News for Herds. Stuff that Splatters.
It was not till exploits started being written, and even further after there were some major epidemics, that unix admins and programmers tightened up on security. (sendmail? ftpd? bind? sheesh!)
Did Microsoft learn anything from these previous incidents? Yes, but very little. The greater cost of cleaning up Microsoft software reflects the widespread use of it by relatively clueless lusrs. But this widespread use means that "total cost" gets spread across a bunch more people. Was the disruption disproportionate to the laxity that Windows sys admins and Microsoft programmers had showed immediately prior to this incident? No, it was a bargain. And trust me, the cost of Code Red cleanup is a bigger bargain if it means that people will wake up to the importance of security in the future.
Right now in the wake of the dot-com collapse, an outbreak of Code Red means we can't get our email for a day or something. But when we are truly dependent on the net in the future it is imperative that we are ready and history shows us that we would not be without a few swift kicks in the pants like this. As I mentioned in another post, I don't think Richard Smith is sophisticated enough to be a leader on issues like this.
Also, "affective" actually did leave some ambiguity since you used "effective" correctly in the same post and since using "virii" can evoke some emotions (as would be implied by "affective").
And I'd be a Libertarian, if they weren't all a bunch of tax-dodging professional whiners.
Berke Breathed
If the only action taken is to warn Microsoft, someone will discover the problem elsewhere, eventually. In the meantime, Microsoft is unlikely to take the complaint seriously - after all, the damage is only "theoretical", right? Now, it's a fact that there are a lot of inattentive, lazy sysadmins out there, many of whom are running IIS, and that's why they haven't all applied the patch yet - but at least with this in the news, it's harder for them to avoid it. How many would bother to apply the patch if there weren't any obvious benefit to doing so? Many might choose not to disturb a working installation.
Personally, I think that the only software that can ever hope to be secure in the real world is built like a tank. Use a language or library that makes it impossible to have buffer overflows; assign permissions to everything and never give out more than you need to; etc. But in an environment where exploits are only theoretical and only announced to the entity responsible for fixing them, you have to admit that companies like Microsoft will be very slow to fix them.
I metamoderate all Redundant and Offtopic moderations as Unfair.
The discussion already happened on Bugtraq. If you're not on bugtraq, you don't have a qualified opinion on the matter anyway. Thank you for ignoring this slashdot story from now on.
I found a serious design flaw and major security vulnerabilities in their systems. I attempted to notify the company, and got no response. I posted 'Partial Disclosure' to a security mailing list with just an outline of the problem and notes on where they had weak security, but I did not post details to exploit them.
The company did not respond.
Three months later, another person independently found the same issues, confirmed with me that these were the same holes I had described in my vague message, then he posted 'Full Disclosure' to the same mailing list.
This time the vendor responded, and toke action to notify users and fix the problem, nearly six months after I first notified them.
I do not deploy Linux. Ever.
"viri" is Latin for (the) men.
...as the guy who got his name all over the news because he claimed to have helped the authorities track down the guy who wrote Melissa? His big discovery was that you can open the Word document in a hex editor and see the document GUID.
The problem is not "lazy sysadmins". I'll bet most of these machines didn't even have one. Most sysadmins do nothing more than think about the patches they'd like to install to prevent having to clean up messes later. And another impediment to good administration is managerial environments that don't encourage pro-active administration, i.e. they don't trust the admins to do their own job. Where this kind of trust comes from, I don't know. The lazy admin is a myth. Admins aren't paid to be lazy, and the lazy one's wouldn't last. Breakins occur to sites whose admins hands are tied, or to sites that in effect have no admin ("gee whiz I'd like a webserver and this microsoft one seems easy...ooh neato it's up!"). Blaming admins for breakin's is like blaming car problems on auto mechanics. "Yes all those lazy mechanics out there didn't wan't to tune up their cars...they'd rather play quake". Absurd. Most mechanical car failures are probably due to owner neglect, not mechanic neglect (other than what is generated by not seeing one). Dentists don't cause cavities. Admins don't cause breakins. Moreover security isn't typically a function that is even *expected* of most admin jobs I've seen. I've practically begged every outfit I've worked for to develop a security policy, check passwords, etc. and it's a small minority that cares- "there are other irons in the fire". Security is a hard to quantify benefit. If you keep the alligators away, who is to know how bad they are? If the alligators are discrete as well, all the more a problem. -florkle
-- "If you need to shoot, shoot. Don't talk" -Tuco
In fact, Marc (the one who posted the original warning from Eeye) included a link to the already available patch in his warning. And he waited another three days to post the exploit code.
Full Disclosure is not about giving tools to script kiddies. It is about giving incentive to vendors, and peace of mind to White Hats. --Rabid Mongoose Boy (very rabid over that shite which was posted on bugtraq)
NTCrash does more than make random calls; it stores what it's doing before it tries it, and after the reboot, avoids doing that again. So after a while, and many crashes, you accumulate a log of new vulnerabilities.
There are later variations on that theme which find more subtle holes. Rather than just making random calls, it's more useful to permute valid calls slightly. That's been tried successfully.
The classic paper on this subject is The Tao of Windows Buffer Overflow, from the Cult of the Dead Cow.
Considering that all this was known five years ago, there's no excuse for Microsoft products having any buffer overflow vulnerabilities. This falls between "gross negligence" and "reckless endangerment". Where's the plaintiff's bar when you need them?
Look-- the fact of the matter is that what gets publicity is only the tip of the iceberg. Black hats who are serious about causing trouble and committing crimes are doing it without letting anyone know. What we hear about are only the things the white hats figure out and script kiddies exploit. I absolutely *guarantee* you that there are holes out there that MS knows about and most of the world doesn't because we haven't found 'em yet. And some BH is exploiting them right now.
The Register ran a story a while ago about the Russian mafia tapping into internet banks for MONTHS and no one knew. They used common holes that should have been patched. If Code Red and it's ilk are what it takes to get lazy admins off their asses, then so be it.
Here's the important point: As the world becomes more and more dependant and tied to the Internet, simple security failures HAVE to be eradicated and software companies who are responsible for this kind of trash MUST be held responsible. As far as I'm concerned, every SysAdmin who was hit by this should be fired yesterday. It's intolerable.
Barely half the people out there bother.
.ida service and applied the patch when they were confident it wouldn't break their systems.
No offense, but have you actually installed a Microsoft patch?
It's not like a Linux patch where you can look at all of the files which are being updated. This thing comes in as a huge monolithic package which you either install in toto, or not at all. You have no way of knowing all the changes it is going to make to your system. You can't back it out after you do it. It may cause some special program you have running on your system to break. It may cause some mundane, MS program to break. You may be royally screwed if you install it.
A responsible admin will setup a mirror of the production system and install the patch on that system. He will then test all of the applications running on that server. If there are no problems, then he will install the patch on the production system--and hold his breath hoping that it still works because he is never quite sure the patch will work the same on the production system. (Sometimes one gets an error installing a patch and all hell breaks loose. Sometimes it just seems to work differently on different systems.)
This all takes time and effort. I hope it's not month end. I hope the boss isn't yelling for the new servers to be brought on line right now. I hope everything is running smoothly (yea, right).
I'm amazed how many people are blaming the admins for this problem. It's the irresponsible/lazy admins who just go and apply the MS patches when they come out without testing them first. When this hole started to be exploited, the responsible admins removed the
...discussed many, many times on Bugtraq.
Elias Levy already summed it all up:
"Well, the world chances. I am not so stubborn to think I will always be right or will never change my opinion on this matter. A little reality check every once in a while is good. It also allows some of the newer members of the list to understand the philosophy behind the list. Now we stop flogging a dead horse and take you back to our regular programming." http://www.securityfocus.com/archive/1/203625
this post will get a zero. It kinda remins me of trying to get a girl that you really like in high school. If you tell everyone, you're fucked. If you tell her best freind, you're really fucked. If you tell her.. well, you might just get rejected. so you try and peek at her in the changing rooms. right? It's obvious to me that a full disclosure policy is a predictable reaction to so many software companies (and car companies, and...) just playing blind to something they already know. Without sharing a wonderfully utopian idea such as everybody being able to share EVERYTHING (I tried it in high school) the "open" idea only works up to a certain scale (like one person..and even then). What we should all be doing, instead of shitting on, or laughing at microsoft software (some of it.. some.. is really neat) is taking our time to write well structured, organised, and documented software. (and car parts). It seems we all like to stick with the underdog and not be the big bad wolf. but.. we all helped IIS become the most widely (geographically) used software out there. and why not help it become the best? well - cause of the high school syndrome. well that and people who code on amphetamines.
Why is slashdot giving wind to this troll?
This guy is woefully misinformed, and completely stupid.
Anyone who is subscribed to Bugtraq knows that eEye has already responded to him, and the bottom line is that Code Red is not based (in any small part) on the eEye security bulletin.
This proves that the guy is completely wrong.. because Code Red wasn't based on the eEye bulletin, that means that the "black hats" already knew about the vulnerability.
Like scientists, security professionals rely on an existing body of work. If the only people who had access to this body was the vendors, it would slow down the white hats, making the entire situation worse, not better.
Please do not feed this troll.
...instead of a tap on the shoulder. Some companies need some "convincing" to make the necessary changes in a timely manner. Microsoft is definitely one those companies.
Unrepentant bullshit. Microsoft is very good at getting fixes out. Some bug-hunters expect a 2 hour turnaround time on their reports before "forcing MS to fix this by going public". Eeye even says that MS was quick in putting out a patch to fix the hole. The vast majority of bug hunters that actually take the time to work WITH Microsoft say that MS is quick in getting patches developed and in the hands of administrators, where they aren't applied (but that's a different story). Where's the sledgehammer? Can you support your claim with any evidence of any kind, or is this merely Yet Another Case of Uninformed Microsoft Bashing?
Knows the outcome of this argument already. I cannot understand why it is that its being debated all over again.
Full disclosure is needed to keep the software companies honest, and to ensure that admins are able to test that they are or are not vulnerable. It allows IDS systems to be updated so that admins can be alerted when an exploit is attempted...
This whole thing was debated on bugtraq... It was a thread that was shut down pretty quickly too... Why waste the space here?
Why do you assume that eEye was the only group of people on the entire planet that found (or would find) this vulnerability?
mp
"The secret to strong security: less reliance on secrets." -- Whitfield Diffie
(Sung to the tune of Mary had a little lamb).
And I'd be a Libertarian, if they weren't all a bunch of tax-dodging professional whiners.
Berke Breathed
I thought the patch was already available when Code Red started spreading. Sorry, but whyle delaying the full disclosure can slow down the virus writers a little, it's not going to make lazy sysadmins apply patches to their servers any faster.
First of all what does this have to do with code red? The virus is self replicating and the creater was using a, from what I've been reading, unpublished exploit. After the first 50, 60, or some small amount of computers are compromised the thing pretty much runs itself. Theoretically this could have all started with manually cracking one computer and no human intervention after that. Not publising would not have stopped the spread. Its not like 20,000 little crackers were tirelessly manually installing code red on a zillion different computers and then telling their friends how to do it. At least if the exploit is published, the poor slob who gets hit with this virus first has some idea what to look for. IIS is out there and you can't stop people from reverse engineering it no matter haow many laws you pass. The best wepon we have is to keep the "good guys" as well informed as possible. I want to know when the vendor knows, maybe I can't fix it but I sure as hell don't want to be flying blind. < sarcasm > Yeah, lets intentionally limit the information I have access to so I can be even more unprepared when a virus hits.< /sarcasm >....riiiiiight good move.
BOFH, My model for being a sysadmin :)
Perhaps more important is the weird coincidence that the e-mail author's initials are RMS!
How many privately reported bugs have gone unfixed just because Microsoft thought it was too obscure to fix?
Microsoft already fixed the problem when eEye released their press release.
.ida and .idq mappings on your web site, etc.
So exactly how did this "pressure" help?
The only "pressure" was on admins who learned that they should read these security bulletins and actually apply patches.
Furthermore, I don't think you understand what Full Disclosure really means, verus Responsible Disclosure.
Nobody is saying that they won't release info telling you what piece is broken, what port the information is coming in, or some sort of tag identifying the issue. (For instance the query string clearly showing up in everybody's web logs)
They're also going to tell you that it's the index ISAPI filter, and you know you are vulnerable because you have the
What they don't need to do is give out a detailed description of how you would write Assembler to take advantage of the hole.
And lastly, what exactly do you think "Security through Obscurity" actually means?
Well in this case I agree that maybe a total disclosure from eEye was a bit of a conflict of interests, here is an analogy to illuminate my point. Suppose that ADT (or some other home/commercial security company) had a flaw in their security systems which actually made it easier for you to break in to a home/business. It would be one thing for a news reporter who is doing an informational story warning people that a flaw exists, it is quite another thing for a 3rd party company who sells add ons for the security companies systems to give potential wrong doers step by step instructions on how to exploit this flaw. This is basically what eEye is doing, if you notice, on the same URL where one can find the free Code red detection tool there is a link to their secureIIS web product. Basically they have released damaging information to stimulate sales of a product they produce...not exactly ethical.
Partial, or even no disclosure works in the favour of the black hats, and against the sys admin that wants to know exactly how to protect his system, and also works against the script kiddiots.
Full disclosure works against the black hats because the sys admin knows they are coming and can prepare. It does however work in the favour of sys admins/security personell, and unfortunately, the script kiddiots that are sitting waiting for the latest to come from bugtraq.
So, who do you phear the most? Script kiddiots though pesky, are not a great threat to your system. At most they use your system for IP laundering, or as DDoS zombies. Rarely do they backdoor your system so thoroughly that you need a full reinstall, and rarely are they after your confidential data. Black hats on the other hand are very difficult to get rid of once you have them, and are there because they have a reason. They want something from you, and you should be afraid.
My 2 or so cents.
Because disclusing vulnerabilities gives administrators the leverage they need to convince the management to give them the resources to apply patches before they become a crisis. It doesn't take much to patch a single server, but patching 30 servers, is no small undertaking.
I hope that with Code Red management will start taking security issues, and preventative maintence seriouly. Kinda like not having the oil changed regularly on your car.
If someone is passing you on the right, you are an asshole for driving in the wrong lane.
To: rms@privacyfoundation.org (Richard M. Smith)
Date: Fri, 10 Aug 2001 18:18:18 -0700 (PDT)
Cc: bugtraq@securityfocus.com
Richard M. Smith (rms@privacyfoundation.org)wrote:
> However one thing is now crystal clear with Code Red: full-disclosure
> comes with one of hell of a price tag. There has to be a better way.
>
> Richard
Wrong. A blatant lie by omission.
Full-disclosure + inaction carries a price. Full disclosure, by itself,
helps anyone who acts on the information. It only hurts those who ignore
it.
Fact: On June 18, Eeye released a very clear and comprehensive warning about
this vulnerability. AND a link to the patch. That is to say, the
patch was available at the time of the warning. And a URL to the
patch was supplied *in* the warning.
Fact: According to Marc Maiffret (the writer of the original warning)
"the CodeRed worm and hsj
to anything that we (eEye) discussed in our
did not use ANY technique that had anything to do with our advisory."
Fact: IIS is buggy, and a good sysadmin doesn't run a public IIS server
without good cause and some forethought. (which implies a plan for
frequent patching, and a way to stay informed about security bugs)
And, from these facts, I conclude that installation of a buggy webserver
followed by inattention to even the most common security practices carries
one hell of a price tag. Full disclosure, however, has given those of
us who were paying attention the opportunity to patch, filter, or shut down our servers long before most of the infections occurred.
The only better way to get this done would be to release a worm to all
of the machines in all of our router logs, which would patch the
vulnerability and mail the technical contact for the domain. But I'll
bet the lawyers would feast on the entrails of whatever martyr was kind
enough to do us all such a service.
--RMB
Please, learn the proper English plural of the word 'virus.'
There's no need to be making up words in hopes of sounding smarter. You only end up looking silly.
The only people who use the word "virii" are the pseudo-intellectual Slashdot geeks, trying to look 31337.
I read the report on CERT and not eEye, why aren't we bashing them too?
These agencies report thousands of bugs. Before Code Red struck, how were they to know that this particular one would turn out to be big?
How does this relate to the topic, exactly? Well full disclosure makes it easier to find, prevent or fix the ones who might be hiding. If application foo has a hole and a few people know about it, it's easier for one of them to quietly exploit it, possibly for years. And the quiet exploits are much, much more dangerous than the ones that are quickly discovered.
I expect that companies will start lobbying Congress to make security disclosure illegal. Those will be the companies you want to avoid if you want your company's network to be secure.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
The problem isn't that Microsoft didn't fix it in time, the problem is that lasy sysadmins (myself included) didn't bother to apply the patch until it was too late. Microsoft had a fix for this thing at least a month before it hit.
Personally if I found a security bug I'd do this......
1. If it was free software I would make a patch for it, then mail the patch and a full description of the problem to the makers of the product and several other security minded websites so that people would know that they had a problem and have the patch to fix it.
2. If it was closed source propriatory software I would give the company a 5 day head start (even if it was MS) by telling them privately first, then if they hadn't posted a patch yet (which IMO would be irresponsible or inept of them) I would post full details of the problem (and if it was MS maybe even code to exploit it) to force the company to move it's ass and distribute a patch.
Would I keep it a secret? NO. Why not? Simply because if I did, anyone else who came acrossed it could use it to their own advantage and hurt others. Why would I not simply inform the creator of proprietory software of the flaw and no pubicly post it afterwards? Because they can't be trusted. (not period) I have a feeling that they would simply ignore the problem until the average person became aware of it simply because they wouldn't want to waste the money correcting something that isn't well know. They would wait for the next BIG update to fix it which would leave the people ignorant of the problem vulnerable. By giving them 5 days I give them a chance to do the right thing with no pressure, then I release it to twist their arm into doing the right thing, if they can't figure out how to fix it.....tough shit they should've made it open if they can't handle their own software. If they release a patch before 5 days will I still release info and (possibly) code to exploit it? YES!!! Why? Because it is a sad fact that people will not install the patch until it is well known that they need it (take code red for example). By releasing an exploit sure I open the people who haven't patched yet up to abuse, but I also make the problem more known and force lazy sysadmins to get off their asses and get patched, in the end everyone is patched (except the stupid) and less damage has been done than would have before.
My philosophy is "If I can find it, others can find it" and I feel that letting the few people that find it run rampant with it is irresponsible and will cause more damge than bringing attention to the problem which may possibly let a few script kiddies do a small amount of damage rather than let an expert use an unknown method to safely exploit others for years.
Bottom Line? Security through Obscurity is ridiculous and does not work.
"
They also accept general concerns/suggestions/complaints through email (XP, for example, has an email address for concerns and suggestions).
well.. they acknowledge people who found the bugs.
Acknowledgments
Microsoft thanks the following people for working with us to protect customers:
John Waters of Deloitte and Touche for reporting the MIME type denial of service vulnerability.
The NSFocus Security Team (http://www.nsfocus.com) for reporting the SSI privilege elevation vulnerability.
Oded Horovitz of Entercept(TM) Security Technologies (http://www.entercept.com) for reporting the system file listing privilege elevation vulnerability.
Microsoft deserves a head start, but that's it. If holes are kept to MS and the people that find them, it's only a matter of time before a Black Hat figures it out. Releasing the details puts pressure on the companies to fix the damn thing. Without that pressure, MS would feel little to no pressure to fix what they screwed up in the first place. You wouldn't be doing anyone but MS a favor by withholding this info. The lesson to be lerned is that if you son't want ot lose money from downtime and reboots, don't use Microsoft on your servers. Certainly don't depend on it.
Carl G. Jung
--
"With one breath, with one flow, You will know Synchronicity" -La Policia
Details are not only useful for those that wish to fix the problem, but are also used by those that want to test if their system has a problem. This fact is often overlooked by those seeking limited disclosure. It is very useful to have a working exploit to conclusively tell if your systems are vulnerable, or patched. If you find you are vunlerable, then you close off that port, or pull down the machine, or somehow isolate the bug so that you are safe.
sure, there's worms that affect both *NIX and Microsoft OS's. HOWEVER, Windows is closed source and only ONE company controls it. therefore, when a new security problem is discovered, it could take weeks before a solution is implemented.
on the other hand, on the *NIX side, if a security problem is found, you get every 14 year old geek from california to siberia working on the problem within hours of the discovery.
Using the internet, the solutions provided by *NIX hackers are immediately available.
the microsoft way of giving solutions to their own security problems are ass-backward.
Great point! The only thing that is going to help the user is a fix. With closed source software, this rests on the vendor.
Certainly, it's within your right as the discoverer of the problem to fully disclose everything to bugtraq, attach a ready-to-go exploit.c that compiles out of the box on RedHat, and walk away.
However, if you're a security professional trying to, or at least pretending to, benefit the users, you're going to have to cooperate with the vendor to avoid screwing the users yourself; on top of that you ought to make sure the vendor doesn't get to screw the users either.
Your plan, I believe, is the best approach so far. With a partial disclosure (important!), the users get to know there's a problem and bitch at the vendor. Also, the more clever would be able to at least implement some kind of workaround if they know the "gist" of the issue.
But a month? I think that's way too lenient. When a vendor gets notification that there is a serious, exploitable vulnerability in one of their products, their first priority should then be to fix it. ASAP. Devote a team of programmers to it on the double. I can't think of any holes I'd give MS a month to patch, really. Give them a month, they'll take the whole month. In that amount of time, someone else could easily take your advisory, start working from there, and figure out the bug on their own (after all, you did it from scratch). Bad. I'd say the author should use some judgment, but a week should be enough for the most heinous of holes.
And...no, I don't think it applies only to closed source projects. Open source projects have maintainers, individuals or groups that are responsible for them. If such a maintainer is available for a project, why not give them the same advantage? You might argue that with open source, you should full-disclose so that any random joe has the chance to fix it, but if it were that easy, why didn't you fix it yourself and include a patch with your advisory? And if the maintainers can't fix it, Joe Shmoe will have his chance 2,3,4,5,6,7? days later when you do release the full.
Full disclosure is great, and it's absolutely necessary to completely document these holes. However, it's also dangerous. By allowing some time for the hole to get fixed, a really short time but some time nonetheless, the users, hackers and vendors all win.
Just because a few of us can read write and do a little math, doesn't mean we deserve to conquer the universe
For anyone who thinks that full disclosure(by anyone) is wrong, you can win me over by convincing me of one idea.
Convince me that knowledge(any knowledge) is bad. Convince me that there is ever a case where not knowing is better than knowing. Convince me that ignorance is in some cases a good thing.
If you can make a reasonable argument for that then i will beleave that full disclosure is not the best course of action.
--- diplomacy - 'the art of saying "nice doggie" 'til you can find a big enough stick'
But I was referring to the average Code Red infected machine. Those machines have nothing sensitive, only some downloaded music and porn, copies of commercial software borrowed from the office, and a resume claiming N years experience administering Windows.
It is only reasonable to format and reinstall an infected machine if the admin honestly plans to either keep up with security updates or disconnect it from the net. Most Code Red victims will do neither of those.
------DO NOT WRITE BELOW THIS LINE------
If Microsoft really wants a head start, they should PAY for the time of the person discovering the error. otherwise, let them deal with angry customers and full disclosure.
Um, but "viri" means "men", it has nothing to do with "more than 1 virus". So, by all means use it, but you will just look stupid.
There was an interesting post about this on the Politech list, which includes a response from Elias Levy (the guy who runs BUGTRAQ).
Why can't I moderate something "Wrong" or at least "Grossly Misinformed"?
From: "Marc Maiffret" <marc@eeye.com>
To: "Richard M. Smith" <rms@privacyfoundation.org>,
"BUGTRAQ@SECURITYFOCUS. COM" <BUGTRAQ@SECURITYFOCUS.COM>
Subject: RE: Can we afford full disclosure of security holes?
Date: Fri, 10 Aug 2001 13:10:51 -0700
After about 3 weeks of little to no sleep and spending lots of my (and Ryan
Permeh's) personal time researching CodeRed and its many variants I have
grown tired of the small number of people who so ignorantly have pointed a
finger at eEye and are trying to somehow get people to think that we are
responsible. As an employee of a company I must hold back some of my
feelings... however as an individual I can tell you that this is all
complete and utter crap.
|Hello,
|
<snip>
|This $20 million figure begs the question was it really
|necessary for eEye Digital Security to release full details
|of the IIS buffer overflow that made the Code Red I and II worms
|possible? I think the answer is clearly no.
Where the hell do you or anyone get off by saying that eEye's advisory made
CodeRed possible? This sort of ignorance being spread in a public forum is
just one of the many things wrong with the security industry. Your making
claims that you have no data to back other than "well I think so."
|Wouldn't it have been much better for eEye to give the details
|of the buffer overflow only to Microsoft? They could have still
|issued a security advisory saying that they found a problem in IIS
|and where to get the Microsoft patch. I realized that a partial
|disclosure policy isn't as sexy as a full disclosure policy, but
|I believe that less revealing eEye advisory would have saved a lot
|companies a lot of money and grief.
Lets get the facts straight. CodeRed is based off of another worm that was
written for a
copy of the
exploited an UNPUBLISHED vulnerability within IIS which was silently patched
by Microsoft without notification to anyone. Therefore IDS vendors never had
a signature and the
not found the flaw, then there would have been details, signatures made, and
IDS systems would have detected the first instance of CodeRed back in April.
So the facts are:
Someone found an unknown buffer overflow vulnerability within the IIS
ISAPI filter, without any data from eEye.
Someone exploited that unknown buffer overflow vulnerability in order to
execute code on remote systems, without any data from eEye.
Someone took that exploit even further and turned it into a worm (Which is
what CodeRed is explicitly based off of) and launched it at the Internet,
without any data from eEye.
Now a few months later someone took that
the
order to modify the
eEye gave them that made it any easier.
In fact when it comes down to it technically... eEye's technical exploit
information within the
shame by a skilled programmer by the name of hsj. hsj published a working
.ida ISAPI overflow exploit which used a wide character overflow technique
which was far beyond (and nothing like) anything we talked about in our
advisory. So technically the CodeRed worm and hsj
technically superior to anything that we (eEye) discussed in our
advisory. They did not use ANY technique that had anything to do with our
advisory. If you, or any of the other small percentage of people pointing
fingers at eEye, actually had any technical understanding of buffer overflow
exploits then you might have understood that and not sent an eMail to a
public mailing list making harsh accusations which are totally inaccurate
and untrue.
|Unlike the eEye advisory, the Microsoft advisory on the IIS
|security hole shows the right balance. It gives IIS customers
|enough information about the buffer overflow without giving a recipe
|to virus writers of how to exploit it.
This isn't the 70's. People are easily able to write exploits simply from
the data that Microsoft gives within their advisories. To say that hackers
are not able to write exploits solely based off of a Microsoft Advisory is
to underestimate the underground, which is a _bad_ thing to do. Most of the
hackers we know have automated tools that allow them to compare the files
held within a Microsoft security patch to system files that are being
replaced and after running them through custom modules for IDA etc... they
have pinpointed overflows etc... by ONLY using the information held within a
Microsoft security bulletin and its patch.
|Thanks,
|Richard M. Smith
|CTO, Privacy Foundation
|http://www.privacyfoundation.org
There is a big bad world out there far beyond the technical information seen
on mailing lists like Bugtraq.
Signed,
Marc Maiffret
Chief Hacking Officer
eEye Digital Security
T.949.349.9062
F.949.349.9538
http://eEye.com/Retina - Network Security Scanner
http://eEye.com/Iris - Network Traffic Analyzer
http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities
You said that "barely half the people out there bother."
Unfortunately, I think that a great deal - possibly even a majority - of those affected by these worms had a greater problem than apathy; The first time they heard about the potential problem was when their machine was attacked!
By a small sample informal survey (read: I asked around my office & friends) only about 10% of IIS users received some official notification of the problem, 20% more heard it from TV news, and the rest were blindsided by it upon attack. This is not good.
What's more, the "official" notifications received were not strongly worded like the one presented above; In order to save face, the parties involved were compelled to downplay the importance of the patch and selectively omit some of the consequences of not applying it. True, the messages suggested that the patch be installed as soon as possible, but they contained yawn-inducing language that basically created the impression that this was a theoretical problem that nobody would be exploiting any time soon. Were I an average IIS user, I probably wouldn't have installed it either.
From a business standpoint, this is entirely understandable. It still, however, sucks.
"Why would God give us a waist if we wasn't supposed to rest our pants on it?" - Rev. Roy McDaniels
You might as well blame Intel. If they didn't store the return address on the stack, stack overflows wouldn't be an issue.
Viruses.
You should not continue to use the MD5 checksum as a secure hash algorithm today. It's highly susceptible to collisions and, with a certain amount of padding, the hash output can be freely set to any arbitary value from any state.
Digital signatures (such as PGP 2.x) and/or some other forms of authentication (including using MD5 sums for checking the integrity of files after an intrusion) based on MD5 are no longer secure.
I would advise the use SHA-1 and/or RIPEMD160 instead; they are resistant to this particular collision attack.
Sadly, I cannot give further details at this time.
So what was this problem you discovered?
Clearly you did not read those links. Rather sad, actually, seeing someone attempt to look intelligent but failing miserably.
I think that MS (and anyone else) should have gotten some early warning before the vuneribility should have been posted, so they'd have a change to have a patch and all that, notify who they can, ect. I know that it wouldn't really solve the problem in the case of something as widespread and arcane as IIS, but still, just dumping a no-fix bug to the world isn't good unless the provider just refuese to do anything about it. Having said that, I still believe that hiding this kind of information is not a good thing. Once a fix and a distru system is established, bug reports should remain available to the public. In this case, MS could have had a fix on windowsupdate, and a generic setup for the SMS world ready to go, emailed SMS admins, and all that, at the same time as public disclosure.
The average cleanup takes a couple minutes. Are NT admins really paid that well, or are they just very slow?
BTW, when is the NT version of Code Red coming out? Seems like it should have a much larger audience of forgotten and neglected servers.
------DO NOT WRITE BELOW THIS LINE------
security through obscurity is a fallacy, but it can delay the inevitable..
seriously.. maybe a stepped grace-period would be an idea?
step 1: Bug is found, creator is notified
step 2: 2 weeks later. if bug is fixed, go to step 3. disclose existence of a bug, not much details yet
step 3: full disclosure
just shooting off the hip here...
//rdj
No one can understand the truth until he drinks of coffee's frothy goodness.
--Sheikh Abd-Al-Kadir, 1587
Umm,
I think that there is some confusion between the iishack exploit for IIS 4.0 and the new IIS exploit implemented in Code Red. When iishack was reported and released by Eeye MS had taken their sweet time releasing a fix. This is clearly not the case with Code Red.
I wouldn't be surprised if Microsoft has a honeypot farm somewhere, running their newest patched versions of everything. Static IP's with default installs should turn up a lot of interesting things when you're looking at the logs...
If the system is known to have a problem with buffer overflows, why not test it yourself before someone else exploits the hole? Why not test ALL of the software this way?
This, "the most expensive computer virus in the history of the Internet" is a mere wake up call. Someone, somewhere, is going to learn from this, and other sources, and do something nastier and far more damaging. It will be more subtle, harder to detect, and will slowly take over all versions of windows, or it might be a blinding flash, splitting up the work to take over everything, hooking in multiple places, distributing its attack methods to make it harder to get a list of ALL of it's methods.
Things are still very insecure, we're all going to get hacked, it's just a question of when, how we respond, and what we learn, in the end.
I hope everyone has a nice, complete, MD5 hash/Binary compare checked backup of their files.
--Mike--
Are you interested in "looking good" (aesthetic), or using English correctly? You're right, no one can convince you that the plural of radius is radiuses because that's incorrect English spelling. As it stands, the links Mr. AC provided clearly explain how and why "viruses" is the correct English plural. True, you are "free" to use whatever word you want, in the same way you are free to use "mouses" as the plural of "mouse" and "hice" as the plural of "house." Just don't expect to be taken seriously.
-------
"Every artist is a cannibal, every poet is a thief."
When the vulnerability applies to Windows:
- publish the vulnerability along with at least one example exploit
- write a paper letter to the vendor telling them of the website which describes the vulnerability. (Include sufficient postage on letter)
When the vulnerability applies to Linux, you still have full disclosure.- Tell the developers
- They fix the bug
- Full source code for the fix is released into the public -- which constitutes full disclosure.
- Comments in the source explain the vulnerability
Seems simple enough.Those who would give up liberty in exchange for security and DRM should switch to Microsoft Palladium!
But, you can *work around* the problem without being able to fix the problem in many cases. If you know about the problem.
The letter is very well written and I agree with the author. My only critiscsm is that Microsoft does not have a good system for accepting such advisories. Its always been my experience that you have to pay Microsoft to listen to your complaints/concerns about their software.
Maybe eEye tried to tell them but they didn't listen?
there are 2 kinds of people. those who divide people into 2 kinds, and those who don't.
Microsoft has previously been informed of security holes and has waited to fix them until the next service pack release rather than offering an immediate patch. Full disclosure of security holes forces them to offer patches now rather than when they get around to it.
None taken, and no, I can raise my hand and say I haven't installed a Microsoft patch.
However, my comment was not just aimed at Microsoft in this instance. I'm well aware that Microsoft patches aren't exact the easiest of things to make the wee small hours the most fun you've ever had, and in that respect I could go back to my argument that the vendor needs to ensure that the code they release is up to scratch - people (admins especially) have to able to trust anything that goes anywhere near production machines.
However, it's reasonably safe to say that your average *nix/BSD update can be trusted a little more not to give too much heartache, and yet most exploits out there attack old, well known and usually long since solved issues - and those exploits succeed, because there are still one subset of admins that do not maintain their systems.
Yes, I agree, patching is not everything, and it takes time to apply changes to development and then live environments after the relevant testing can be carried out, hence other ways around problem can (and should) be used if possible.
This comes back to the admins knowing enough about their systems, and how everything interacts to be able to recognise and implement alternative solutions - the end result is still an improved/secured (as secure as is possible at that time) system.
IMO, you *have* to blame everyone involved - everything has to come together, from vendor to admin.
Once again, I've steered clear of the root cause - the crackers and worm/virus writers - it's a problem that will probably never be solved, much to my regret.
So apparently you believe when eEye released their press release discussing this problem, there was no fix available from Microsoft?
Do you have proof for this claim? Or are you just talking out of your ass?
That "grace period" is how it's done today. Microsoft released their security bulletin on the same day as eEye released their disclosure information. Because they had been working together on the issue for quite some time beforehand.
Blame Microsoft for having released software with huge security flaws.
Full disclosure is definitely a good thing. Not only it pressures software vendors to release a patch, but it also help other programmers to understand good programming practices.
And *this* help every application on the security road.
Today, more and more software is designed with security in mind. 10 years ago, nobody was careful about this.
How could programmers know how to code secure software without review full disclosures of other software ?
Yes, there are "secure programming" mailing-lists, but they'd be abstract and far from the reality without any knowledge of real cases.
{{.sig}}
No, eEye notified first Microsoft. Microsoft released a patch and after that eEye made public its exploit.
Personally, I am against making public the sample exploit code. Why? Yeah, a hacker might eventually find the hole as long as you describe it but making the code public makes the hacker's life much much easier, because developing exploit templates takes time and patience and reduces a lot of debugging efforts!
¦ ©® ±
I've always been a firm believer against virus-watchers who release full exploits to the general public. It simply isn't necessary. The same results (warning Microsoft) could have been done without causing such a hyped panic.
It's akin to not only delivering a news story on a serial thief who's robbed many homes, but giving full and agonizing details on how he broke in to the general public (and in the process, other criminals). There is NO ONE who can argue that the only people who *need* that information, for the safety of others, is the police.
Where talking trusted systems here, with code written in ADA or LISP. Not pretty when it comes to the real world, outside of the military, though.
My only problem with this is that Microsoft lacks the motivation to fix the hole if no one else knows what it is.
Sure, people can point out there "some hole" exists. But unless the details are made public, Microsoft (or whoever)isn't motivated to fix it, and no one can check up after them to see if it has been fixed. We have to take their word for it. That would make me very nervous.
I wouldn't be against a "grace period" where the vendor is told of the hole so that a patch can be ready when it is announced, but it would need a time limit on it to keep it from being delayed forever.
--Ty
Please, learn the proper English plural of the word 'virus.'
There's no need to be making up words in hopes of sounding smarter. You only end up looking silly.
when will the nerds here get this right?
I've heard this argument an awful lot, and no one in the open source community (who seems to want to use this argument) has ever been able to bring any factual instances to light. Has there ever really been a Microsoft vulnerability reported to MS where the company replied "That damage is only theoretical. We don't feel obliged to fix it." I mean, a real world story.
And keep in mind, MS probably receives dozens of fake security exploits a day by open source/hacking zealots (and I include myself wholeheartedly in that group). You can only expend so much money on determining what exploits are "real".
You're nothing more than a pompous M$ lover. They deserve to be bashed because of the business practices they stand for and the crappy software they produce. I suggest that if you don't like the comments then don't read em. Damn Jerk!!!
Wow. My Linux based Irony Meter just coredumped from an impossibly large input. Here: let me help you-
I suggest that if you don't like my comments, then don't read them. Anonymous Coward!!!1!!!
Please, learn the proper English plural of the word 'virus.'
There's no need to be making up words in hopes of sounding smarter. You only end up looking silly.
Eeye does give Microsoft advance notice before releasing details, but the minimal advance notice they give isn't sufficient for Microsoft to get moving on a fix, much less for thousands of admins to patch hundreds of thousands of servers.
But who is ultimately at fault here? Eeye for releasing the information, or the black hat for writing the worm, or Microsoft for releasing buggy code in the first place?
I do not deploy Linux. Ever.
I think a grace period makes sense, perhaps even one with a sliding release date, (i.e. we won't release the information as long as we are convinced you are dedicating appropriate resources to a fix), but in the end (once the patch is out) there has to be full disclosure, right down to example exploits.
Full disclosure drags mistakes out into the light where the entire programming community can have the benefit of learning from them. Otherwise, each vendor has to independently learn these hard lessons.
If examples of buffer overflows or other more subtle code weaknesses are documented and explained in a public forum, then companies can benefit by being able to hire programmers who have learned from these cases without having to be bitten by them.
I understand companies like/need to hoard their intellectual capital, but in today's always-connected environment some things should be too important to keep to yourself.
eEye is responsible for the initial bug being created. So lets think about this.... The guys that wrote this little worm can write multi threaded, self propagating, ip scanning code but they can't find a simple buffer overflow? Somehow I just don't see that happening.
VMS does not have a history at all! It's just a big hoax.
Sounds like the path to CERT to me.
(CERT being so in bed with the vendors that they often take years to get the word out, if they do at all. Meanwhile the black hats have full access to the info and plenty of time to start exploiting it)
So, anyway, Richard Smith, this supposed privacy guru, it turns out happily uses this very same toll system! Despite its obvious privacy problems, he can't be bothered to wait a few seconds a day to pay cash. Not only that, but he shows up in public forums letting us all know how he feels.
Now, on a security list (he is CTO after all, woo woo!) he is now praising Microsoft's security policies...?
Ya know, Stallman can be incredibly annoying. But, when it comes to a public figure like this, his "purity" is somewhat reassuring. I think Richard Smith is probably a nice and smart guy, and he's entitled to his opinion... but CTO of the Privacy Foundation is also how he's "entitled" and if you ask me, he loses credibility all the time. So what? Well, he dimishes the causes of privacy and security as he sinks.
Vendors all around view a vulnerability that has been publically exposed as a much higher priority than those that have not been exposed. Over and over again, history has shown that a vendor will try to cover up a vulnerability if it is not exposed, to avoid bad publicity. (No, this is not specific to Microsoft, all vendors hate bad publicity). If an exploit is publically available for a particular vulnerability, it also changes the method in which the vendor advertises the patch, thus increasing the people who know about it and install the patch.
Full disclosure provides many useful functions, including the ability to test for vulnerabilities in their own systems. It gives them the abliity to verify that the system has been properly secured after a work-around has been implemented.
Partial disclosure, which is often suggested, is no different htan full disclosure, except it may give the admins a false sense of security. With partial disclosure, the existence of a bug is disclosed to the public - but the details are not. Sad enough, once the cat is out of the bag, it's only a day or two before someone else can figure out the exploit. Once the vendor releases a patch, it is trivial to do binary diffs on the provided updates and figure out the details of creating the exploit. In fact there are tools that help to automate this already in existence today.
The sad thing about code red is this: Patches have been available for quit a while now. Yet systems are still getting hit. The widespread affect of Code Red is the ONLY thing that will get the admins who never patch their systems to potentially pay attention to whats going on.
Full Disclosure is not the problem. If one person has found the vulnerabilities, there are generally more who have found them and are actively exploiting it already. To think otherwise is to seriously underestimate the cracker community.
--
Twivel
Correct me if i'm wrong but MS did fix this on time, the problem was IT/MIS not applying the propper patches or taking the time to close security holes.
The whole argument is moot since obscurity != security, in fact, full disclosure has proved to be the fastest way to get a bug properly fixed.
Now a more interesting argument is why the hell is it so hard to keep MS systems properly patched.
That might have been me. Or it might not. In any case, it's a belief I subscribe to, and one which I have voiced here on at least one occasion.
I think what a lot of people are missing with all the talk about "pressure" is that there are basically two types of sysadmins: those that are security-conscious and those that are not. Those that are not are unlikely to apply a patch even when an exploit is known and circulating, unless and until it actually hits them. Look at all the people who failed to apply the IIS patch even after CRv1 went around, and got hit by CRv2. No amount of pressure, on or from the OS vendor, is going to affect that. By contrast, those who are security conscious would take protective measures even without full disclosure just to be safe. If there's no patch available from the vendor, maybe someone else can come up with a stopgap. For example, eEye could have described an adequate set of protective measures for CR without providing the recipe for CRv2; anyone who thinks their reason for not taking that approach is anything but venal must be hopelessly naive. If nobody has a patch or stopgap, the only people who benefit from full disclosure are the bad guys.
Note that in no case of those above does "pressure" make a difference. Also note that in no case does full disclosure help the good guys. The people who work at security companies know each other. They can share the details among themselves discreetly if they choose to, so that all of the firewall/IDS/etc. people can keep up in the arms race. The only difference between that and full disclosure is that full disclosure also makes it more likely that new exploits will appear before the vendors all catch up.
Do you think it's just coincidence that it's good for eEye's business for new versions of CR to appear when they're prepared for it? If so, consider the text of this link from their front page:
Slashdot - News for Herds. Stuff that Splatters.
I guess you are as completely unfamiliar with the history of this bug as you are with proper spelling. eEye DID contact Microsoft and gave them plenty of time. The patch has been out for MONTHS.
I agree that software defects shouldn't always be flung out to the wind as soon as they are discovered. I believe they should be released, after the community that it impacts is able to remedy the problem, or at least some time has passed to give the community a chance to remedy the problem.
It's not a philosophical question, but merely a pragmatic, logistical reality. Unfortunately, companies love to try to keep a problem quiet rather than fix it, gambling that it won't get out of hand. Of course, this is bad for security, so in some cases, immediate disclosure is the only way to get companies to do something.
With Code Red X, in the immediate sense, it's not Microsoft's fault that it spread so far, they did their part this time. You can always blame the architecture, but it's not just Microsoft's problem. It's a systemic problem that faces all software distributions. The patch was out for at least a month before Code Red showed up. People simply didn't apply the patch. A lot of people didn't even know they were running a web server, or even what that means.
Of course, I don't want to be forced to apply patches, nor am I very comfortable with my machine visiting microsoft.com autonomously. But there has to be a channel through which information about patches can be pushed or polled.
Microsoft has done a lot of good with http://windowsupdate.microsoft.com and I hope the trend continues. I would like to see every new Microsoft distribution go out and check for updates at regular intervals, but have the ability to turn that off if I dun like it.
OK, you're talking about a situation where you *knew it didn't apply*. That's a little different than *not knowing it does apply*. Maybe you'd treat the two scenarios the same way, but many wouldn't.
Also, I'd like to point out that I'm all for providing as much information as possible about the conditions that make one vulnerable, and about countermeasures. What I oppose is description not only of conditions and countermeasures, not only of the vulnerability's basic nature ("unchecked buffer length in the xxx-checking part of the yyy-module"), but of exactly how an exploit works or could work. If I, as a user, knew that the exploit involved such-and-such a buffer overflow, that it only mattered if I used feature X and that I could protect myself by doing Y, that last sort of information provides no additional value. It would provide additional value to security professionals as a test case or data point, which is why they should get it via limited disclosure, but it's not useful to me. The only people who derive significant value from the broadcasting of information about exploit mechanics - as opposed to limited disclosure or broadcasting of risk/countermeasure information - are the exploit programmers.
I already went over that ground in another sub-thread. Check my user page if you're really interested.
I'm well aware that my attitude regarding disclosure runs counter to the herd/leech mentality.
...and if the information had been disseminated efficiently among members of the "defense" before giving it to the "offense" the exploit would be obsolete before it was created. Let's say that I find a vulnerability. I can do one of two things:
Clearly it's a race. I know that, even if I try to keep the information among the good guys, a leak will nonetheless occur sooner or later. However, I can try to make sure that as many good guys as possible are already working on countermeasures before the bad guys get the information and start working on exploits. That edge, even if it's only a day or two, might make millions of dollars' worth of difference in the damage (if any) the exploit does when it appears. Are you saying that we should sacrifice those people, just so you can have the warm fuzzy feeling of having additional information that in fact provides you with no additional protection? I'm sure you don't like to think of it that way, but it seems to me that your arguments - and those of others - favoring full disclosure are based more in a personal desire to feel like an expert than in overall social/economic utility.
Slashdot - News for Herds. Stuff that Splatters.
...instead of a tap on the shoulder. Some companies need some "convincing" to make the necessary changes in a timely manner. Microsoft is definitely one those companies.
Troll
I think they really hoped some virus dev will pick it up.
Think about it, that was a shitload of PR for eEye, mentioned in about every second article about Code Red.
Before you email me, remember: "There is no god!"
I'm just astonished that in a multi-level posting with no fewer than three participants that addresses the use of English, every single post exhibits spelling, grammatical or usage errors. To cite:
Post one: Here's a little lesson for you in a form that may be easier
> to remember. (Sung to the tune of Mary had a little lamb).
To use a parenthetical, include it before the ending punctuation. Don't make it a new sentence.
Post two: You see the purpose of words is to communicate an idea.
The "you see" part is a separative, and should therefore be separated from the rest of the sentence by a comma.
words have no inate meaning
Ahem.
Post three: Shaekspeare
Who? The spelling of the bard's name isn't that hard to check.
Post four: Yes, you are correct, that is what I meant.
While creating three sentences with one period may be economical, it's not correct.
Come on, folks, let's pull it together a little better next time.
Virg
The only way that companies can ultimately be made responsible is through full disclosure. The only way you can know if they actually fixed or patched anything is through full disclosure. If you don't trust your vendor enough either you can stop using them or you can check them against what they say. Even if the real number is 20 million that is nothing compared to MS or any other company not fixing the problem or doing a poor job of it. Remember that software companies are judgment proof unlike other types of companies so you can't even add the risk cost of litigation into the equation like you could with pharnaceuticals or automobiles.
There WAS no time limit, until eEye decided to instill one by releasing the code.
They did not release any code.
Simple example, how many people use time functions in C without realizeing they are dealing with a very limited function which croaks in about 35 plus years. Use one of those functions to calculate a date beyond the range and who knows what you get for data. This bogus data then gets pushed into another function which is not checking because only valid data should come back from a built in function...
In many ways we get tripped up using code/languages which were designed under past limitations (8, 16, and 32 bit). The libraries need some cleaning/correcting, and code in general needs some serious error checking. Error checking along the lines of, "what happens when procedure X receives the impossible?"
In a place beyond time and space, in a land far better than this, look for me there...
Even a patch with no details of what it is patching is enough information for someone competent to reverse engineer the vulnerability.
By their nature patches don't change very much (even within a single file) so it's easy enough to spot what is being protected against, and hence work out the exploit.
Ok, so partial disclosure means that any budding black-hat has to spend maybe a couple of hours more crafting an exploit -- but will that couple of hours really be the difference between the Internet being wholly vulnerable and wholly patched?
Recent experience suggests not.
What partial disclosure does give is a false sense of security through obscurity.
This question sort of assumes that if eEye doesn't release the exploit code, the code won't be written. On the contrary - exploit code is often referred to as proof of exploit code and is intended to show that the vulnerability indeed exists. Otherwise, vendors have a habit of stonewalling: "that vulerability is entirely theoretical."
Is it not also possible that they discovered these vulnerabilities in their own testing, and decided to fix them before an exploit appeared? Would you fault them for that? I know how the herd likes to jump to the most negative possible conclusions regarding everything MS does, but simple honesty requires that we at least mention and consider alternative explanations.
Slashdot - News for Herds. Stuff that Splatters.
This is such a blatant antagonism I can't believe it's still making the rounds. The note was posted to Bugtraq and has become the poster child for the anti-full-disclosure crews.
Slashdot is trolling us--successfully, it looks like. Too bad we can't mod the story itself down!
This debate is hashed through time and time again, and solved--time and time again. Anyone who argues against full disclosure has never been a system admin or been deep enough into someone else's exploit-ridden code to feel the pain.
Exploit disclosures are like the work-saving packages collections of *BSD. Someone else has done the work for you. For those who are in the know this means we don't have to fire up our own copy of IDA or grep spaghetti source code to figure out what the heck is going on.
Why should I worry about the lower forms of system admin life and hold their ignorant hands when my more important systems and the systems of my clients are at stake? If you can't stand the heat, bloody well get out the kitchen and leave the work for someone who knows what they're doing.
Wouldn't it have been much better for eEye to give the details of the buffer overflow only to Microsoft?
That is based on the assumption that Microsoft would take immediate action for the benefit of the society.
Ok, take a look at this:
The update, which amounts to a point release for both IIS 4 and IIS 5, also addresses five previously undisclosed vulnerabilities with IIS, which could result in either denial of service or privilege elevation.
Five undisclosed vulnerabilities! Smart crackers might have enjoyed exploiting them for months!
When would Microsoft disclosed fixes of those vulnerabilities? Next Service Patch? Does it mean they wouldn't be fixed if not for this CR instance?
How could you rely on a group of people whose actions are unaccountable?
Ok, you can mod me troll now if you don't like I speak ill of Microsoft.
Oh, and it was also a Netscape problem, and they ignored me as well.
-- these are only opinions and they might not be mine.
I think many people are missing the point that white hat exploits are necessary in order to get the vendor to take the vulnerability report seriously.
How many crackpot vulnerability warnings do you suppose Microsoft gets on any given day? Ten? One hundred? One thousand? All of them from lunatics asserting that the vulnerability will lead to one gagillion dollars in damage, the extinction of at least one animal species, and the destruction of the entire internet.
In a situation like that, the one serious vulnerability report that comes through is just not going to get any attention. Not unless it comes with proof that the vulnerability actually exists.
Yes, it could be argued that BugTraq now has enough credibility to be taken seriously without doing proofs. On the other hand, how do you suppose they acquired that credibility? And how are they to maintain it?
Microsoft doesn't seem to do that anymore, because they've adapted to the reality of full disclosure. However, many software vendors still do sweep problems under the rug - in fact this seems to be the 'default setting' for a software vendor.
If you read BugTraq, it seems like half the vulnerability postings say "I notified $VENDOR four weeks ago, and they failed to respond/said it's a feature/said it's not worth fixing.
One vendor revved their firmware three times while ignoring a huge vulnerability that had been reported to them. Finally the researcher posted it to BugTraq. And this is not exceptional - I remember it only because I read it recently.
If you look at Microsoft's vulnerability announcements, you can see the evolution. They used to put a little PR spin on the vulnerability, claiming it would take 'special software' to exploit it, or otherwise implying that an exploit was unlikely. They seem to be reducing these attempts at damage control, since they realize that everyone realizes that if it can be done, it can be automated.
I mention these little PR driblets because they demonstrate that the advisories are issued under duress - Microsoft feels that it would be better not to issue an advisory. And they acknowledge the duress honestly - part of adapting to the full disclosure world - by giving credit to the researcher who reported the vulnerability. That's how they reward people for telling them first.
After reading the email, it gives me the impression that it could have just been one of the comments posted here, and that it would have a score of 1, and it would have no responses. There is no real "meat" to it. So he's trying to say that information is dangerous, and shouldn't be allowed, because it might cost some mega-corp a few bucks. And "can't we all just get along?" Sheesh.
The question has been debated over and over again for years. Doesn't it always come down to unless there was total disclosure, MS or whoever is responsible drags its feet in releasing a patch?
There was an idea raised on /. a while back that I thought was pretty good, I think a hybrid of the two would be even better. Someone (no link, sorry) suggested that a security firm could notify the manufacturer first - give them maybe a months notice or so - and then release to the public. The idea being that a patch could be developed and released before too many l33t h4x0rs got a chance to exploit it.
A slightly better proposal - and one that would add a little pressure to the manufacturuer - would be to release some details to the public, full to the manufacturer, with promise that full details would be released shortly. The manufacturers would have time to patch, the public would know something was wrong and (conceivably) pressure them into getting it fixed and soon.
Of course that really only applies to closed source projects.
It could work.
Ad in classifieds: Pandora's Box (no box) $5
Me: Hmm... This is pretty serious shiznit! Maybe I should disable indexing on my company's IIS server...
Boss: Okay. You do that.
Me: Clickity Clickity Click...
~ ONE MONTH LATER ~
Boss: Oh god! The world's going to end! Our profits are going to dry up. Code Red is trying to rape my daughters...
Me: Relax, buddy! We've got it taken care of. Remember we disabled indexing on our IIS box? I also installed the patch from M$ just as soon as it came out.
Boss: Oh... Okay.
~ ONE WEEK LATER ~
Boss: Oh god! The world's going to end! Our profits are going to dry up. Code Red II tried to assault me behind the bar last night.
Me: Relax, buddy! Remember, we disabled indexing on our IIS box and installed the patch. Remember?
Boss: We did that?
The lesson here isthat EEye was perfectly responsible in releasing the information, and did so with the knowledge of Microsoft, so that M$ could release a patch in time to fix a hole that could have halted governments. As bad as it was, it could have been worse.
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
I always wonder about that when watching various shows on the Discovery Channel or TLC about real-life crimes, usually murders. I mean, after watching those shows for a while one night, I thought "you know, if someone wanted to commit a murder, they could just watch these for all the 'how not to do it's...'"
"Giving money and power to government is like giving whiskey and car keys to teenage boys" P. J. O'Rourke
There's also a series of articles on ntbugtraq talking about this issue. Russ Cooper is a huge proponent of what he calls 'Responsible Disclosure', whereby basically a mailing list is created which only has subscribers from people in the industry. Namely vendors of the security products, and of the OS and other tools.
This is the process that is used in the Virus community today, and it's been working well.
One of the points Russ made was that eEye could have discussed this issue on the mailing list before issuing a press release. In addition to feedback having been given by Microsoft, there would have been peer review. Additional information would have resulted, clarifications on impact and so forth.
Then a final press release could have went out, giving eEye full credit for finding the issue, but providing a wealth of useful information to the end-user/admin type folks.
Russ also raised a point about eEye's motivation. Why do they insist on not only full disclosure, but also releasing exploit code? Again he raises a good point, and I think it's quite clear.
eEye is in business to sell a product which supposedly protects you against these types of attacks before they happen. So it is in there best interests that an attack is quickly released and spreads rapidly, thus generating mass hysteria. Only with such hysteria can they generate traffic to their site and obtain orders for their product.
Enough said. eEye released the code to MS 2 weeks before made public. Fix was on MS's site before you even heard about the buffer overflow.
Bruce Scheier has been full of shit for at least several years. He wrote Applied Cryptography. Thanks. What else has he done. I don't even read cryptogram anymore because all it is is a plug for his new book "Hire Counterpane and buy our anti-h4x0r insurance!"
And it's viruses, not virii.
Unfortunately as code red has shown us lately security is a major player that people tend not to add into their budget or network configuration.
If operating systems came default everything turned off upon install we wouldn't have issues of this magnitude. Or perhaps if patches were properly applied in a timely manner.
I believe that the general public should be known of the security hole, in detail. Your network administrator/security group should be on the ball and fixing it when it's made public. If not you'll never know when a daemon, program etc needs to be patched or upgraded.
-maz
<happiness>beer</happiness>
was also published on lwn.net, and linked to on the front page. I think it somewhat disingenuous to cite only the criticism and not the response, when they are given equal play by your sources. Could it be that once you read eEye's response the discussion pretty much evaporates? I think they did a good job of answering the criticism (as does LWN's editor). In short, eEye didn't aid and/or abet anyone. All of the info required to write Code Red was already available, and it was a slight modification that turned a previous worm into Code Red.
While I hate MicroShaft (ask anyone at my job) and TheCabal appears to have a slight slant towards BillCo, I must reply to this!
/. line and Love Linux, hate Microsoft and have the latest disto of Debian running on my toilet. If that makes me a MS lover, feel free to apply that label. I, on the other hand, prefer to use the right OS for the job. And sometimes that is Microsoft. Maybe some day soon, more people will realize that, and get away from this asnine OS bigotry.
Heaven forfend that I don't toe the
They are pretty good at putting out fixes (if more than a little low key on the announcement thereof)
Strange. I get announcements delivered to my inbox not only from Microsoft's Security Notification service, but their security guys are pretty active on NTBugtraq. And the latest patch announcments are always available on the TechNet homepage. Would you rather that they send a man with a bullhorn out to your house and shout the URLs for the latest bulletins? Have a skywriter spell it out for you in the sky? Burn the URL on the moon, a la Chairface Chippendale? Is it lack of effort on Microsoft's part, or lack of effort on someone else's part?
They certainly deserve a good bashing from time to time. However, please keep the bashing based on real facts, not generic BS. (we like to bash them for their FUD, let's not spread FUD ourselves)
I wish a lot more people would adhere to this rule... I see a LOT of award-winning fiction being written here on Slashdot about the (imagined/exaggerated) wrongs of Microsoft and Windows in general... I urge the authors to leave the IS/IT field and get into writing fulltime.
Does being less than hypercritical of Microsoft make one a MS-lover? I've never said anything bad of *nix, but then, I've also never painted *nix in glowing, flowery prose, either.
eEye's response,
http://lwn.net/2001/0816/a/eeye.php3
clearly points out that they provided *NOTHING* to the virus writer, and in fact the virus writer used another virus as a template. The criticism in this
case is quite unfounded.
or, if you insist on pseudo-latinate formations, "viri". US I O UM O I ORUM IS OS IS!
I did not intend to make you out to be a lover/hater of any OS. I only stated that (based on your post) you appear to have a slight slant towards Microsoft.
:-)
I myself don't run Debian, Mandrake and Red Hat is what I use. I too use/recommend the appropriate OS. My kids run Win98 and so does my mother in-law. At work I run NT (Corporate decree), Linux , Solaris and HP-UX.
For me it's as simple as this, why would I pay Big Bucks (tm) for an OS that'll cause me grief and instability when I can get a stable OS that'll do the job better for free?? At work I am one of the very few not affected (directly) by all these LookOut viruses because I insist on using standard mail. (yes, we do anti-virus updates daily and apply patches as soon as recommended.)
Strange. I get announcements delivered to my inbox
I insist that MS is good at puting out bug fixes but low key on anouncing them. If you know where to find them or what mailing lists to subscribe to you'll get the info otherwise you're in the dark.
That would apply to most people!
Does being less than hypercritical of Microsoft make one a MS-lover? I've never said anything bad of *nix, but then, I've also never painted *nix in glowing, flowery prose, either
No, that makes you an unusally balanced person (for this forum at least). Me being a *nix pro for 16+ years I can, here and publicly, say that unix has a number of bad sides, the latest of the big Linux distros are starting to address the most serious, the high learning curve. Today I would say that it's as easy or easier to install Linux but not quite as easy to use for Joe Sixpack (yet).
Microsoft does engage in some shady practises and does charge a lot for poor quality products. But they have also to a good extent helped generate the computer boom and occationally release good software and/or concepts.
Specifically to TheCabal. I did defend your statement against the AC. Take it easy
After about 3 weeks of little to no sleep and spending lots of my (and Ryan
.htr ISAPI buffer overflow. CodeRed is an almost identical
.htr worm. A worm which was released back in April. A worm which
.htr worm went unnoticed. To bad a security company had
.htr
.htr worm and modified it to attack
.ida vulnerability. They already had ALL of the knowledge they needed in
.htr worm to be the .ida worm. There was nothing that
.ida ISAPI overflow advisory was actually put to
.ida exploit were
.ida
Permeh's) personal time researching CodeRed and its many variants I have
grown tired of the small number of people who so ignorantly have pointed a
finger at eEye and are trying to somehow get people to think that we are
responsible. As an employee of a company I must hold back some of my
feelings... however as an individual I can tell you that this is all
complete and utter crap.
|Hello,
|
|This $20 million figure begs the question was it really
|necessary for eEye Digital Security to release full details
|of the IIS buffer overflow that made the Code Red I and II worms
|possible? I think the answer is clearly no.
Where the hell do you or anyone get off by saying that eEye's advisory made
CodeRed possible? This sort of ignorance being spread in a public forum is
just one of the many things wrong with the security industry. Your making
claims that you have no data to back other than "well I think so."
|Wouldn't it have been much better for eEye to give the details
|of the buffer overflow only to Microsoft? They could have still
|issued a security advisory saying that they found a problem in IIS
|and where to get the Microsoft patch. I realized that a partial
|disclosure policy isn't as sexy as a full disclosure policy, but
|I believe that less revealing eEye advisory would have saved a lot
|companies a lot of money and grief.
Lets get the facts straight. CodeRed is based off of another worm that was
written for a
copy of the
exploited an UNPUBLISHED vulnerability within IIS which was silently patched
by Microsoft without notification to anyone. Therefore IDS vendors never had
a signature and the
not found the flaw, then there would have been details, signatures made, and
IDS systems would have detected the first instance of CodeRed back in April.
So the facts are:
Someone found an unknown buffer overflow vulnerability within the IIS
ISAPI filter, without any data from eEye.
Someone exploited that unknown buffer overflow vulnerability in order to
execute code on remote systems, without any data from eEye.
Someone took that exploit even further and turned it into a worm (Which is
what CodeRed is explicitly based off of) and launched it at the Internet,
without any data from eEye.
Now a few months later someone took that
the
order to modify the
eEye gave them that made it any easier.
In fact when it comes down to it technically... eEye's technical exploit
information within the
shame by a skilled programmer by the name of hsj. hsj published a working
.ida ISAPI overflow exploit which used a wide character overflow technique
which was far beyond (and nothing like) anything we talked about in our
advisory. So technically the CodeRed worm and hsj
technically superior to anything that we (eEye) discussed in our
advisory. They did not use ANY technique that had anything to do with our
advisory. If you, or any of the other small percentage of people pointing
fingers at eEye, actually had any technical understanding of buffer overflow
exploits then you might have understood that and not sent an eMail to a
public mailing list making harsh accusations which are totally inaccurate
and untrue.
|Unlike the eEye advisory, the Microsoft advisory on the IIS
|security hole shows the right balance. It gives IIS customers
|enough information about the buffer overflow without giving a recipe
|to virus writers of how to exploit it.
This isn't the 70's. People are easily able to write exploits simply from
the data that Microsoft gives within their advisories. To say that hackers
are not able to write exploits solely based off of a Microsoft Advisory is
to underestimate the underground, which is a _bad_ thing to do. Most of the
hackers we know have automated tools that allow them to compare the files
held within a Microsoft security patch to system files that are being
replaced and after running them through custom modules for IDA etc... they
have pinpointed overflows etc... by ONLY using the information held within a
Microsoft security bulletin and its patch.
|Thanks,
|Richard M. Smith
|CTO, Privacy Foundation
|http://www.privacyfoundation.org
There is a big bad world out there far beyond the technical information seen
on mailing lists like Bugtraq.
Signed,
Marc Maiffret
Chief Hacking Officer
eEye Digital Security
http://eEye.com/Retina - Network Security Scanner
http://eEye.com/Iris - Network Traffic Analyzer
http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities
IANAL, but yes, it is legal to hack chinese servers. Deface their website to say "Hacked by United States", and then have the hacked servers attempt a DOS attack on www.stupidfsckingdictators.chineseTLD (make sure you use their domain name, and not IP address).
:-)
And since IANAL don't call me when you get arrested....
I want my rights back. I was actually using them when our government stole them after 9/11.
I'm sorry, but I would really prefer to have the information that a certain lock installed on my frontdoor can be picked just by staring at it really hard, so I can go out and fix it or replace it.
If all I had to go one was "somethings wrong with the door" what the hell are we supposed to do about it?
Sure other criminals might now about it now. But I've already fixed the problem, or I have a contingency shotgun in place, etc.
I'm still waiting for the clause in the Windows license that states you cannot publish vulnerabilities or defects with their product. It's already been done with database performance as seen with Oracle. Why not Microsoft and security?
What's the world coming to when everyone's favorite security guru starts blaming the messenger, too?
Why? Because then it is just a matter of testing to see if it is a stack related issue or not. Once it is determined it is a stack related issue it is just a matter of figuring out the specifics of exploiting it.
If I know a web server on W2K crashes when I pass it 10,000 characters then I can start running something to see how it crashes when I do that. If it is a buffer overflow then I can probably get it to do what I want.
Second, eEye already pointed out that the author of the email actually knew nothing about the issue, as the exploit had been used months before they posted their description.
Here's part of a response to that email, from an employee of eEye:
Lets get the facts straight. CodeRed is based off of another worm that was written for a .htr ISAPI buffer overflow. CodeRed is an almost identical copy of the .htr worm. A worm which was released back in April. A worm which exploited an UNPUBLISHED vulnerability within IIS which was silently patched by Microsoft without notification to anyone. Therefore IDS vendors never had a signature and the .htr worm went unnoticed. To bad a security company had not found the flaw, then there would have been details, signatures made, and IDS systems would have detected the first instance of CodeRed back in April.
Okay, so the guy who wrote the letter blaming eEye was a fool, who spouted off without possession of any facts in the case. But, it looks like he has a lot of company on slashdot. Maybe, they ought to rename the site 'slashdork.'
mp
"The secret to strong security: less reliance on secrets." -- Whitfield Diffie
You are a loser. More of a loser than I am. Thankyou, you just made my day. Nothing like shadenfreude(sp??).
Basically they have released damaging information to stimulate sales of a product they produce...not exactly ethical.
The problem with this position (that eEye is acting unethically) is that eEye doesn't appear to have misled anyone in anyway. This is the MOST ethical marketing you can do--be honest. Would you rather see a marketing department disingenuously attempt to mislead large groups of people about the nature of Free Software by calling it virul?
It is dis-heartening to see that FUD is now the 'appropriate' method of comparing product, while pointing out legitimate inadaquacies in competing products is considered un-ethical.
How absurd.
-fp
OK, so obvoisly its not a good idea to give hackers all the information about a bug in your system. The problem as I see it is that the people who released the information had too much confidence in the ability of users to fix the security problem before it could be exploited again. I think discretion should be used in these information releases and even though a fix is available, it should not be assumed that everyone on the planet has already installed it. Such assumptions cause problems, as we have seen in this case.
~ now you know
Can you go check to see what day eEye released their disclosure?
Hint: June 18, 2001
Now go check to see what day Microsoft released their disclosure?
Hint: June 18, 2001
What was this sledgehammer?
You've completely missed the point. The problem is not that "there are too many security exploits" but that many are simply tomfoolery brought about by the community. Do you have any idea how many security exploits MS receives that have no basis in reality, but are only there to get their goat? And it's not like the security people should have to pay for the mistakes of the company (monopolistic practices, etc.)
It is apparent that "Virus" is an exemplary Latin noun, ending with -us and thus undoubtfully belonging to the 2nd declension, masculine, nominative. Now repeat after me:
You mere heathens only think you can acheive full disclosure. I, however, have created the world's greatest vulnerability, and no one has found it yet! What is even better is that I have since morphed it into a Trojan, appearing harmless. Corporations and individuals alike have been lulled to think that not only is my beloved exploit helpful, but worth paying for! Muahahahaha! But alas, my foothold on world domination has been slowly diminishing due to an unforseen (and very unintentional) fix. It goes by many names, but usually ends in "NIX". These "pioneers" will turn back. There is no doubt in my mind. They will soon yearn for my little friend's features, inadvertantly sending large sums of cash my way. You sorry souls... -bg
IWARS.
People, in general, disappoint me. Politicians even more so.
I'm curious, why not? What do they do differently? Do they not use C?
Please go read Eeye's excellent response. Aleph1 only allowed this to be posted to BugTraq to once again EDUCATE the public on how this type of thinking is FLAWED.
I wish slashdot had investigated this submission instead of just running with it.
aXV1cTswMDR5dS9wc2gwYnFxew
Ahhh hey people the fix for this was out on microsofts site before eEye released the code.
not to disclose any information that concerns the security of your investment is a waist, it hides the potential(sp) for someone to exploit that fact.
any and all security information should be released upon the finding of it, after that, it is up to the company/admins to take care of it there after.
in my opinion, anyone that is complaining about code red is someone that has obviously been bit by it, and right out it shows that they dident take the time to deal with it 2 months before it was a problem in the first place.
i cant seem to come up with a sig.
This is why "security through obscurity" is a paradox inside an absurdity. From the moment a piece of software is available, ALL information contained therein is ALSO available. And that includes information on buffer overflows, other exploits, etc.
Since releasing the information doesn't actually add any information to what is already out there (it merely changes it into a more "readable" form), it makes no sense to question the release of such information.
It is perfectly true that, on the release of information, those who are less willing to examine the code can also find the exploits, but if they haven't the initiative to do the work themselves, they really shouldn't be considered the problem.
The problem remains those who DO do the work themselves, who DO find, identify, and utilize exploits that are NEVER published. Those people are the real danger.
A skript-kiddie downloading a million credit card numbers is an irritant. They just cause a million people to have to put stops out, and get fresh cards. No big deal. Cards get lost or compromised, then stopped, all the time. The problem will be spotted quickly, and the most severe damage will be to a few people's egos.
Place a black-hat in the same situation. The exploit is unknown, unpublished and goes unfixed. Minor "glitches" go unreported and unnoticed. The few complaints are passed off as stupid customers or bank errors. By the time the enormity of what has happened is detected - assuming it ever is - the perp might well be half-way to -owning- a South American country. Chances are, though, that it'll never be detected.
From what I have heard, US banks lose something like $150,000,000,000 a year to computer crackers. That's a LOT. Let's be honest, here. Given that kind of write-off, can they really lose any more money by being open?
Regular companies and corporations are so big and so complex, that your average black-hat could walk in with an elephant and walk out with the payroll mainframe, without anyone noticing for several weeks.
Attempting to keep intruders out by not telling them things is like trying to keep out a burglar by not having a front gate. What good is that going to do? If the burglar can see a door or a window, then the lack of a gate obscures exactly nothing.
You can achieve -some- security through having guards, monitors, etc. The military works this way, and it's generally pretty effective. IMHO, though, working on the holes is even better. And you can't do that, if you're busy pretending that there aren't any there to work on.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
This is just another wake up call. If it helps
anyone understand that they need to take
security seriously, then the price is cheap.
Too bad that's just wishfull thinking.
I'm wondering if we don't need some way to
exploit these **more** so the defenses get
better, sort of like a vaccine. Otherwise
the defenseless organism gets wiped out. I'm
old enough to remember bringing the kids around
to get measles and chicken pox. Now that those
are (sometimes) rare, larger groups of unexposed
population without vaccines (security patches)
get hit harder with greater consequence.
Perhaps if there were a higher level of random
hostility pervading the internet operating
environment - like the air we breath, the
food we eat and the streets we drive - then it
would be a **safer** place overall. You know,
crash test dummies, bumpers that worked (oops -
wishfull thinking again), and fences to make good
neighbors.
cfm
So, someone who doesnt understand much about Internet security posts a naive message to bugtraq. Aleph1 (owner of bugtraq) kills the thread shortly afterwards due to the forest-fire risk.
**6 days later**, someone at Slashdot thinks its worth putting up as "news". Not exactly 'as it happens'.
Well guys, I just hope you've got the asbestos covers for your router sorted out.
Veg
Best disclosure system I know :
1/ Sent a private and secret email to the editor
2/ wait 15 days and Check if anything has been done.
3/ if nothing has been done, tell the editor you will disclose within 15 days.
4/ wait 15 days
5/ if nothing has been done, post the bug and then call the boss of the guy who didn't do a thing.
Of couse, if they tell you "We're working on it", you can keep the bug for yourself and devellop your own first Large Scale Worm-virii and broadcast the direct phone number of the Guy to Every Single IIS in the World 8)
Gosh ! I love my Job 8)
It takes 40+ muscles to frown, but only four to extend your arm and bitchslap the motherfucker
The whole full-disclosure/"Responsible Disclosure" has been raging on the Win2KSecAdvice mail list (from www.ntsecurity.net) since Monday. A lot of good points have been raised by both sides of the issue.
And while I don't agree wholly with any one side, the point that I agree with in that whole mess that goes against this email (clearly for very restricted disclosure) is this:
I want to know why I'm installing this patch. What does it fix? Do I trust Microsoft to fix it? They broke it in the first place! How do I test my system once the patch is applied to ensure the patch actually fixed anything?
Should I have to pay to be part of some exclusive club that gets to find out how these vulnerabilties work? Sounds like printing money to me...
You can't have your cake and eat it too - either I know how it works or I don't. Giving the information to SysAdmins levels the playing field against the Blackhats. You can bet your @$$ they already know about it.
-AutoNiN
VMS allows instructions on the stack to be executed. That capability is used in some complex programs that generate machine code for execution "on the fly".
VMS does not have a history of buffer overflows.
I think that there is some confusion between the iishack exploit for IIS 4.0 and the new IIS exploit implemented in Code Red. When iishack was reported and released by Eeye MS had taken their sweet time releasing a fix. This is clearly not the case with Code Red.
.ida buffer overflow that Code Red exploits existed weeks before the release of the worm. Clearly, Microsoft responded in a timely fashion with a patch before it was a problem. To blame MS for administrators not applying patches is lunacy. Are we going to lay the same level of bile on say... Paul Vixie, for releasing a version of BIND that gives any skiddy root access with a simple buffer overflow? What was HIS solution to that problem?
I think there is some confusion. The patch for the
Information may be a BAD THING, but so are the patches: all a clueful SUPERHACKER has to do is sit on their hands and then take a look at the files updated in a patch. Diffing the two of them will reveal what's changed and have them well on their way to recreating the hole that they knew absolutely nothing about. This is, of course, running with the faulty assumption that the person who found and the person/people who fixed the hole are the only ones in the entire world who knew the details of the flaw.
On the other hand, you can distribute information on what you've found after working with the vendor to see a patch get put out, then release details on the flaw so that administrators can patch their systems as well as be on the lookout for people trying to exploit them. Without information, where do IDS makers get their signatures from?
Locks have a similar fatal flaw: they don't work unless you use them. Let's go find some locksmiths to string up for this horrible oversight.
Easy does it!
This comment has been submitted already, 276865 hours , 59 minutes ago. No need to try again.
why bother rehashing everything i read on bugtraq last week here in slashdot ?
boring.
-- Spankmeister General
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
Since the Chineese decided to release Code Red on us is it legal for us to hack their servers over US phone lines? You can get into trouble for hacking US based servers, but how about chineese and eastern european?
by the tone of the email it was made out as if eEye released the proof of concept code with out notifying Microsoft to the hole first. This is wrong eEye had sent the proof of concept code with details of the explot to Microsoft 2 weeks ahead of releasing the code on their site. During the 2 weeks before releasing the proof of concept code Microsoft had made available a patch to fix this exploit and only after the fix was available did eEye then release the code. I feel who is at fault for the huge outbreak of infected systems should not be layed upon eEye or MS. The fix for this exploit was available months before the spread of Code Red I and II. What it boils down to the blame needs to be placed on UNINFORMED OR LAZY ADMINISTRATION.
...We should have a "Full Public Disclosure Principle" - say, we give the authors of the software 1,5 months to fix the problem, before it is released to the general public.
Any technology distinguishable from magic, is insufficiently advanced.
should get full disclosure.. In the case of windows MS, in the case of Linux the community. Doesn't it make sense that if you can't fix it it's only a liability to know all of the details anyway..
"Even the Devil can quote scripture to suit his purposes" - William Shakespeare
Sure - Melissa et al. For years people have been bitching about the security of executing email attachments in Microsoft Outlook, and the amount of control over the machine that executed attachments have (no sandbox). The initial response from Microsoft was "that's a feature, not a bug", and even though there have been some steps in the right direction, the problem still exists and still breaks out into an epidemic from time-to-time.
I suppose that you could argue that clicking on attachments is more social engineering, but on the other hand Microsoft products are specifically sold as "easy to use". If it's so easy to use, why do users still fall prey to simplistic social attacks?
I'll admit that full disclosure hasn't even helped in this case, though - Microsoft and the whole world has known about the problem for a long time and it's still with us.
My heart bleeds for them - "we have so many security exploits that we can't even take the time to figure out which of them are real". Hint: do it right the first time, and then hire yourself some crackers to do this poking and prodding for holes that until now has been reserved mostly for the black hat community. I don't have much pity for Microsoft's inability to fix their security problems - they dug themselves into that hole by valuing time-to-market, embracing-and-extending, and pseudo-usability more highly than security and actual functionality.
Your right to not believe: Americans United for Separation of Church and
Remeber sourceforge getting cracked a couple of months back? Apparantly, the guy who did this spoke to securityfocus.com about th attack. In this article he says:
"i hack, dot slash or whatever you might want to call it, i do not write my own exploits, i use other people's stuff, and no im not anti-open source, i am however anti-sec. i support the anti-disclosure movement among the computer and network security communities,"
Furthermore, the cracker said he works as a contractor in the field of security, and perhaps it is the ease of cracking so many sites using nothing but published exploits that makes him support the "anti-disclosure movement."
Although I am personally not against full- or partial- disclosure per se, I do think the anti-disclosure movement has a valid point. There does seem to have been a huge increase in cracking activities recently, and although the script-kiddie phenomenon is at least partially due to the rise of the internet/home computer (i.e. more kids with cheap pc's in their bedrooms), I do think that the current fashion for open-disclosure means that security holes spread into the black-hat community faster than most sysadmins apply patches.
On the other hand, if we go back to the anti-disclosure, it will be like pre 90s. The white hats will know one set of holes. The black hats will know a differnet (far more limited) set of security holes. This scenario obviously poses a whole set of different problems.
it's spelled v-i-r-i-i, but pronounced viruses, kinda like netscape.
Just a word to say about this subject. As a network admin with multiple WAN connections, supporting 3 data warehouses I don't have time to explore every vulnerability to the OS's I'm required to support. What I have learned about Code Red is that I don't have time not to explore every vulnerability to the OS's I'm required to support. I need full disclosure. I need the information so I can build my own little Perl scripts that I can enable to test prior to more refined testing tools being fielded. I'm lucky. I'm one of 2 NetAdmins here and we share responsibillity and authority over our systems. I'm the coder of the NetAdmins and I believe in my own ability to test exploits. I didn't do that with Directory Traversal, or with the Indexing Service vulnerabilities in NT, 2K and I'm paying the price for that. Tell us everything. Give us data. I know that I may be unique in my perspective. I'm a Net Admin with a programming background. It's to my company's detriment that I didn't exercise my talents quickly enough to test my systems and find out what server was vulnerable and to what degree. I applied the hotfixes as soon as they were available, but on one server they evidently did not take. I didn't find out until 20 July 2001 when I was out of town on business. If I had applied the fixes, and then tested the servers to see if the vulnerability still remained, I could have been spared embarassment. Shame on me.
Let's just phrase it this way...
Wouldn't cars be safer if there were not public reporting of defects, if safety information went only to the car makers, so they could fix the problem?
I realize this anology has a flaw, being passive defects vs giving attackers key information.
So how about information about the security of your bank. For the moment, let's leave IT out of it. As a consumer, I'd like to know if a given bank is sloppy about their security, because I can vote with my money, and where I put it. A key part of a free market is an informed consumer, and withholding information from the consumer is tampering with the marketplace. (gag terms in software licenses, anyone?)
I can certainly agree with giving the software developer advance notice, but the key word is 'advance', not exclusive or secret.
To take it back to cars, isn't part of just about any safety-related lawsuit a gag order? Is critical information being withheld that would help my decide on a safer car to put my family in?
The living have better things to do than to continue hating the dead.
You're nothing more than a pompous M$ lover. They deserve to be bashed because of the business practices they stand for and the crappy software they produce. I suggest that if you don't like the comments then don't read em. Damn Jerk!!!
I think you're absolutly right. When you try to reason your way around using principles in favor of doing something less painfull you'll end up worse off in the long run. Say it does cost $2 billion to get compainies to get their fixes out immeadatly and for them to start campaigns to get their customers to apply those fixes, and for the costemers to be scared enough to fix them. The value is obviously worth the cost. This worm was public, but just think if it were engineered better and private it could be swallowing up all of your private information or worse. Never take the easy way out. You'll get screwed in the long run.
Im not here now... Im out KILLING pepperoni