Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Ka (ka_at_khidr.net)
Date: Mon Aug 19 2002 - 15:23:14 CDT
-----BEGIN PGP SIGNED MESSAGE-----
you misunderstood my intention. I was simply expressing
my point of view, I'm not intending to tell anybody,
what to do or what not to do.
I'm appreciating this list very much, in fact after recognizing
that for example bugtraq is withholding critical information
often for weeks, I was looking forward to such a list (as is
formulated in its goal and yet to be realized).
And I was answering to one of your posts, because I saw from
your statements, that you are not buying a ready-made
philosophy but expressing your own point of view in clear words.
Having said that (sorry for the flattery .o) I just want to explain
my point: what about the colleagues (like me), who are neither
experienced in exploit-writing nor unexperienced in programming
and willing to learn? And of course learning on an actual problem,
trying to verify and fix the imminent software flaw before exploits
are im wide use. That's more to my taste, than just waiting for the
rpm from the distributor and then simply installing it (and having
to install it immediatedly, because so many weeks have allready
passed after the first detection).
At Montag, 19. August 2002 19:57 aliverxexil.com wrote:
> [...] What I'm addressing is the flawed idea that everybody has to share
> this work if it applies to some vendor's product, no matter what.
> [...] doing free research for a greedy company still sucks,
Certainly. One of the reasons I quit my last job.
> [...] and categorically
> applying some "ethical" standard is a sure sign of lack of the ability to
> think for yourself.
> Again we are talking about security vulnerabilities,
> not just general "information" as you put it.
Not agreeing on that one. Security concerns have
become general. The whole net depends more and more on
it (negatively or positively).
> Again, you are over-generalizing and being way too ambiguous. What kind of
> bug? A security vulnerability is a specific type of bug with specific types
> of implications often greater than a simple "program X won't function in
> condition Y."
I don't play this black-n-white game, sounds too much of 007-movies to me.
A bug in a compiler or OS can be far more costly than a defaced website.
The only difference I see in the security sector is that there is the _intention_
of the intruder, an intention which is far too easily named "malicious"
for my taste. "Malicious" has nothing to do with hacking or not hacking,
it's a different dimension -- one can be malicious within the letters of the
law (and without). Yet - a good tester will allways have the "malicious"
intend to bring the developed system down. The IBM black-team was feared
for that (long ago .o)
> I for one am not suggesting that the "exchange" of know-how among hackers
> be hindered.
> I'm suggesting that a person in a researcher role has the
> right to exercise his own judgment before he decides what to do with his
I agree. But a lot of people might not.
This is against the basis of our so called "modern"
society, which is in fact anti-individual in large areas.
> I'm also saying that there are many conditions where that
> individual might be morally justified by withholding a bug with security
> implications from the original vendor. Lastly, I'm suggesting that
> one-size-fits-all "ethics" from whitehats publishing silly "RFC" documents
> on what I should do are a vile idea.
Sure, I never understood you otherwise.
Ethics stink, may they come from society or anti-society.
But at least this RFC was a try to make the decision processes
public and transparent. After all it's a "request for comments".
That we don't need more RFCs but more individuals is not the
fault of the authors of the RFC. That _some_ of the "disturbing"
postings to this list showed the resp. hacker's individuality
was also not allways recognized.
This email has become quite personal (and OT to this list).
Nevertheless I post it to the list in the hope, that my
standpoint might help communication between black-n-white.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----
Full-Disclosure - We believe in it.