lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20020820153657.GH57585@darkuncle.net>
From: lists_full-disclosure at darkuncle.net (lists_full-disclosure@...kuncle.net)
Subject: Shiver me timbers.

On Tue, Aug 20, 2002 at 12:38:04AM +0200, peter@...k-connect.com said:
> I am wondering....
> 
> Besides the "I am bad and you cannot stop me" threads, the main issue
> (of course) seems to be whether to publish exploits/vulnerabilities
> found. Although one might want to hold one's own moral judgement against
> others, such appears mostly futile. Thus the personal moral evaluation
> gets all the more relevant. One aspect I've found missing so far is the
> distinction between commercial and open/contributed software.

A critical distinction indeed. More attention needs to be paid to the fact
that all situations are not the same, and hacking targets (for the
blackhats), as well as vulnerability releases, need to be tailored to the
situation. I feel no compunction to send word to Microsoft, for example, of
any bugs I find in MSIE or any of their other products. For one thing, any
such bug would likely be almost exactly the same as a dozen other similar
bugs already disclosed and patched, individually. Also, MS has billions of
dollars to spend on hiring good coders, and enforcing good programming
practices. They obviously do not consider this to be a priority.

Now, if I found a bug in, say, Apache or OpenSSH, I'd notify the developers
immediately, both because I use these products heavily, and because they're
open source projects that I wish to support. While more high-profile projects
(like Linux or Apache) may have some level of corporate funding, they are
still mostly volunteer efforts. There is no multi-billion dollar R&D budget
as exists at MSFT, Sun, etc. Thus, entirely different situations, calling for
entirely different responses on my part (IMO).

> I also fail to see the distinct link between (not)publish and morals.
> Would every must-publish-hat (:>) willingly help that notorious spammer?
> Or would every must-not-publish-hat deny assistance to the makers of his
> favorite OS or web-stat tool? I would like to be surprised by any
> consistent moral motivation by either faction. I'm afraid that moral
> judgement cannot be made by rules of thumb. Then, I'm also afraid
> there's always going to be a bit of sacrifice in order to achieve
> "morals". But hack, none of that's any good for sake of argument.

I agree with you here - while my personal ethical code remains fairly
constant, each situation must, IMO, be evaluated on its own merits.

> So, indeed, argument is a decent thing. And as far as moral obligations
> go, there's just the arguments that can be spelled out. So that they can
> be a mirror to anyone that is compelled to reflect. An RFC to simply
> formalize the required procedures for any vulnerability found seems to
> me like a grave over simplification.

Indeed - I think the original rfpolicy was a good idea, but any such policy
or RFC can be, at best, only a starting point. From that starting point, one
can then begin to decide what actions are warranted in each specific
situation.

-- 
-= Scott Francis || darkuncle (at) darkuncle (dot) net =-
  GPG key CB33CCA7 has been revoked; I am now 5537F527
        illum oportet crescere me autem minui
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20020820/47ba5920/attachment.bin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ