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>] [day] [month] [year] [list]
Message-ID: <15533237421C6E4296CC33A2090B224A11C03C@UTDEVS02.campus.ad.utdallas.edu>
From: pauls at utdallas.edu (Schmehl, Paul L)
Subject: No Subject (re: openssh exploit code?)

> -----Original Message-----
> From: mitch_hurrison@...lip.com [mailto:mitch_hurrison@...lip.com] 
> Sent: Tuesday, October 21, 2003 3:05 PM
> To: full-disclosure@...ts.netsys.com
> Subject: [Full-Disclosure] No Subject (re: openssh exploit code?)
> 
> Then this means that, if you as an admin cannot rely on the 
> proper designated outlets for security alerts. You are forced 
> to seek guidance in the public realm? That's an awfully big 
> dependence on people who are in no way employed by your organisation.
> 
Who decides what a "properly designated outlet for security alerts" is?
I can assure you that in my case, I make that decision, and I suffer the
consequences if it's a wrong decision.  Personally, I'll take my
information in any way I can get it, and I'll decide if it's relevant or
not, if it's critical or not, and what my recommendations should be WRT
patching schedules.  I would *assume* that other organizations would
function in a similar manner.

Besides, in the public realm I can make much better judgments about
someone's competence because I can read what they write and verify its
veracity or logic myself.  For example, (not tooting his horn, but...)
Michal Zalewski is someone whose posts I pay very close attention to.
Because he has proven repeatedly that he knows what he's talking about.
If he weren't posting in public lists, then I couldn't make that
judgment.  So I would be less inclined to believe him if he suddenly
announced that a certain vulnerability was exploitable and people had
better get to patching, but he wasn't going to explain why that was so.

This may come as a shock to you, but no one can be an expert in
everything.  To be successful you have to learn to rely on people who
prove themselves in their field.  Very few IT professionals that I know
are CS majors, because frankly they tend to be very poor performers when
it comes to customer service skills.  I'm generalizing, of course, and
there are counter examples available.  When IT professionals need to
understand the level of risk of a particular vulnerability, *one* of the
things they may do is consult someone who understands code intimately.
By the same token, when a CS major needs to buy something they only
understand in a superficial way, I would expect most of them to consult
someone who understands the issue more intimately.  

I don't suppose you are intimately familiar with petroleum refining and
the consequences of poor cracking techniques, but I'll bet you still buy
gas from dealers that you trust to know that and do it right.  That's
how the world goes round.
> 
> How would you feel about returning to the old, pre full 
> disclosure, state of affairs. Where admins of government 
> networks, university networks and any other admin that could 
> prove they had a valid use for the information, were privvy 
> to private security bulletins. Allowing them to internally 
> disclose the details needed for the confirmation of 
> exploitability of a certain issue. Without hanging out their 
> dirty laundry for all the world to see?

Well, before you came along arguing the opposite, I would have thought
my involvement in this list would define that pretty clearly.  I'm
opposed to the withholding of information of any kind.  Only tyrants
benefit from the withholding of information.  And only the free flow of
information can defeat tyrants.

> Personally I'd love 
> to see a return to the days of old. A public exchange of 
> exploits and the methodologies involved is an illogical and 
> irresponsible way of going about things. By atleast 
> attempting to keep something that can be considered weaponry 
> in a time of network dependance, from a largescale audience 
> you eliminate alot of noise, and eventually eliminate the 
> untalented people out there who are still writing papers on 
> formatstring abuse and posting lnx86.S execve opcodes. 
> 
> I think both the administrator community as the true hacker 
> community is willing to go back to this state of affairs.

I disagree.  I think you have a skewed view of the world today.
> 
> So yeah, there should be no need for the public disclosure of 
> exploits. And if there is a valid need for exploit 
> confirmation this disclosure should occur in a closed forum. 
> That way hackers can get back to hacking, and admins can get 
> back to adminning.
> 
> Full disclosure is an excersise in futility.
> 
Obviously I disagree.  But let's assume for the moment that your
argument is completely correct.  What do you do about vendors that don't
patch or don't patch in a timely manner?  (I don't mean you personally,
because I would assume from your previous responses that you would do
nothing and not care if anything was done.)  If full disclosure were to
cease to exist tomorrow, do you think that the state of vulnerabilities
in software would improve?  Or degrade?  Do you think vendors would be
more or less responsive to reports of problems?

Paul Schmehl (pauls@...allas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu/~pauls/ 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ