On Wed, 3 Dec 2003, JoeHill wrote:
Again, facts and reality fly in the face of this argument. Hackers are usually, if not always, aware of these vulnerabilities before the security "establishment", and certainly before software designers can come up with a
Years in the security arena make me disagree with this statement. Most "Hackers" (I prefer the term Crackers but there you go) are script-kiddies. The number of Black Hats (people who are actually serious crackers in their own right) is, and has always been, very small. Far smaller than the security establishment. Most exploits discovered these days are found by those who launch a concerted effort to detect them. By sheer number and amount of effort most of the people who discover exploits are in the security establishment and are not Black Hats. I, along with most security professionals, maintain that the vendors/developers are better off receiving some amount of warning before the exploit goes public. This period can be quite short: 2-4 weeks is fine. Lists like Bugtraq now have specified grace periods that a vendor should have to fix a problem. If they haven't patched after this period, then it is time enough to release the exploit to the world. The problem with this is approach is that while it definately speeds up lazy vendors it creates a race condition: Will the bad guys get to a working exploit before the good guys get a fix out. The reality is the idea of providing vendors a grace period before releasing info on a vulnerability/exploit has been working well for many years and we have all benefitted from it. Most exploits fixed in this way don't get the media attention of ones released on an unsuspecting world so the hard work of many security professionals goes unacknowledged (how typical :)
patch. Full public disclosure is one way to give the vast majority of users a
Not true. The vast majority of users can't fix the problem for themselves. They are reliant on a vendor (using the term generically here to include OSS development teams) and the public disclosure has just put the vendor at odds with Black Hats who now know about the exploit. Immediate public disclosure just creates a situation where bad buys & good guys are working on the exploit at the same time, instead of providing the vendor with a head start to getting a fix.
head start, before a patch can even be issued, so that they can at least be aware of the risk. In fact, following this logic, it could be proposed that
Most exploits have few or no ways of mitigating risk without taking down services/servers so knowledge of the risk without viable means to protect against it is only of limited use (trust me I've been there :) It does keep you up at night watching firewall and IDS logs though.
disclosure be even *more* widespread, as soon and as widely as possible. Security issues are not solved by a patch, they are mitigated by awareness.
Software vulnerabilities are normally fixed by patches but I'll agree that security overall is more a function of awareness. I think this sentence mixes up too different concepts (specific security issues vs security procedures and knowledge).
Finally, there is no way to develop an enforceable "policy" in this
Do you follow Bugtraq? The policy of advising a vendor first is not formally enforceable but it works anyway. Peer pressure can be a positive force in some instances. Well, there's my position. I won't be replying to this thread again unless interesting new material is added. I find all too often that people will follow up, just repeating (or slightly varying from) what has already been said and the arguments go round and round. As far as I'm concerned Joe and I have differing opinions and have both expressed them now. I won't waste time following up if I'm only going to be repeating what I've already said. Rob -- Robert Brockway B.Sc. email: robert-5LEc/6Zm6xCUd8a0hrldnti2O/JbrIOy at public.gmane.org, zzbrock at uqconnect.net Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah -- The Toronto Linux Users Group. Meetings: http://tlug.ss.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml