Mailing List Archive

Re: Re: it\'s all about timing
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

How about some people are not lookin for them, they are so glaringly
obvious that they literally leap out at you. How about some people
have no time or interest to make a a job of submitting it and monitoring
what the vendor does it with. How about that! Some people find them
and simply submit them. There be done with it.

It is interesting that the people screaming loudest for some sort of
order in the submission of bugs, are in fact non-bug hunters at all. Rather
a vocal group academics who intent of have their name on a draft or ratified
document they came up with. Sure some may have posted a few findings but none
are consistently doing so, and the bug hunters, sure don't sound like they need
some else telling them what to do. You don't hear them crying to for order.

Wonder why that is.

There is always a group that will want to try and harness free energy.

On Fri, 02 Aug 2002 15:44:19 +0100, full-disclosure@lists.netsys.com wrote:
>I propose an exercise:
>
>Why do people look for vulnerabilities?
>Why do people publish vulnerabilities?
>
>If you take the broken window example Evrim Ulu has proposed, it is
>clear that most of us do not walk around the streets carefully examining
>windows to see if they are broken. Sometimes we spot a broken window,
>but we don't actively look for them. Unless, of course, we are the shop
>owner. Or a burglar.
>
>People look for vulnerabilities for the following reasons:
>
>- They want to stress the code they are running on their systems to make
>sure it is safe (shop owner)
>- They are looking for possible ways to abuse a system they do not own
>(would-be burglar)
>- They feel that they have a moral "duty" to use their skills and time
>for other's good (concerned citizen)
>- They have nothing else to do and think this is fun (vulnerability
>hobbyist)
>- They look for vulnerabilities because they are responsible for the
>vulnerable product (vendors)
>- They look for vulns with the express intention of publishing them and
>make themselves noticed (karma whores)
>
>On the other hand, people publish vulnerability information for the
>following reasons:
>
>- They publish vuln info to make themselves noticed (karma whores)
>- They publish vuln info because they have customers that pay (or
>otherwise produce revenue) for that service (watch dog)
>- They publish vuln info because they are responsible for the vulnerable
>code (vendors)
>- They feel that they have a moral "duty" to publish this information
>once they have it, since it may be a global risk (concerned citizen)
>- They have nothing else to do and think this is fun (why nots)
>
>Professional security staff and vulnerability seekers are a special case
>of the karma-whore/watch-dog combination. You find vulnerabilities in
>order to have them published and have your name metioned, bacause that
>is the basis for your revenue model. In turn, you have paying customers
>that profit by either having early access to the vuln info or premium
>access to patches and/or related security services.
>
>The whole DMCA vs. Full Disclosure issue must take into account the
>deeper reasons I have mentioned. Why do people search for vulns, and why
>do they publish them?
>
>Shop-owners:
>Shop-owners that look for vulns on the products they use already have
>the "right" attitude about this issue. They either contact vendors or
>create their own patches and submit them to the vendors. Shop-owners are
>not interested in early disclosure, since it might further expose their
>systems. Enforcing any kind of n-day disclosure or no-disclosure law
>would have no impact on their behavior. Except, of course, in the event
>that the vendor does not fix their product and the shop-owner has to
>create a patch to protect himself, and only them will he be willing do
>publicly disclose the vuln.
>
>Would-be Burglars:
>Burglars don't disclose vulnerabilities, just like in the real world
>they don't go around telling other burglars about this nice broken
>window they found. Burglars actively exploit vulns and will continue to
>do so, regardless of any law on the subject.
>
>Vulnerability Hobbyists:
>Hobbyists look for vulns because it's a challenge, and they would
>probably continue to do so. But any challenge must have a reward, and
>peer-recognition is part of that reward. If disclosure is banned, part
>of the reward is gone and hobbyists will be less inclined to seek vulns,
>directing their efforts to other things. Hobbyists thrive in recognition
>from the established security industry, so they are likely to be
>responsible in their disclosure procedure. Having an n-day policy would
>not change the way they act. Having a no-disclosure policy would
>probably lead them to diclose vulns in private forums, where it might
>easily leak to would-be burglars before it reaches the white-hat
>community and the affected system owners.
>
>Concerned Citizens:
>Concerned Citizens (aka the white hat community) would be severely
>affected by any restrictions of full disclosure. Most citizens already
>report vulns primarily to the vendor, in the hope that the vendor will
>solve the issue. If the vendor fails to comply, they look for a forum
>where to advise their peers about the problem, the failure to comply,
>and a possible fix. If such forums are outlawed, the citizens will still
>feel the moral need to search for flaws and to warn others. Remember
>that it is the concerned citizen attitude that is in the origin of every
>neighbourhood watch and popular militia group in the world. If the means
>to perform this "duty" in a responsible manner are banned, the citizens
>will be pressured into finding other ways of spreading this information.
>What is not volunteer work, white hat work, done for the global
>community, may turn into commercial activities, if the citizen is so
>pressured in his need to be "responsible" that he finds it in himself to
>affiliate with a professional security company. It may turn into an
>underground activity, if the citizen is forced to create an
>"underground", "illegal" list in order to publish what he has found. Or
>it may turn into an activity known to few, inside a members-only mailing
>list for a small group of like.minded people that the citizens
>personally know. Either way, any disclosure control law other than what
>is now current practice (vendor first, CERT if you want to, back off 30
>days, then all hell breaks loose) will limit the activity of concerned
>citizens and diminish global security.
>
>Karma Whores:
>The karma whores are in it for the glitz. They look for vulns in order
>to publish them, and publish them in order to get peer recognition.
>Vulns are like hunting trophies. They will eventually report to the
>vendor, if and only if the vendor will acknowledge what they report and
>give them appropriate credit when it finally discloses the vuln, along
>with the patch. If it is not like this, they will disclose the
>information independently. The damage done by karma whores can only be
>mitigated with better vendor responsiveness. And that is something that
>no law can achieve. If any law requires vendors to be notified ahead of
>time, the karma whores will still publish the vuln if the vendor does
>not respond in appropriate time. And the next time a vuln comes along in
>another product by the same vendor, karma whores are likely to disclose
>on day 0, "just to show them".
>Having a law will not change this. This is human nature at work. Today,
>karma whores disclose on the public lists, and everyone benefits from
>that. If <n-day is banned, or if disclosure is banned, the karma whores
>will move into the black hat lists, into private forums, into the irc
>networks. The effort required by the white hat community in order to
>track all disclosed vulnerabilities will be greatly increased.
>
>Vendors:
>Many vendors only disclose if they have to, if they are forced to
>disclosure by full or partial disclosure by third parties. Increasing
>the non-disclosure timeout period only gives vendors more time to react.
>But the time already given is more than enough. Any vulnerability that
>cannot be fixed in 30 days is not likely to be fixed in 45 or in 60
>days. And if the vendor contacts the vuln finder and asks for more time
>before disclosure, most finder will gladly comply.
>The problem is that many vendors don't respond when they are contacted.
>And no law is going to fix that. The vendors that only respond after the
>vuln is public, and after an exploit is in the wild, their customers are
>not going to benefit from a delayed non-disclosure period.
>Furthermore, the longer one waits after reporting to a vendor and before
>full disclosure, the more chances that a separate, independent
>researcher will fin the same vuln and disclose it into a black hat
>forum, making all customers vulnerable. Vendors will not benefit from a
>further delayed disclosure law. And customers will be hurt.
>
>Defense is very different from offense.
>Defense must cover all the fronts, offense needs to concern with only one.
>Black hats will continue to thrive if the public, general forums are
>outlawed. No blackhat ever needs all the information about all the
>products. He just needs one flaw in one product that he can exploit in
>order to get into wherever he wants. If disclosure is harmed, they won't
>suffer. The private forums and mailing lists and irc and icq and instant
>messenger black-hat clubs will continue to exist and information will
>continue to flow there. If anything, the law will help them, by moving
>what would otherwise be responsible disclosure by citizens and hobbyists
>into the blackhat zones.
>White hats, on the other hand, will be forced to roam the blackhat zones
>looking for information. They will need to pay much more attention to
>their IDS systems. They will need much more people in their departments
>to help with auditing and identifying potential attack attempts. If they
>do not know about the vulnerabilities, they cannot protect themselves.
>
>I do not wish to propose full 0-day disclosure as a rule. 30-days is
>appropriate. Even if it was 20 days, it would still be appropriate. But
>any effort to delay the timeout period, or to limit the amout of
>information that can be disclosed, is bad for the industry, bad for the
>users, bad for the system administrators.
>And, in fact, good for the burglars.
>
>JuliĆ£o Duartenn
>
>
>
>_______________________________________________
>Full-Disclosure - We believe in it.
>Full-Disclosure@lists.netsys.com
>http://lists.netsys.com/mailman/listinfo/full-disclosure
>

-----BEGIN PGP SIGNATURE-----
Version: Hush 2.1
Note: This signature can be verified at https://www.hushtools.com

wmYEARECACYFAj1KtHsfHGNob29zZS5hLnVzZXJuYW1lQGh1c2htYWlsLmNvbQAKCRDT
5JkCl0iMkE+IAKC/rlZjdmhFYGx+4S8w/jP+aqH9jQCeM3SDsuFeAEPL4cZB2Mf2Y6R7
Y3I=
=e8hQ
-----END PGP SIGNATURE-----


Communicate in total privacy.
Get your free encrypted email at https://www.hushmail.com/?l=2

Looking for a good deal on a domain name? http://www.hush.com/partners/offers.cgi?id=domainpeople
Re: Re: Re: it\'s all about timing [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I am afraid I still don't understand any of this. What is the actual point of this guideline? It looks to me like nothing more than a blueprint or template for future arbitration or litigation down the road.

What are the penalties now for not abiding by this guideline, or any other guideline that might be out there.

Pretend that your (as in this) guideline was already implemented. How on earth would you expect it to have stifled the release by both the individual in (or a part of) SnoSoft and ISS.

What exactly would have been done differently? Are you expecting either party to have been even more aware of some guideline or is this again, the benchmark by which the vendor will have recourse in the future? [read: litigation].

Based on an informal study I've done of about 350 researcher reports
from early 2002, approximately 50% of the vulnerabilities were
released without notifying the vendor, and about 20% of those reports
included full exploit code

Your informal study of 50% of 350 researcher reports. What exactly does that mean?

How many of those released were one-offs? 1 person never to be seen from again.
How many of them were "repeat offenders" 10 of the same people releasing the bulk of them?

In either case, how again, will the guideline apply or change that behaviour?

Your number 6 below:

"The Vendor MUST provide a facility for individuals or
organizations who are not Customers to report vulnerabilities"

This to me sounds like it is acceptable that there are going to be vulnerabilities. Continue cranking out shodware because we have a set of guidelines that people who stumble across them are expected to adhere to.

Why not draft a guideline for release of software onto internet. Security guideline (defaults of configs. etc.) and Quality Guidelines (vendor (a) is a known creator of crudware etc.). if you want to connect to the interne or peddle your internet connect warest, you the vendor must follow these guidlines. Penalise them them if they fail. Fine them real money if the repeat.

Don't try to coral the victim of the vendor with guidelines on what he is expected to do if he is burnt by a vendors product. Expect to find garbage software out there. When you do this is how you must report. You are duty bound to do that.

Never going to happen.I am afraid I still don't understand any of this. What is the actual point of this guideline? It looks to me like nothing more than a blueprint or template for future arbitration or litigation down the road.

What are the penalties now for not abiding by this guideline, or any other guideline that might be out there.

Pretend that your (as in this) guideline was already implemented. How on earth would you expect it to have stifled the release by both the individual in (or a part of) SnoSoft and ISS.

What exactly would have been done differently? Are you expecting either party to have been even more aware of some guideline or is this again, the benchmark by which the vendor will have recourse in the future? [read: litigation].

Based on an informal study I've done of about 350 researcher reports
from early 2002, approximately 50% of the vulnerabilities were
released without notifying the vendor, and about 20% of those reports
included full exploit code

Your informal study of 50% of 350 researcher reports. What exactly does that mean?

How many of those released were one-offs? 1 person never to be seen from again.
How many of them were "repeat offenders" 10 of the same people releasing the bulk of them?

In either case, how again, will the guideline apply or change that behaviour?

Your number 6 below:

"The Vendor MUST provide a facility for individuals or
organizations who are not Customers to report vulnerabilities"

This to me sounds like it is acceptable that there are going to be vulnerabilities. Continue cranking out shodware because we have a set of guidelines that people who stumble across them are expected to adhere to.

Why not draft a guideline for release of software onto internet. Security guideline (defaults of configs. etc.) and Quality Guidelines (vendor (a) is a known creator of crudware etc.). if you want to connect to the interne or peddle your internet connect warest, you the vendor must follow these guidlines. Penalise them them if they fail. Fine them real money if the repeat.

Don't try to coral the victim of the vendor with guidelines on what he is expected to do if he is burnt by a vendors product. Expect to find garbage software out there. When you do this is how you must report. You are duty bound to do that. Vebdor continue as you were, keep cranking out your crap.

The print looks bright blue to me.

On Fri, 2 Aug 2002 17:44:34 -0400 (EDT), full-disclosure@lists.netsys.com wrote:
>choose.a.username@hushmail.com said:
>
>>It is very unclear as to what it is that you are really after. Who are
>>these people "Vulnerability researchers", who's label is this?
>
>It's an RFPolicy-ism. Alternate terms are "reporter" (which covers
>"bug hunters" and "people from the press") and "notifier" (which is
>probably more accurate than "researcher," because the notifier might
>not be the person who discovered the issue). I'm leaning towards
>"notifier."
>
>>Are thes professionals now not adhereing to some suitable reporting
>>method where they do in fact alert the vendor in private, work with
>>that vendor in private, and then release the advisory? Is this not the
>>case already?
>
>Based on an informal study I've done of about 350 researcher reports
>from early 2002, approximately 50% of the vulnerabilities were
>released without notifying the vendor, and about 20% of those reports
>included full exploit code. (NOTE: the data is presently incomplete;
>but I hope to publish a full report in the future).
>
>But even in the case where the vendor is notified ahead of time, one
>needs only to look at the recent HP/SnoSoft situation to see that
>there are different opinions on how disclosure should happen. Going a
>little further back, the ISS/Apache situation also demonstrated a
>variety in how professionals handle vulnerability reporting. We may
>agree on the general notion of "give vendors some warning," but when
>you get down to the nitty gritty details - like *how much* warning,
>and how much effort the researcher should make, and how the vendors
>should respond - suddenly you realize that there's a lot of variety.
>
>You speak of "harnessing" vulnerability researchers. A number of
>people have said that the current RVDP draft asks too much of
>researchers, including Georgi Guninski and Rain Forest Puppy (and some
>vendors). That feedback will be taken into account in the next
>version.
>
>In the meantime, the current RVDP draft already has a number of
>suggestions for vendors:
>
>3.3.1 Vendor Responsibilities
>
> 1) The Vendor MUST make it as easy as possible for Reporters,
> Coordinators, Customers, and the Security Community to notify the
> Vendor of vulnerabilities.
>
>as well as:
>
> 3) The Vendor SHOULD ensure that its staff knows how to recognize a
> reported security issue and direct it to the Security Response
> Capability. This recommendation applies to staff who provide support
> online, over the telephone, in person, or through some other means by
> which reporters may interact with the Vendor.
>
>as well as:
>
> 6) The Vendor MUST provide a facility for individuals or
> organizations who are not Customers to report vulnerabilities. The
> Vendor SHOULD NOT require (1) an active technical support number, (2)
> telephone access that is not toll-free, or (3) user registration for
> a web site or other facility that would be used for reporting.
>
>
>If more vendors follow the recommendations in the current draft, it
>will be easier for people to report vulnerabilities to them, which I
>think is a good thing.
>
>
>>Or do you mean the one-off vulnerabilty report, the one that some
>>individiual stumbles upon and sends it off to the lists.
>
>If the one-off person knows about security-related mailing lists, then
>hopefully they'll know something of disclosure issues.
>
>>Are you trying to harness them? Do you think some standard setout on
>>what do do with the reporting is going to trickle down to the
>>individual man in the street and he's going to (a) know about it (b)
>>be bothered to follow the method if he did.
>
>If there is enough awareness of disclosure issues in the IT community,
>then hopefully this won't happen as much. However, as you say, there
>will always be people who won't follow the disclosure guidelines.
>
>You may be surprised to learn that the RVDP draft specifically tells
>vendors that they should be prepared for such a situation:
>
> 3.3.1 Vendor Responsibilities
>
> 7) The Vendor SHOULD recognize that inexperienced or malicious
> reporters may not use proper notification, and define its own
> procedures for handling such cases.
>
>
>I've mentioned at least 4 vendor requirements from the current draft,
>which would make the notification process easier for researchers.
>
>>Is there then a third set out there that needs this guidence everyone
>>is hollering about?
>
>I think so, and that's the people who are somewhere in between - maybe
>they're not professionals, but maybe they like to do research for fun,
>to analyze the software they use themselves, to build a resume,
>whatever (and before someone misinterprets what I just said, I
>personally don't think that there's anything wrong with doing research
>for resume-building). Sometimes, it seems that researchers start out
>by releasing advisories without notifying the vendor, then as they
>gain experience, they work with the vendor more and more. But I don't
>have any hard numbers to back that up. Indeed, the whole area of
>disclosure is woefully short of hard numbers.
>
>- Steve
>_______________________________________________
>Full-Disclosure - We believe in it.
>Full-Disclosure@lists.netsys.com
>http://lists.netsys.com/mailman/listinfo/full-disclosure
>

-----BEGIN PGP SIGNATURE-----
Version: Hush 2.1
Note: This signature can be verified at https://www.hushtools.com

wmYEARECACYFAj1LGmUfHGNob29zZS5hLnVzZXJuYW1lQGh1c2htYWlsLmNvbQAKCRDT
5JkCl0iMkPW/AJ4k/WgRMA8UF6OiMLG8MgACO6O3FACdFIqqRD6zgXL96iEVHMw1yhJD
7oI=
=m0a6
-----END PGP SIGNATURE-----


Communicate in total privacy.
Get your free encrypted email at https://www.hushmail.com/?l=2

Looking for a good deal on a domain name? http://www.hush.com/partners/offers.cgi?id=domainpeople
Re: Re: Re: it\'s all about timing [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>You speak of "harnessing" vulnerability researchers. A number of
>people have said that the current RVDP draft asks too much of
>researchers, including Georgi Guninski and Rain Forest Puppy (and some
>vendors). That feedback will be taken into account in the next

Harnessing in a "P2V" effort. Collecting the data from bug finders, bug hunters, neatly packaging it to suit the vendor, then releasing so that what the vendor ultimately has is a nice free outsourced quality control mechanism.

Standardised the process and vendors may as well do away with ever really coding cleanly. Why, because there is a reporting standard that everyone must adhere to which will very neatly cost them nothing, and ultimately achieve the same results.

Certainly some immense monatery value in such a favourable network down the road.
-----BEGIN PGP SIGNATURE-----
Version: Hush 2.1
Note: This signature can be verified at https://www.hushtools.com

wmYEARECACYFAj1LHdUfHGNob29zZS5hLnVzZXJuYW1lQGh1c2htYWlsLmNvbQAKCRDT
5JkCl0iMkDfJAJ9K3jwmnmns6WVz00azWhozxXiYZwCeJb4/L42/G2GpZxzorUQHCOoq
BVQ=
=tc5z
-----END PGP SIGNATURE-----


Communicate in total privacy.
Get your free encrypted email at https://www.hushmail.com/?l=2

Looking for a good deal on a domain name? http://www.hush.com/partners/offers.cgi?id=domainpeople
Re: Re: Re: it\'s all about timing [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I keep re-reading this and all I get out of it is, the vendor is doing the customer an enormous favor by allowing them to report a problem with their product.

Why does this stick in my throat?

"it will be easier for people to report vulnerabilities to them"

Is that so? Who is doing who the favor. Someone who spends hundereds of dollars or thousands of dollars and finds a problem in that vendors product. Or the vendor for allowing you, the customer, to buy their product? You should be honored by giving your hard earned money to me the vendor. Here take my product and tough shit if it doesn't work well.

How about fuck the vendor. Find a bug, post away 0-day? Or give me money back for the defective product you sold me plus compensation for the time and effort it took me to fix the problems your software did on my machine.


>In the meantime, the current RVDP draft already has a number of
>suggestions for vendors:
>
>3.3.1 Vendor Responsibilities
>
> 1) The Vendor MUST make it as easy as possible for Reporters,
> Coordinators, Customers, and the Security Community to notify the
> Vendor of vulnerabilities.
>
>as well as:
>
> 3) The Vendor SHOULD ensure that its staff knows how to recognize a
> reported security issue and direct it to the Security Response
> Capability. This recommendation applies to staff who provide support
> online, over the telephone, in person, or through some other means by
> which reporters may interact with the Vendor.
>
>as well as:
>
> 6) The Vendor MUST provide a facility for individuals or
> organizations who are not Customers to report vulnerabilities. The
> Vendor SHOULD NOT require (1) an active technical support number, (2)
> telephone access that is not toll-free, or (3) user registration for
> a web site or other facility that would be used for reporting.
>
>
>If more vendors follow the recommendations in the current draft, it
>will be easier for people to report vulnerabilities to them, which I
>think is a good thing.
>
>
>>Or do you mean the one-off vulnerabilty report, the one that some
>>individiual stumbles upon and sends it off to the lists.
>
>If the one-off person knows about security-related mailing lists, then
>hopefully they'll know something of disclosure issues.
>
>>Are you trying to harness them? Do you think some standard setout on
>>what do do with the reporting is going to trickle down to the
>>individual man in the street and he's going to (a) know about it (b)
>>be bothered to follow the method if he did.
>
>If there is enough awareness of disclosure issues in the IT community,
>then hopefully this won't happen as much. However, as you say, there
>will always be people who won't follow the disclosure guidelines.
>
>You may be surprised to learn that the RVDP draft specifically tells
>vendors that they should be prepared for such a situation:
>
> 3.3.1 Vendor Responsibilities
>
> 7) The Vendor SHOULD recognize that inexperienced or malicious
> reporters may not use proper notification, and define its own
> procedures for handling such cases.
>
>
>I've mentioned at least 4 vendor requirements from the current draft,
>which would make the notification process easier for researchers.
>
>>Is there then a third set out there that needs this guidence everyone
>>is hollering about?
>
>I think so, and that's the people who are somewhere in between - maybe
>they're not professionals, but maybe they like to do research for fun,
>to analyze the software they use themselves, to build a resume,
>whatever (and before someone misinterprets what I just said, I
>personally don't think that there's anything wrong with doing research
>for resume-building). Sometimes, it seems that researchers start out
>by releasing advisories without notifying the vendor, then as they
>gain experience, they work with the vendor more and more. But I don't
>have any hard numbers to back that up. Indeed, the whole area of
>disclosure is woefully short of hard numbers.
>
>- Steve
>_______________________________________________
>Full-Disclosure - We believe in it.
>Full-Disclosure@lists.netsys.com
>http://lists.netsys.com/mailman/listinfo/full-disclosure
>

-----BEGIN PGP SIGNATURE-----
Version: Hush 2.1
Note: This signature can be verified at https://www.hushtools.com

wmYEARECACYFAj1LJFUfHGNob29zZS5hLnVzZXJuYW1lQGh1c2htYWlsLmNvbQAKCRDT
5JkCl0iMkB3kAKCoupjU2QzSO75H6CKBD4l/pMwQ2wCgsanIKDniM8Xr+GII5T7VWdS8
4i8=
=esAQ
-----END PGP SIGNATURE-----


Communicate in total privacy.
Get your free encrypted email at https://www.hushmail.com/?l=2

Looking for a good deal on a domain name? http://www.hush.com/partners/offers.cgi?id=domainpeople
Re: Re: Re: it\'s all about timing [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>This to me sounds like it is acceptable that there are going to be
>>vulnerabilities. Continue cranking out shodware because we have a set
>>of guidelines that people who stumble across them are expected to
>>adhere to.
>
>Vulnerabilities will happen, even in the best of circumstances, as
>long as new types of vulnerabilities are discovered. If there are 20
>individuals who decide to audit a package for a new type of
>vulnerability, but the vendor only has 5 developers, then it seems
>like there's a good chance that someone other than the vendor will
>discover the issue. Then you've got "interaction" vulnerabilities,
>which I loosely define as when a vulnerability occurs in the way that
>two products interact with each other. Developers can't always
>predict how their product will be used, or how it will interact with
>other products, so interaction-based vulnerabilities may be around in
>one form or another.

This is not my problem. You want to make something and sell it to me,
make sure it works as advertised. Your problems are "interaction" with
other products, and your lack of developers, not mine.

Give me one good reason why I should be concerned with how you make your
product and your inabilities to ensure that what I paid for (probably as
a result of your snake oil marketing)work.

I don't understand your stance that my giving you money in exchange for your
goods somehow gives you license to not provide me with my money's worth. The commerical world simply doesn't work like that. Time to change the fantasy software world. You've been riding on the "that's software" coat tails too long.


>
>Given the likelihood of vulnerabilities in a "perfect" world, it seems
>reasonable that the vendor should be prepared to respond to incoming
>reports.
>
>>Why not draft a guideline for release of software onto
>>internet. Security guideline (defaults of configs. etc.) and Quality
>>Guidelines (vendor (a) is a known creator of crudware etc.). if you
>>want to connect to the interne or peddle your internet connect warest,
>>you the vendor must follow these guidlines. Penalise them them if they
>>fail. Fine them real money if the repeat.
>
>This is a very interesting proposal if I understand what you're
>saying, but it's outside the scope of a disclosure process document.

I think it goes hand-in-hand. You're drafting a guidline for people who are responding or reacting to something. What is it that they are responding or
reactiving to? Your guidline is the chaper two or step number 2. Where is
Chapter one. People don't find and report vulnerabilities out of thin air. it is a result of something. That something is either buying or installing a vendors product. There must be a step one or chapter one. The vendors guidlines. Against which your reporting guidline is the process as a result of buying or installing the vendors software.

Chapter One. Vendor Guidline: vendor promises to ensure his product works
Chaper Two. Customer who finds it doesn't work, will do this.

Simple cause and reaction. You must have a guidline for the vendor first and then a guidline for the customer second. Is there is no guidline for the vendor now and that is why your guidline simply will not wash.

>
>I can't think of any document that specific says "use
>secure-by-default" (and defines what that means), "avoid buffer
>overflows," "conduct third-party evaluation of product design," "make
>security-based patching and configuration easy" (and try to define
>*that* :-), etc. Such a document might be useful for less-technical
>customers to ask their vendors to make more secure products. I
>suspect that many customers want security, but they don't know how to
>ask for it.
>
>- Steve
>_______________________________________________
>Full-Disclosure - We believe in it.
>Full-Disclosure@lists.netsys.com
>http://lists.netsys.com/mailman/listinfo/full-disclosure
>

-----BEGIN PGP SIGNATURE-----
Version: Hush 2.1
Note: This signature can be verified at https://www.hushtools.com

wmYEARECACYFAj1RZ5IfHGNob29zZS5hLnVzZXJuYW1lQGh1c2htYWlsLmNvbQAKCRDT
5JkCl0iMkCyhAJ9IZQYzYKhDkQXCPpGXi3BXJpDBdQCgqLIFUfRr7wHDDXCdTkHrmFYL
KX4=
=vXD2
-----END PGP SIGNATURE-----


Communicate in total privacy.
Get your free encrypted email at https://www.hushmail.com/?l=2

Looking for a good deal on a domain name? http://www.hush.com/partners/offers.cgi?id=domainpeople
Re: Re: Re: it\'s all about timing [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I get the impression that some government type may have whispered in your ear

"go out into the IT community and get a 'peoples' consensus on a guidline that we expect to put into legislation in the near future". This way it is the 'peoples' guidline and not the governments.

All this continual talk about it does nothing other than give it legitimacy and a footing when in fact had the status quo been maitained, nobody would be the wiser. In other words someone has come up with the brainwave to do something about nothing.

On Mon, 5 Aug 2002 21:51:50 -0400 (EDT), full-disclosure@lists.netsys.com wrote:
>choose.a.username@hushmail.com said:
>
>>What are the penalties now for not abiding by this guideline, or any
>>other guideline that might be out there.
>
>We explicitly stayed away from defining what the penalties are.
>That's outside the scope of the recommendations - the "marketplace"
>may decide, or perhaps, the legal community may decide. If there are
>no guidelines at all, then perhaps "the government" will decide (which
>obviously has its own issues, in an international community such as
>information security.)
>
>>Pretend that your (as in this) guideline was already implemented. How
>>on earth would you expect it to have stifled the release by both the
>>individual in (or a part of) SnoSoft and ISS.
>
>It at least establishes a point of discussion. Whether you agree with
>the particular points of the draft or not, they can be compared to the
>facts (or apparent facts) of the situation.
>
>For the ISS/Apache issue, it seems that nobody disputes that ISS gave
>Apache less than 7 days to respond to the initial report, before they
>published. This is not consistent with the spirit of the disclosure
>draft (I just took a look at it, and while it requires the vendor to
>respond within 7 days, it doesn't have a complementary suggestion that
>the reporter should give 7 days to the vendor! whoops). In the
>ISS/Apache case, we have the further complication that multiple
>vendors were involved (a difficult issue that is not addressed by the
>current draft, except in its recommendations for involving
>coordinators). Without community-defined guidelines, there are no
>clear boundaries to say whether ISS did things "reasonably" or not.
>
>The SnoSoft/HP issue is more complicated and not cleanly addressed by
>the disclosure draft, which does not cover accidental or unauthorized
>releases, and is not comprehensive on the role of third party
>coordinators. I think it demonstrates some of the complexity in
>vulnerability disclosure. Some people have argued that this means
>that there shouldn't be *any* guidelines, but I believe that we should
>try to be as detailed as possible in the guidelines to reduce
>confusion, provide flexibility where it is needed, and do what is
>possible to avoid regulations that may come from outside the IT
>community.
>
>- Steve
>_______________________________________________
>Full-Disclosure - We believe in it.
>Full-Disclosure@lists.netsys.com
>http://lists.netsys.com/mailman/listinfo/full-disclosure
>

- -----BEGIN PGP SIGNATURE-----
Version: Hush 2.1
Note: This signature can be verified at https://www.hushtools.com

wmYEARECACYFAj1RaaofHGNob29zZS5hLnVzZXJuYW1lQGh1c2htYWlsLmNvbQAKCRDT
5JkCl0iMkP31AJsHv2J3QICwlKsvoCiK+I8STNAedACgtn0/KLwugGTn/ldKdFLGhWBj
0dg=
=0E/o
- -----END PGP SIGNATURE-----


Communicate in total privacy.
Get your free encrypted email at https://www.hushmail.com/?l=2

Looking for a good deal on a domain name? http://www.hush.com/partners/offers.cgi?id=domainpeople

-----BEGIN PGP SIGNATURE-----
Version: Hush 2.1
Note: This signature can be verified at https://www.hushtools.com

wmYEARECACYFAj1RabofHGNob29zZS5hLnVzZXJuYW1lQGh1c2htYWlsLmNvbQAKCRDT
5JkCl0iMkOlEAKCS2Yvrfwy0GPLnvwhiedke61qCzwCgjUcQqPUeRjQGTDvZt1hNjjGp
8kI=
=Vlls
-----END PGP SIGNATURE-----


Communicate in total privacy.
Get your free encrypted email at https://www.hushmail.com/?l=2

Looking for a good deal on a domain name? http://www.hush.com/partners/offers.cgi?id=domainpeople
Re: Re: Re: it\'s all about timing [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On Mon, 5 Aug 2002 21:16:53 -0400 (EDT), full-disclosure@lists.netsys.com wrote:
>choose.a.username@hushmail.com said:
>
>>Who is doing who the favor. Someone who spends hundereds of dollars or
>>thousands of dollars and finds a problem in that vendors product. Or
>>the vendor for allowing you, the customer, to buy their product? You
>>should be honored by giving your hard earned money to me the
>>vendor. Here take my product and tough shit if it doesn't work well.
>>
>>How about fuck the vendor. Find a bug, post away 0-day? Or give me
>>money back for the defective product you sold me plus compensation for
>>the time and effort it took me to fix the problems your software did
>>on my machine.

The best person to answer your question is you. You're the author of these
guidlines. You'll need to address the motivations of everyone involved. As difficult as bottleing wind which is why the guidlines simply cannot work.

You could include:

a) one man show software developer in his musty basement, makes free app. goes out and spams the hell out of everyone claiming it is the greatest invention.

Irritated by his behaviour, someone may poke a hole in his product and 0-day it

b) one man show software developer in his musty basement, makes free app. releases by word of mouth or "viral" marketing.

his behaviour may not irritate someone and, even if a hole is poked, he is informed quietly

c) massive commercial developer, continually churning out product that is continually flawed, sitting on billions of dollars cash while the owner runs around the world with an unsettling grin and walking into cream pies whereever he goes.

This behavior might irritate someone to and motivate them to poke a hole in their product and slam it wherever possibl and whenever possible

d) massive commerical developer continually churning out product that is consistantly not flawed, sitting on billions of dollars cash, plowing it into research and delopement and quality control. Known for caring about their product and taking pride in their product and listening to their customers. In other words caring.

This behaviour might not irritate someone and even if a hole is poked in their product, they are informed quietly.

The list could be endless. To each his own and once again, why your guidliness simple cannot fit.




>
>I'm just curious, do people on this list think that freeware vendors
>should be treated differently than this? Do you think they should be
>given more (or less) time to address the issues? How about commercial
>vendors whose products are open source? How much does a vendor's past
>performance (or the perception of past performance) come into play?
>
>- Steve
>_______________________________________________
>Full-Disclosure - We believe in it.
>Full-Disclosure@lists.netsys.com
>http://lists.netsys.com/mailman/listinfo/full-disclosure
>

-----BEGIN PGP SIGNATURE-----
Version: Hush 2.1
Note: This signature can be verified at https://www.hushtools.com

wmYEARECACYFAj1RbEsfHGNob29zZS5hLnVzZXJuYW1lQGh1c2htYWlsLmNvbQAKCRDT
5JkCl0iMkKSVAKCmopCKn6swc21wUIcbELylqNUe2QCfVFNLHTQ99CDI0fgZsbGw+nDA
f+A=
=WcIJ
-----END PGP SIGNATURE-----


Communicate in total privacy.
Get your free encrypted email at https://www.hushmail.com/?l=2

Looking for a good deal on a domain name? http://www.hush.com/partners/offers.cgi?id=domainpeople
Re: Re: Re: it\'s all about timing [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This all after the fact. These names and labels are assigned once the deed is done.

It cannot be like that.

More importantly you need to define what a "vulnerabililty" is otherwise no matter what your guidline says or suggests, without that definition we could be talking magic tricks.

>
>The current short definition of "reporter/notifier" is:
>
> A [Reporter/Notifier] is the individual or organization that
> informs (or attempts to inform) the Vendor of the vulnerability.
> Note that the [Reporter/Notifier] may not have been the initial
> discoverer of the problem.
>
>The current draft doesn't include any definition of "security
>advisory," so that will need to be addressed.
>
>Thanks,
>- Steve
>


-----BEGIN PGP SIGNATURE-----
Version: Hush 2.1
Note: This signature can be verified at https://www.hushtools.com

wmYEARECACYFAj1RtIgfHGNob29zZS5hLnVzZXJuYW1lQGh1c2htYWlsLmNvbQAKCRDT
5JkCl0iMkNH5AJ9V9HWiv+nN5rNfeQKsA+/fkUDoAwCeK5Si4JST6JiXtvI6Pn7NyF8I
Esc=
=EoNv
-----END PGP SIGNATURE-----


Communicate in total privacy.
Get your free encrypted email at https://www.hushmail.com/?l=2

Looking for a good deal on a domain name? http://www.hush.com/partners/offers.cgi?id=domainpeople