Full Disclosure mailing list archives
Re: Security Industry Under Scrutiny: Part 3
From: "David Howe" <DaveHowe () gmx co uk>
Date: Tue, 10 Dec 2002 15:13:29 -0000
at Tuesday, December 10, 2002 5:12 AM, sockz loves you <sockz () email com> was seen to say:
If anyone has learnt anything in security over the years, it's that "security through obscurity" DOES NOT WORKplz explain why? so far all the explanations i've heard have been self- sealing arguments backed up only by simplified models and varying degrees of 'faith' in the security industry.
Because if your algo is secure, you don't NEED to rely on it being secret for it to work. This doesn't mean that you need to show everyone and plaster it all over a website - but you shouldn't care if someone can see the code, and in fact, if you can get another (or as many as possible) security professional(s) to look at your code, they may find security faults you missed; as long as you don't give them your key (and they can't break it) your system *should* remain secure. Relying on your actual code being secret breaks the second someone else gets a chance to look at it - and protecting an entire site from read access, forever is not feasible. If all else fails, there is always "thick wallet" cryptoanalysis - there is always *someone* onsite who can be bribed to place a bug or swap a "failed" backup tape for a fresh one before it hits the eraser/furnace/whatever. In the early days of unix, even the *passwords* file on a server was readable - it was understood it didn't matter, as it wasn't possible to obtain the passwords from the file (later on, computing power reached the point where it *was* possible to reach the passwords by brute force, but then, it is almost always possible to break some passwords on a box by brute force; I particularly like the reverse password approach banking-site crackers use :)
what others should i have included that were relative to the debate? i assumed that if i was describing the flow of information between whitehats and script kiddies, then i would not need to list any other adversaries because they would have been outside the scope of the email. perhaps i was wrong? then again you could mean here that fake-whitehats with fake-advisories are also kinds of adversaries? i am not clear on this.
I think what he is suggesting is that, regardless of your throttle of information from whitehat to everyone (including the blackhats and kiddiez) there are other channels of information available to those whose hats are not spotless; the people who would lose the most information if whitehat disclosures were removed entirely would be the site admins and other whitehats.
The solution you present for secure computing, is indeed a purely political scheme, and not a technological scheme, for the goal is not the reduction of vulnerabilities, but _the reductions of REPORTED of "security violations"_.that's correct and incorrect. the goal is to change the way vulnerabilities are reported. it isn't security through obscurity really, because a responsible security architect would be notifying the software vendor alone... and not the rest of the world. what i am calling for here is not an end to bug reports but a beginning of maturity and responsibility in the industry.
Unfortunately, this is the way it used to be. Full disclosure isn't so much a tool to get vunerability information into the hands of the deserving (and undeserving of course) as a tool to achieve change; back before FD was common, literally hundreds of people would report the same vunerability to the vendor, and be told they were the only one, that it must be an isolated case, and that the next release would fix it (of course it wouldn't, but that silenced the complaints for a while). Now a *responsible* whitehat will alert the vendor, but also let the vendor know exactly how long he is willing to wait for a response before he dumps the information (with proof of concept; no vendor before FD would even admit a bug existed unless you gave them proof of concept) to every channel in reach. Name and shame is a PR disaster, and it then makes financial sense for the vendor to do something about it (and try their best to spin it positively; "look, we had a bug and we have patched it before any harm could be done") rather than face plummetting sales due to lack of consumer confidence. That some vendors (a fair few in the early days and occasionally even now) prefer to try and use their potential loss as a legal club to silence the discoverer (while doing nothing to avert the eventual damage to customers they aren't liable for) shows only that vendors can't be trusted to do the right thing unless they are shamed into it. It is sad that some whitehats are not responsible; In particular, ISS in rushing out a vunerability alert (with full exploit code and a remote shell) for IIS without telling MS about it at all (in order to promote their own vunerability scanner) probably did more damage to the case for "responsible disclosure" than all the script kiddiez combined.
BLACKHATS ALREADY KNOW AND HAVE THIS INFORMATION! BLACKHATS DO NOT DISCLOSE!i think that it is unreasonable to suggest that everything that has been churned out on bugtraq in the last year was discovered by a blackhat.
no. let us assume there are four groups 1. whitehats working to find vunerabilities 2. vendors working to find vunerabilities 3. blackhats working to find vunerabilities 4. site maintainers looking for suspious-looking entries that might indicate a known or unknown vunerability The first group maintain full disclosure; they (if they are responsible) notify the second group so that they can release a fix at the same time as the disclosure (but note bruce's curve for actual vunerability over time) The second group are interested purely in PR spin - they will patch as unobtrusively as possible, often leaving a patch for months until it can be rolled into an unrelated issue (such as a protocol enhancement or improved driver) and patched without disturbing the peaceful contented sleep of their customers The third group work just as diligently as the first group; they notify only each other (so have a slight head start over the first group, but only slight as they trade knowledge, not give it freely, so the trades are begrudged and never contain the most valuable information). They also benefit from the first group's information, but recognise anything that widely publicised is not valuable (in a trading sense) to them, and will be watched for in other code (so may even devalue information they previously considered valuable) The last group will use the information from the first group to prime them on what sorts of exploits to be looking for; this is one of the few groups where actually finding nothing is a victory (vendor teams may find themselves downsized if they find nothing :) provided there is actually nothing there to find. Finding nothing while there *is* something to find though may well get them downsized, so they should be as diligent as possible keeping up with the "state of the art". They may also drop potential vunerability information into the same channels that the whitehats use, so that smarter minds can pick it over and possibly find something they missed. (in case you are wondering, I consider myself in group 4; this should let you know at least what my vested interests are :) now let us assume we remove group 1 entirely; if they don't have any channels, they become equivilent to group 2, just not paid to do it - and their numbers will drop drastically. group 1 will no longer exist group 2 will find they have less help; not only do they have less information from whitehats directly to them, but *comparative* information - information on other vendor's problems that might be in their own products - is also lost group 3 will find they have less competition; not only does every exploit they find have a longer lifetime (due to lack of reporting) but they can apply the same principles cross-vendor and exploit several different systems at once; odds are good that any patches that *are* issued are issued blind (there is no fanfare and they are rolled into "functional" patches) and therefore there is no incentive for sysadmins to install them; after all, a working system may develop problems if you apply a patch; if it ain't broke..... group 4 will be more or less isolated; there will be no information they can use to educate them on what "suspicous" activity looks like; vendors will actively downplay any problems they find, some random future patch *may* repair the vunerability, or simply address their individual case without addressing a more general problem; their managers will rely on vendor glossies to evaluate security strength (ok, they do that anyhow :) and they won't know a bad decision from a good one; compromised systems may *remain* compromised for years, and when the compromise is discovered, the organisation will downsize the "sacrificial" technical staff member, then pay some vendor to install a completely different vunerable package.
whitehats find bugs to make themselves famous, make money, score advisory brownie points, and those bugs can be *anything*. i dunno about you but the only bugs i've really sought after are the ones that will help me achieve my individual goals.
Its how the game is played - whitehat reporting (like open source development to a great extent) is a reputation game; those who are publically good at it gain respect (which may or may not spill over into improved work opportunities, but in any case are worth having just in themselves) at the expense of vendors who suffer reputation loss (and hence profit loss) only salvagable by expensive security patching they would not otherwise consider economic to perform. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- Security Industry Under Scrutiny: Part 3 sockz loves you (Dec 05)
- <Possible follow-ups>
- RE: Security Industry Under Scrutiny: Part 3 Steve W. Manzuik (Dec 05)
- RE: Security Industry Under Scrutiny: Part 3 sockz loves you (Dec 05)
- Re: Security Industry Under Scrutiny: Part 3 Silvio Cesare (Dec 05)
- RE: Security Industry Under Scrutiny: Part 3 Richard M. Smith (Dec 06)
- Re: Security Industry Under Scrutiny: Part 3 Silvio Cesare (Dec 05)
- RE: Security Industry Under Scrutiny: Part 3 John . Airey (Dec 06)
- Re: Security Industry Under Scrutiny: Part 3 sockz loves you (Dec 09)
- Re: Security Industry Under Scrutiny: Part 3 David Howe (Dec 10)
- Re: Security Industry Under Scrutiny: Part 3 John (Dec 10)