CERT And Vulnerability Disclosure 87
Carnage4Life writes "In a radical departure from it's previous stance of security through obscurity, the Computer Emergency Response Team, CERT, has stated that it will fully disclose all vulnerabilities in software that come to it's notice 45 days after the fact whether or not companies have provided a fix. The change of policy can be found at the CERT site and there is also a story on C|net.
The change is not a complete embrace of full disclosure because CERT will not release exploits as some other software security watchdogs do."
Bullshit (Score:1)
This is a MS world right now - I don't have to like it.
Re:Exploits not needed (Score:1)
The users/customers need to know of vulnerabilities. They do NOT need the actual exploit tools. Publishing the vulnerability is one thing, providing a tool that actually exploits the vulnerability helps no one but script-kiddies. THEY are the idiots who are likely to actually download the exploit and then immediately use it to do their little, pointless, damage.
What possible good does it do to give script-kiddies the tools they need to bust systems that, otherwise, they are too stupid to be able to figure out themselves?
It buys them credibility with the vendors. (Score:1)
Now that CERT is saying to the vendors, "look, 45 days is enough to do something, just feeping do it", I hope that corporate buyers will start demanding real action on structural issues. Take the LoveLetter "virus": if a significant number of buyers would tell Microsoft that they should address the issue of hiding important information from the users so that they could make an informed decision on whether or not to open a certain e-mail message, Microsoft might address the underlying issue and fix it once and for all: not just the e-mail case, but also shared file stores and web sites.
Sigh. It has surprised me from the outset that there hasn't been a buyers uprising. People overestimate Microsoft's Evil Empire nature and underestimate the delinquence on the part of users to make their concerns known.
Re:Exploits not needed (Score:1)
The -problem- with exploits is that they are often too narrow minded. They may take advantage of a hole that is much bigger than the exploit itself indicates...leading to people thinking that if they stop the particular exploit, the hole itself is fixed.
A User's Perspective on Exploits (Score:4)
While all of you are discussing the ideological and legal aspects of this, I think I would like to address the practical side.
Very few novice Redhat 6 users, myself included, actively monitor the security problems addressed at bugtraq or securityfocus, out of ignorance or lack of time. However, the Internet is crawling with 5kr1p+ k1dd135 who do, and they have preyed on our system. I do not appreciate the abstract, idealistic attitude of this community, the good-ol-boy mentality that if you aren't an expert administrator, you ought to be hacked by 14 year old malcontents. They used that goddamn wu_ftpd exploit on us and we had to reformat and waste another freaking day reinstalling and upgrading the only OS I've ever personally seen hacked.
Now RedHat wasn't the only distro affected by this exploit; this is truly an open-source security problem. Consumers will not latch onto Linux if it's this hard to keep secure. There are several items your community needs to address:
You might not care if all the "dumb" users go away, but you know what? Then your OS won't win, you will always be stuck in nerd obscurity, and MacOSX will be the #1 unix in the world.
Re:"complete embrace of full disclosure" (Score:1)
CERT has had a history of releasing vague reports about a problem fearinf that embarassing the vendor was a bad idea. IMHO, the more embarassed, the better.
I don't think exploits should be released right off, but upon discovering a security hole, you should immediately release a detailed enough description that an exploit could be written by someone competent in a few days.
Releasing an exploit is something you do after you feel the bug has been out for long enough for someone to have coded one anyway. I would say, 3-6 months after the bug has been disclosed, but probably not at all if the vendor has a patch. This gives vendors enough time to code a patch, but doesn't let them ignore you.
I don't think there is anything about actually releasing the exploit immediately that should be actionable under the law. It should just be considered rude and in poor taste.
That's my personal philosophy, and IMHO, what CERT is doing doesn't go far enough. I don't consider releasing an exploit as necessary to claiming full disclosure. I do consider immediately releasing all pertinenet information to be required.
Re:"complete embrace of full disclosure" (Score:2)
Testing whether or not your particular setup is vulnerable or not sounds like a pretty "LEGITIMATE" use of an exploit to me. I shouldn't have to understand every possible security problem in depth and write my own test exploit just to determine whether I'm vulnerable.
Re:"complete embrace of full disclosure" (Score:4)
I as an admin have legitimate use for it. I'm able to run the exploit against my box, to check if I'm vulnerable. If its a proper description of the vulnerability in addition,i'll be able to check if the flaw is there at all in my version of the software.
Exploits is an easy was to check if you're vulnerable and needs a patch. Its helluva lot easier than to check if you've got the updated libs, and if the program is updated, and versionchecking everything.
Of course, its not foolproof. You may be vulnerable even if the exploit doesn't work. But, if you run redhat, and the exploit is for redhat, then
Furthermore, you say that full disclosure is the way to go. And right afterwards, you say that exploits shouldn't be released. Sorry mac, its not full disclosure if you don't disclose everything. You seem to have misunderstood something.
For example, while MS didn't improve LanMan until l0pht released l0phtcrack, neither was anybody cracking it!
And how exaclty do you know that? When l0pht released the informatiom, security minded people were able to patch their systems, because they forced a fix to be made. If they had not publicised the information, you wouldn't know about it. You wouldn't know that you were vulnerable, and if you had a smartass cracker around, he could run circles around you without you understanding what the fsck were going on.
You seem like a troll, but are modded to 5.. I don't get it.
The number of people actually capable of discovering new holes AND who are shady enough to exploit them is so tiny that the odds are high an average user will never be affected by them. Most of these people spend all their time coding up "exploits" for skript kiddies today anyway!
And how can you be so certain about this? You really can't. What is unknown is unknown. You are doing nothing but theorizing right now.
Btw, as far as I know, slashdot has been cracked once without anyone having any idea on how it was cracked. Furthermore, rootshell.com was cracked about 1-2 years ago. I don't think they've discovered how yet. So, you are saying that the superhackers don't exist, even so, we see this kind of things.
Keep in mind that your enemies are the skript kiddiez, NOT the corporations or end users.
I seem to remember som corporations using more than a year in patching some holes. I think they are my enemies, not the scriptkiddies. And I've been cracked by scriptkiddies. If the tools weren't widely published and available, I would never've known what hit me. (maybe i wouldn't have been hit, but that i can't know).
--
Re:"complete embrace of full disclosure" (Score:2)
I guess they fixed it by now...
L0phtcrack wasn't the first program to crack lanman packets. It was the first that combined all the known ideas into one package easy enough for a scriptkiddie to use.
Re:A User's Perspective on Exploits (Score:2)
Consumers have latched onto a series of OSes in the past which are virtually impossible to keep secure. Lamentably, security ranks a long way down the list of priorities in purchasing decisions. Even when it ranks highly, most people lack the expertise to make a judgement about what comprises security -- WinNT says "world class security" on the box -- and that's the level of depth many people are prepared to explore.
DO NOT post exploits to the general public; insist that securityfocus, bugtraq, and others only allow legitimate developers to view them. Exploits are the equivalent of guns and ammo, and there is a great need for background checks!
I highly doubt this one will ever work -- recent piracy and weak-crypto issues have demonstrated how difficult it is to restrict the flow of information. There are legions of "my leet hax0r expl01t-4rch1v3 hou5e o p4in" sites, and it only takes a single leaking "legitimate developer" before every one of them has a 0-day exploit.
It's probably more feasible when free information flow is used as an advantage -- ready availabiliy of information and the fix, e.g. "Information wants to be free," whether right or not, is a difficult force to fight.
We need to express leadership in the open-source community to make the distros have secure default configurations, and automatically alert users of security problems, and allow them to choose to install patches. This could be integrated with policies at security sites.
No argument with this one -- most vendors are pretty bad about this, because a shiny new installation sells best when it appears to be just bursting with new functionality, and "Install Everything" is still one of the more popular options in your typical installation. Linux distros have an elevated problem with that option because they ship with a ton of software, rather than a skeletal OS-and-GUI-shell which lets you choose whether you want to play Solitaire or not. Though I look forward to the announcement of a vulnerability in Win32 Solitaire.
So, maybe: the installer offers a cronjob to check the updates site every night, or offers to subscribe you to the vendor's security-announce list. The updater (autorpm, update agent, etc) lets the user pick a notify-only, fully-automatic or run-on-request mode. To gain any acceptance, such an updater must provide anonymity (e.g. autorpm against ftp, debian's apt-get, etc), cryptographic security (e.g. autorpm's use of a gpg keyring with the vendor key) and optionality (see above).
Re:A User's Perspective on Exploits (Score:1)
You don't really have to (if you don't run any servers, or server services). You do have to follow your distributors security advices however, but that is the case with Microsoft too.
With Red Hat, just subscribe to their security mail list, and get the appropriate bugfixes from a local mirror. (just like anybody should do if they run Windows)
"DO NOT post exploits to the general public; insist that securityfocus, bugtraq, and others only allow legitimate developers to view them."
It is very hard to describe a security problem in words, without, at the same time, giving the recipe for abusing the security hole. Personally I really don't think, that the posted exploits makes any real difference; The stupid Skript Kiddies probably don't use them much, since they prefer "ready-made" exploit & root-kits (hence their name). The smart hackers really don't need them either.
The routine on BugTraq stems from decades of experience, in dealing with security issues and major software vendors; the problem was, that the vendors _ignored_ security issues, hence the public pressure. Microsoft allegedly have denied a security issue, with the statement, that "it was only a hypothetical security hole", an attitude, that help explains the release of exploits.
But the point is, that BugTraq actually is on the side of the endusers; Without Bugtraq the skript kiddies would roam free on the unknowing publics computers, and the vendor wouldn't really care.
Check BugTraq out for fun, and se how most bugreports and exploits, is accompanied by a patch or a work-around solution. Read their FAQ too, to see more about "full disclosure".
"Realize the useability and security go hand in hand"
No they don't, and that is the problem (and the reason why the Melissa and ILOVEYOU virus spread like wildfire). Security means restrictions, and people don't like that.
A lot of the problematic default services in eg. RH linux, stems from historic reasons; people running Linux, where likely to use it, as a server on a intern LAN. But the Linux landscape has changed a lot; the majority af linux-boxes now runs as a desktop pc, with either dial-up, or xDSL. And I wholeheartedly agree, that all the (Linux) vendors, start to make their distros more secure by default, for this large segment.
Re:Exploits not needed (Score:2)
15 years ago most programers would not believe that you can write a program that overflows the buffer of a second program causing it to do something uninteded other than dumping core. Now people understand buffer overflows are a real issue but only because of the huge library of exploits.
Re:Full Disclosure Good (Score:1)
Without full disclosure, Mr. Security Administrator can't possibly do this. He's reduced to saying "fix everything immediately because CERT says so". This is not a real convincing argument in a world where you have to justify costs and benefits.
Re:Gripe about software companies (Score:2)
It depends on the nature of the bug (Score:2)
Also a decent software provider can't release a patch without THOROUGHLY testing it first.
M$ did that kind of stupidities many times as an example...
Re:Exploits not needed (Score:2)
I would have to agree with this. Further more, by publishing exploits to the general public, you are just giving script kiddies the tools to break into something. Why make it easier for them to break into machines. If they are gonna do it, at least make them code up the exploits themselves. And hey, who knows. That young kid who right now is wipping some exploit up might grow up and turn into a serious responsible kernel hacker.
"complete embrace of full disclosure" (Score:5)
Full disclosure is the right way to go... WHEN handled sensibly. You have no need for a coded exploit - if you can't write it yourself, what chance do you have to understand it? And if you don't understand it, what possible LEGITIMATE use do you have for it?
I am always irritated by people who make flip remarks like "security through obscurity is proven not to work", when the basis for their remarks is that some vendors didn't patch known vulnerabilities in the days when STO was more prevalent. In reality, the aim of information security is NOT to eliminate all security holes. The aim is to prevent legitimate users from service interruptions and abuses. It's not that difficult a distinction, guys. For example, while MS didn't improve LanMan until l0pht released l0phtcrack, neither was anybody cracking it! The theory of some full disclosure zealots is that if all vulnerabilities aren't released and coded up within 24 hours of discovery, some shadowy breed of "super hackers" out there will find it in time and exploit it. Guess what - these super hackers DON'T EXIST. The number of people actually capable of discovering new holes AND who are shady enough to exploit them is so tiny that the odds are high an average user will never be affected by them. Most of these people spend all their time coding up "exploits" for skript kiddies today anyway!
CERT has it right. Disclose the vulnerability to the vendor. Give them A LOT of time to fix it, and a lot of goodwill. Software companies can be slow on their feet - they can't address every problem that crops up in the 12 hours you give them until you announce "they haven't responded". But if the problem is not patched in that liberal amount of time (45 days seems enough to me) THEN feel free to shout from the rooftops and embarrass the suckers.
Keep in mind that your enemies are the skript kiddiez, NOT the corporations or end users. For some reason it is easy to lose sight of that fact in the world of infosec, where everybody believes they are unusually smart and the companies they correspond with unusually stubborn. I know - I work in that field and ego is a dangerous thing. Don't let it blind you to what should be your real goal - helping people improve their lives.
-konstant
Yes! We are all individuals! I'm not!
Re:Full Disclosure Good (Score:1)
hey, if your manager sucks that's a problem by itself
there's no way you can blame CERT for that
clarification (Score:2)
Too Much or Not Enough (Score:4)
Here's the rub, though: there are some vulnerabilities that cannot be fixed in 45 days. 45 days is plenty to fix a buffer overflow in a single software package (or even a common overflow in a group of packages). It is not nearly enough to fix a protocol weakness.
An excellent example of this is the SYN Flooding attack perpetrated on PANIX in NYC years ago. Let's rewrite history and suppose that the attack was mailed to CERT first (and not used in public first). CERT then would mail the details of the attack to the security contacts of every operating system at the time (since the idea of SYN queue resource exhaustion was viable on every IP stack at the time). And then those vendors and maintainers would do what?
Well, fix it, of course, right? The problem is that the fix isn't obvious (it still isn't obvious, years after the attack). You can reduce the SYN queue and time things out, but then you can get in trouble with timing out connections from viable end-hosts. You can use Dan Bernstein's SYN cookies (although it took someone like Dan to come up with these--they are entirely inobvious to the average protocol stack maintainer).
The problem is that the TCP protocol didn't envisage the presence of an entry on the SYN queue (SYN received, SYN+ACK sent, waiting for SYN+ACK to connect) as a resource that needed to be managed carefully. As a result, there's no easy way, in the protocol, to avoid resource exhaustion for this correctly in all cases.
In situations like these, 45 days is woefully inadequate. It's not clear if a year is adequate. I like the idea of forcing vendors to respond promptly and get this stuff fixed. I worry about the trend of using the innocents as cannon fodder (as described by Marcus Ranum, whose homepage at http://www.clark.net/pub/mjr appears to have disappeared. anyone know where it is now?).
Anyway, just wanted to point out that this is not as simple as the shrill FULL DISCLOSURE!!!!! folx are making it out to be.
CERT, full disclosure, exploits, etc (Score:2)
But glad to see they fixed it, maybe it'll make CERT something more then amusing now. Eg: "You just got that fixed? I mean CERT will be releasing an advisory any day now!"
Second, for those who don't understand the role of exploits... I worked for a software house as a sysadmin/manager at one point. It took the IIS valnerability and the speed of a working exploit coming out on BUGTRAQ to prove to our head developer that he needed to check for buffer overflows in code, as he previously felt that creating an exploit would be impossibly hard.
Once again, thanks CERT!
----
Remove the rocks from my head to send email
Re:"complete embrace of full disclosure" (Score:3)
Re:Exploits not needed (Score:1)
The government tried to stop encryption technology from getting out because they feared its use by black hats. DeCSS is an exploit, of course... seems like value judgements are being made about people, not principles.
Re:A User's Perspective on Exploits (Score:2)
Re:A User's Perspective on Exploits (Score:2)
I would like to commend everyone who responded to my post in a very professional and helpful way. Slashdot is at its best when people like you participate. Sorry if I seem like a troll; I would like to see the open-source community succeed, and I'm just pointing out what I perceive as deficiencies. You have all corrected my mistakes, such as forgetting about putting pressure on the software companies themselves. I'm glad that there is some sort of consensus about having secure installations, and I hope there is some sort of effort underway to do something in open-source that provides the functionality of the autorpm pay service from Redhat. Again, thanks for the interesting conversation.
Re:"complete embrace of full disclosure" (Score:2)
Um.... no one was cracking it that you know of. And, let's see now, if l0pht did it then it's fairly likely that a) someone else would and b) relatively soon. Would it not have been much better for Microsoft to have taken care of this problem before someone wrote a crack? After all, you're only guessing that l0phtcrack was the first... a truly malicious cracker wouldn't advertise their methods, as that leads to people doing something about them.
Actually, your enemies are anyone an everyone who threaten the integrity of the data or systems you protect. Certainly, many of these threats seem to come from scrip kiddies, but, to be quite frank, the more serious threats come from the people who are actually capable of creating the scripts (they do have to come from somewhere, you know). Knowledgable, effective crackers do exist, and are a real, if somewhat less prevalent, threat. Even so, don't rule out corporations. The figures for industrial espionage are on the rise, the presumption being that the internet, etc. are providing corporations with another unregulated playground which they can try to abuse in relative safety. Don't make the mistake of focusing tunnel-vision on the script-kiddies... there's more to the world of threats than that.As for ego, well, I do agree that it's a problem in our field (in most fields, in fact), but don't forget to include yourself in that bunch. Do I have ego issues? Yes! Hopefully by recognizing that tendency I can prevent it from being a problem, but it takes aknowledging that ego inflation seems to be a natural tendency to which I am not immune. I think you would do well to remember this, as one of the fatal flaws of any security officer lies in the assumption that they are in possesion of the sole correct methodology - an impression I get strongly from your post.
--
Re:Too Much or Not Enough (Score:2)
It's funny you should mention the TCP SYN attacks on Panix [panix.com], because I actually did E-mail a description of this problem to the CERT [cert.org] a full three years before it was actually used as a denial of service attack. I also wrote to the IETF [ietf.org] main mailing list a more general observation about denial of service attacks, and the need for all ISPs to do ingress filtering of packets based on IP source address in order to have a first approximation of DoS attack source (who you then go and stomp).
The CERT didn't get it. They did nothing about it until Panix was attacked.
The responses on the IETF list mostly moaned about the cost of adding all those filters to all those CPE routers, and how ingress filtering would stomp one mode for mobile IP...
Three years later, people were a whole lot more interested in dealing with this.
Re:Too Much or Not Enough (Score:2)
There are lots of problems where the fix isn't obvious. Its design flaws in the tcp, ip, or whatever protocol. SYN-attacks are design-flaws in the protocol.
I agree with you that syn-attacks, and other DoS attacks, don't seem to have an end. The point is, we cannot actually say that it has been a Bad Thing (Tm) disclosing them. They SHOULD be pointed out. As another one that replied to you said, he wrote a paper about it three years before Panix. Nobody was interested because the problem was only theoretical. It would be to expensive with ingress filtering, it would ruin mobile ip, and so forth.
The solution to the syn-flooding attacks are of course ingress filtering. THe trouble is that nobody wanted to do that, before the "syn-flooding-tools" existed. And seriously, do you think it would've been better if nobody ever had disclosed it? Do you really think its better to have an extremely weak infrastructure, instead of having the infrastructure going through peer-review again and again, until you find all the bugs ?
Personally I'm glad the synflood-attack-tools were made publicly available. I'm glad that smurf was made public
Oh, I could rant on forever, but I think i'll stop now.
--
Re:A User's Perspective on Exploits (Score:3)
Or, as it was for me, SuSE 5.1 or 5.2 (don't remember which one) that had the qpopper vulnerability. I was cracked, and afterwards I *love* the resources secfocus, rootshell, packetstorm and so forth has provided for me.
wu-ftpd exploit
If an open source program has a security fix , people will run a diff, and find the bug. If you've seen the exploit floating around, they are mostly written by kiddies / friends of kiddies. People that put "DO not distribute" in the top of the comments of the code. The code is of course circulated among 'the eLiTe uND3Rgr0und' - and after a relative short time, it gets onto kiddie-hands, via irc or whatever. They don't need bugtraq for this.
DO NOT post exploits to the general public; insist that securityfocus, bugtraq, and others only allow legitimate developers to view them. Exploits are the equivalent of guns and ammo, and there is a great need for background checks!
No way. I insist on being able to review the exploits, review the vulnerabilities and so forth. I want to patch my holes, but I want that they're there before I go ahead and patch. Also, the exploits puts a fire in the asses of the developers. It makes sure that they do produce a fix, and fast. I, as a security admin for my company want those fixes asap. I don't want to live months without them because there is a bunch of lazy admins in the world that should "be protected". No thank you..
We need to express leadership in the open-source community to make the distros have secure default configurations,
Agreed. Nothing but sshd and auth should be started by default. Everything else than that should have to be specified explicitly, imho.
and automatically alert users of security problems,
No way. NOOO way. I don't want the distro to automagically check for anything. That should be made an OPTION to ENABLE, not something that should be forced upon people. NO way..
*shudder*
Realize the useability and security go hand in hand, and consumers, in the long run, are going to support the OS that gives them the fewest headaches
Yup, and therefore distros should be shipped without many daemons enabled by default. The full disclosure policy is not affected by this.
--
Re:Too Much or Not Enough (Score:2)
Oh, I forgot to comment on this. Are people still taking Marcus Ranum seriously? After his speech on blackhat this year? Of course, one should embrace new ideas and so forth, but hiding the exploits, and not letting the public see vulnerabilities is hardly a new idea. It was the way things worked in the past. And the pasts show that IT DOESNT WORK.
I don't care how many "innocents" that is used as cannon fodder. I want to be able to make sure that MY system is secure. The same applies to every other security conscious admin out there. We scour bugtraq, pen-test, vuln-dev, incidents, and so forth. I want to be able to secure my system damn it. I don't want the information HIDDEN from me.
If people don't care about their security. *BAD FOR THEM*. I want to be able to secure MY systems, and I want people equal to me, to be able to secure THEIR systems, without having to wade through a bunch of NDA's, being part of special commitees or whatever.
Furthermore, how do you think programmers ever will learn to program securely, if they can't follow security lists where exploits are shown and openly discussed? Heh, they should teach themselves magically perhaps?
blargh, no Ranums ideas are outdated, and really, I lost all respect for the guy during this years blackhat briefings in las vegas.
--
Re:A User's Perspective on Exploits (Score:2)
in other words i expect them to be skilled.
and for sysadmins of linux systems i expect that even more because they have a freely available os they can install on as many test boxes as they like. and there are docs up the wazzoo and tons of other resources.
in other words, *you* did something stupid, *you* need to take steps to fix it.
CERT is useless nowadays (Score:3)
1) CERT is way behind anybody else
They issued an advisory about wu-ftpd and rpc.statd in July or August when exploits, and proof of concepts, were on bugtraq in late May.
2) CERT has turned into a laughing stock.
The funniest thing I think I've seen in a long time is Jamie Rishaw's mock advisory about the Sony Aibo [securityfocus.com]. This is just a slap in the face of CERT.
I'm not mocking the concept... an entity such as CERT serves a very big purpose. Being associated with the SEI one would think a much more active one. However since white hats are just as skilled as the black hats it doesn't take somebody at the SEI to write an exploit. By the time they do, somebody has already posted it to bugtraq or it's already out in the wild.
Just my $.02.
Smart Move (Score:1)
I'm surprised this didn't happen sooner (Score:2)
Sometimes you by Force overwhelmed are.
not REALLY... (Score:5)
Exploits not needed (Score:3)
Besides, it shouldn't take anyone more than a day or two to write an exploit, anyway.
45 days? (Score:1)
45 days seems like a long, long time. In a single day, the average kiddie can go through a hell of a lot of computers. Do vendors really need that long to provide a fix, or are they just dragging their heels?
This won't be good for Microsoft (Score:1)
Open software is no biggie it they did it 45 hours later! MS might not fix a bug after 45 weeks!
45 days too long? (Score:2)
Of course, if you consider it as 15 days to put out a patch and 30 days for people to get it installed, then it isn't too bad.
Personally, I think it should be a two-tiered policy. 15 days of secrecy once the software vendor has been notified. Then, if a patch has been released that fixes the problem, an announcement of "unspecified security problem" with a reference to the patch should be released, followed by an explanation 30 days after people have had a chance to install the patch. If no patch is released, then the full details are released at the end of the initial 15 days.
Oh well, 45 days is still better than never--much better.
what is their point? (Score:1)
Re:Exploits not needed (Score:2)
I think its intended to persuade the company to fix it. 45 days is a reasonable amount of time to fix these bugs as long as the company is expecting that they might have to. It would be irresponsible to leave a security hole for longer than is neccesary to fix it, but many companies are irresponsible.
It's about time... (Score:1)
Security through Obscurity (Score:3)
Case by case (Score:2)
There shouldn't be a blanket rule for security disclosure. If some thing is broken in Word fine post that up in 45 days if it not fixed by then the company might get a little bad press. But if there is something broken in a medical database (you notice that medical computers are always used to curry favor in these examples?) and they can't get it fixed in 45 days should the exploit be released anyway?
I say email the manufacturer, read what they have to say and if it seems like they are just sitting on their butts make the information public. But if doing so would endanger public safty maybe a different rule needs to be applied then "release after 45 days"
Time, the net, and your good nights sleep (Score:1)
Time taken to fix a security hole on an most BSD and Linux distros 10min-8hrs
Time taken to fix a security hole on a microsoft distro 1day - never
It's a welcome change, in the right direction (Score:2)
It's good that CERT are making strides in the right direction, as it will force tougher, faster action on the part of companies. Something that those companies have tried to avoid altogether through the new copyright acts, which made them exempt from haveing to make fixes.
The biggest question that remains, though -- is CERT, SecurityFocus, etc, legal, now? After all, publishing security alerts IS a form of review, unauthorised reviews are illegal, and I can hardly see names like Microsoft or Sun actively encouraging people to publish major security holes.
Really? (Score:1)
Oh well, time to go bury my computer in the backyard.....
Not as bad as it sounds... (Score:1)
Software is bad enough now w/ Full Disclosure (Score:2)
The point is that with the practice of full disclosure, there's a real opportunity for upset customers and damage to reputation for the vendor who released buggy software..... I'd guess that software vendors would do even less testing and concentrate even less on security if they knew they were free from the risks associated with full disclosure.
If anything, what's needed is something that punishes software vendors for buggy code.
Re:Security through Obscurity (Score:3)
Three days is short for a large organization. Somebody in charge needs to be convinced of the problem (managers do have many responsibilities and despite what we might hope to believe, fixing vulnerabilities cannot always be worked into a tight schedule). Then a competent developer needs to be allocated to do the work.
Most organizations will have to do some sort of quality assurance/testing on all changes to the software. It's irresponsible to not do this. That's another group, another manager, another several days. If you're close to an already-scheduled release date, the fix will probably be bundled in there. It costs A LOT of money to create new installation media, to mail the fixes to customers or to even go through (yet another) group to provide fixes on an external FTP server. In all, 45 days could be quite short!
Opinion [flamebait] section - it seems that in an open source environment, the testing sometimes isn't quite as disciplined (offset by more frequent releases). An acceptable fix may already exist in the disclosure report because somebody other than the programmer who applies the main source tree fix has been able to think about the problem. This also reduces the time to provide an official fix for this sort of project.
Re:"complete embrace of full disclosure" (Score:4)
It's funny that you mention Microsoft during your argument about giving vendors time to fix things. Microsoft won't even fix widely known vulnerabilities, much less things that are pointed out to them and kept private. You're talking about the company that maintained for DAYS after ILOVEYOU destroyed data everywhere that there was absolutely no problem with the way Outlook worked. They had been notified of this problem MONTHS before ILOVEYOU hit, and chose to do nothing. And then after it hit, they still chose to do nothing for a few days.
Keep in mind that your enemies are the skript kiddiez, NOT the corporations or end users.
Hmm, none of my friends have been sued by script kiddiez, or been threatened by their lawyers. I'm not saying I'm in love with script kiddiez, but the corporations are capable of doing a lot more damage.
Re:Exploits not needed (Score:3)
I'm not trying to be a smartaleck; it seems like an interesting question to me.
Re:Too Much or Not Enough (Score:1)
Re:Exploits not needed (Score:1)
--
To go outside the mythos is to become insane...
Re:Exploits not needed (Score:1)
In other words, you may have the right to stand up on a soap box and say whatever you want. But I don't have to give you the soapbox.
Re:Full Disclosure Good (Score:2)
Re:Sounds good to me... (Score:2)
Re:Software is bad enough now w/ Full Disclosure (Score:2)
Re:Really? (Score:1)
Re:Gripe about software companies (Score:1)
Re:A User's Perspective on Exploits (Score:2)
Very few novice Redhat 6 users, myself included, actively monitor the security problems addressed at bugtraq or securityfocus
Then perhaps you should. Heck, if you don't have the time to wade through Bugtraq, then subscribe to your distro vendors security notification list. They're typically only a day or two behind us. Or install our pager app, and configure it to mail you when one something you're running has an advisory released for it.
Or if you just refuse to watch for patches, then run OpenBSD. It's not totally perfect, but it will allow to you be a lot less vigilent than most other OSes.
Or do like most of the world, and wait until you get nailed. When you recover, apply all the security patches at the time as well, while security has your attention.
DO NOT post exploits to the general public; insist that securityfocus, bugtraq, and others only allow legitimate developers to view them.
Exploits serve many more people than just the attackers, and there is no such thing as a list of "legitmate developers".
Realize the useability and security go hand in hand
Actually, they're quite in opposition.
Re:"complete embrace of full disclosure" (Score:1)
Second, you say "You have no need for a coded exploit - if you can't write it yourself, what chance do you have to understand it? And if you don't understand it, what possible LEGITIMATE use do you have for it?" but without exploit code how does one test to see if a security hole has *really* been fixed, if you can't test it?
Code is the langua franca of the open source movement, code is often the best possible way to demonstate a security hole to programmers, and more inportantly, what mistakes other programmers should try *not to make*.
Third, and main reason that I agree with full disclosure, is the idea that sucurity comes when all the good guys have every possible tool at their disposal to secure their networks. I don't want company A (cough Netscape) or B (cough Microsoft) should sit around debating if they should release information about security problems, or trying to pretend problems don't exist when they do. I want the businesses that I work with to trust me, and to let me be the judge of how vulnerable I am.
Re:Exploits not needed (Score:2)
cert (Score:1)
--
Peace,
Lord Omlette
ICQ# 77863057
Re:Exploits not needed (Score:3)
Developers of similar code also have a keen interest in the exploits. As do writers of secure code. When the exploits are analized, often they relveal areas of exploration which heretofore might have been thought completely safe, or whose danger was unknown. Executable stacks and printf format strings come to mind here (a hardware problem and software sloppiness).
Besides, it is just against the freedoms that this country was founded upon to restrict speech.
Warner Losh
FreeBSD Security Officer
Re:A User's Perspective on Exploits (Score:1)
No way. I insist on being able to review the exploits, review the vulnerabilities and so forth. I want to patch my holes, but I want that they're there before I go ahead and patch. Also, the exploits puts a fire in the asses of the developers. It makes sure that they do produce a fix, and fast. I, as a security admin for my company want those fixes asap. I don't want to live months without them because there is a bunch of lazy admins in the world that should "be protected". No thank you.
No. Make an exploit. send it to to developer. Publish it on bugtraq only if the developers don't respond. exploits are ammunition. handle them with care.
Having developers/distributions distribute fixed versions before exploit gets wild is win for everyone.
Re:A User's Perspective on Exploits (Score:2)
Of course notifying the developer first, and give him a week or two to make a fix is a nice thing to do, as long as the exploit isn't already found in the wild.
But, it should always be posted to bugtraq when a fix is issued. Both for education and so that admins may test their systems.
Information about the holes should be made public, including the information on how to exploit them.
Having developers/distributions distribute fixed versions before exploit gets wild is win for everyone.
That depends. Personally I really like the idea of pushing closed source developers a bit by publishing the exploit before contacting them. It makes an incentive to open source it. If it had been open source, you would've published a patch along the exploit.
I'm sure those who use closed source solutions will disagree,
--
disclosure for some (Score:1)
The Meaning of Life [mikegallay.com]
They should just make it illegal. (Score:4)
Full Disclosure Good (Score:3)
Security Admin: "We need to immediately upgrade all our servers to fix a serious security bug?"
Executive With Money: "What's our exposure if we don't?"
Security Admin: "I don't know. CERT just says to fix the bug."
Executive With Money: "And we are supposed to pull people off our Vitally Important Marketing Strategy Project to immediately fix a security problem, when we don't know what the problem is and what it costs us?"
BugTraq has it right (Score:3)
A lot of the "early" reports are motivated by the desire for credit for finding the bugs. It might seem petty and small minded, but so what? If that's your motivation for putting in useful work and publishing, who are we to criticize: go to it. If the companies/developers that have the security hole in their products enhance the glory for the discoverer, they might get more cooperation.
But early reports with exploits really light a fire under the fixers and create more awareness in the vicitms and potential victims, so in the long run it's a good thing, IMHO. But, MHO opinion doesn't matter: as I said, it's all about free speech.
Re:Security through Obscurity (Score:2)
With GPL and BSD code, you will get a lot of security experts looking into it immediately. A large company can't afford that.
CERT's Change in Policy (Score:3)
A Polyester Law Suit (Score:1)
1) Unauthorised reviews are illegal.
2) In order to bring suit, MS writes a statement that SecurityFocus is publishing unwelcome bug reports, an illegal review of their product.
3) SecurityFocus never gave MS the right to issue a statement about the SecurityFocus product/service.
4) Therefore MS is breaking the law it's trying to prosecute on, just by bringing the suit.
Sorry. I'll be quiet now...
Drake42
Gripe about software companies (Score:1)
The frustrating part is that the customer ultimately loses the most when an exploit is used against software they're running. In a way this is good - the more they suffer, the less tolerant they will be of insecure software - hopefully putting the vendor out of business or causing them to change their ways. Of course, in the meantime, they pay the price.
CERT is no longer an acronym (Score:4)
According to their FAQ [cert.org]:
CERT" does not stand for anything. Rather, it is a registered service mark of Carnegie Mellon University.
Its history, however, is that the present CERT® Coordination Center grew from a small computer emergency response team formed at the SEI by the Defense
Advanced Research Projects Agency (DARPA) in 1988. The small team grew quickly and expanded its activities. As our work evolved, so did our name.
When you refer to us in writing, it's OK to refer to us as the CERT® Coordination Center or the CERT/CC. Although you should not expand "CERT" into an acronym, it's appropriate to note in your text that we were originally the computer emergency response team.
OT: Crabs and Octopi (Score:2)
Re:Case by case (Score:2)
Pfffft... (Score:2)
Get the credit yourself. =)
Re:This won't be good for Microsoft (Score:1)
45 days: quite long (Score:1)
The sysadmins who need to be able to identify the security level of each components will be exposed to the 45-day black period. IMO, it is way too long. Sometimes, just knowing the nature of a security hole is enough to find an appropriate workaround and this doesnt have to wait 6 weeks.
I don't understand why they have chosen that 45 days magic number. It depends so much on the security hole.
I (with others) maintain an open-source software (delivered without any warranties). However, if I find out a security problem in our software, as a responsible maintainer, I would announce it immediately on the mailing list/web site and fix it as soon as I can. Unfortunately, you cannot expect this behaviour from major vendors or else, they wouldn't have put pressure on the CERT to remain protected for this period.
So my point is: "protect people, not vendors".
A Hacker's Perspective on Exploits (Score:1)
Basicly a server is granting limited access to the world. Even if that server runs only to deliver data to 3 people around the world it must grant enough access to everyone that it may verify the identity.
Any time you grant limited access there is a danger of a defect granting unlimited access.
"Dumb" users generally don't run server software and don't grant any access to start with.
They only run CLIENT software. Unless the client dose something amazingly stupid (like run programs as part of e-mail or wordprocessor files or use wordprocessor files as e-mail) the user is generally safe from harm.
(People or companys who ship client software that allows such things to happen shouldn't be trusted to write ANY software.)
If you run a server (like NcFTP) you really should know what your doing and read the BugTraps etc.
If your just a "Dumb" user then just use clients known to not do stupid things (like run scripts in e-mail, word processors or web browsers... or use word processors as net clients)
DeskTop Linux systems really should be devoid of server software as it's an unneeded security risk.
If you arn't an admin you shouldn't act as one...
If you are going to run server software you need to take full responsability for this...
There is no such thing as a "User friendly" server.
On this note... MacOs and Dos are the two most secure Internet operating systems.
This becouse they come shipped Internet UNready..
(Dos dosn't need Windows for Internet access.. just an Internet Network driver)
The only software running is the software being used.
Linux distros generally come with a bunch of servers installed by default and that is bad news for a workstation...
From my side...
This is the game of keepping crackers in the dark.
We tryed this in the 1970s... The result was techs who didn't know enough about security to protect themselfs against crackers.
This gave crackers the image of "All powerful hackers" in the 1970s.. but in the 1980s the reality came through as it was just a matter of not doing some really stupid things.
The techs didn't know thies were stupid things becouse they weren't talking to each other hoping to keep crackers in the dark. In the end only the techs were in the dark.
That is the problem here. In trying to keep the script kiddys in the dark you WILL keep they techs in the dark. That dosn't mean you'll keep the crackers in the dark.
If you publish NOTHING you expect the defect will be fixed before a cracker will discover it. The chances of this are increadably small.
If you publish the fact that the defect exists "I" can remove the offending software. The crackers can publish an exploite for script kiddys and a bugfix will take an unsuaully long time as most of the good guys don't have an exploit to work with.
Or you can publish an exploit...
"Dumb" users as a rule don't have anything to worry about.
They don't run the kind of software that makes cracking posable...
"Dumb" in quotes BTW becouse.. they aren't dumb just not techs. Thats gotta be reasonable.
I think however the casual user should know as much about computers as they do about cars.
Not enough to build one from ground up or how to fix an engen.. But enough to know to put gass in the tank and change the oil.
Yes the avrage user should know if a pacage he is using has a defect. But for now the News media dose that job pritty nicely... Malisa, and "ILoveU"...
They need not worry about defects in NcFTP.. as a rule the avrage user shouldn't be running NcFTP to start with... When they are.. thats the problem to fix...
Obscurity? (Score:1)
These people are just trying to keep a secure system. You cannot do that very well by just telling all the script kiddies how to exploit your own product. ESPECIALLY when the other venders do not have a patch to fix the hole.
I personally commend them for waiting 45 days. There is no need for immediate anything. All this will do is add more script kiddies, more downtime, and LESS security. Youall seem to want the greatest security possible. Well I can tell you that if you leave yoru front door open, its not gonna do you jack shit.
Re:Exploits not needed (Score:2)
Who do you think your system administrators,
network managers, stock brokers, insurance agents,
etcetera, are? It is the General Public who need
to know about these things, whether they can fix
them or not!
Re:nice troll (Score:2)
but you forgot the first amendment makes 'unauthorised' reviews legal.
In the sense that you can't go to jail for it, yes. In the sense that you can't be sued into poverty, NO. That's the problem with the civil courts today, any big company can pretty much wipe you out at will unless your case can capture enough public attention (a big gamble vs. just shutting up).
Sounds good to me... (Score:3)
Second, by publishing the details, and saying "hey, you knew about this for 45 days; don't you think your customers should know?", you're encouraging software companies to get their act together.
If left to themselves, no, they won't fix bugs out of the goodness of their hearts. The only people this sort of thing affects are the consumers; big businesses have firewalls and probably use better, more expensive products internally, wherever possible.
I think it's pretty sad that it has to be this way, but that's the way it is. Taking a laissez-faire attitude to big software companies doesn't seem to work, because there is too much potential for abuse.
I also don't like the whole "unauthorized negative reviews aren't allowed" business. Who cares about freedom of speech, eh? We can have unauthorized biographies of Bill Gates, and not unauthorized reviews of Front Page. Whatever you say, guys. For example, I did a lot of benchmarking between DOS and Linux's DOSEmu; my findings at the time were that DOSEmu was about 3% slower in raw CPU than actual native DOS (testing using the DOS 32-bit BYTEMarks), but that defragging a native DOS partition was *much* faster under DOSEmu, due to Linux's cache subsystem. Those are the facts; why should they be censored just because someone else isn't happy about it?
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
45 days? (Score:1)
45 days is a looong time.
Just think of all the things hax0rs can do to your server in 45 days.
At least if you knew about the exploit you could prepare yourself, even in a closed source environment where it takes a while to get a patch.