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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
From: mitch_hurrison at ziplip.com (mitch_hurrison@...lip.com)
Subject: No Subject (re: openssh exploit code?)

Hi Paul,

> Admins and management base decisions on those differences.  Now
> let's look at the case at hand, which you characterize as
> "devastating".

Yes, lets. 

> Note the words "may......cause a denial-of-service condition"  and
> "may.....execute arbitrary code".  It is those vagaries that folks
> who run large networks need clarified.  If something *may* cause a
> problem, the correct preventative action could be entirely
> different from something that *will* cause a problem.  Decisions
> about whether or not to take critical services offline **right
> now** for patching are *frequently* based on those nuances in
> wording.

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.

> First of all, I object to your characterization of an entire
> organization based on the *alleged* actions of one individual.
>  And I would ask you to ask yourself, *why* do you feel the need
> to make such statements?

Because I'm a condescending jerk, remember?

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? 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. Most
of us are confident enough in our own research abilities that
we won't suffer from a public dry-out of cookbook bug reports
and exploits. It's only those who can't think for themselfs
and be creative in their use of a debugger who get worried
at this notion. Because at the end of the day, that's all 
exploit dev is. Creative debugging. 

That's why I'm so opposed to even linking to pre-fab papers
on exploiting any "technique" of sorts. There is no such thing
as a set technique. Exploit dev is based on everyday real life
skills that any CS major should be familiar with. There is no
magic secret. And that's why so many people doing real exploit
dev refuse to recognise the info-sec world as a legitimate 
business. You're using skills that cover an innate understanding
of the architecture in question to debug a certain bug in a software
implementation using that architecture. You're just looking
at the debugging process from a different viewpoint.

Now this includes understanding how a certain malloc implementation
functions, or determining how the heap is used in a certain
application. These are all skills any competent CS professional
and/or enthusiast should be, or atleast could be at home with. 
Now having a sparkle of creativity or original thought in you, 
that's a different story.  

But I'm digressing..

Sure there will be the occasional leak in a non-disclosure enviroment, sure there will be the occasional hack. But isn't
"occasional" preferable to a state in which every dimwit in the 
world is armed to the teeth with an arsenal of exploits? By taking
away the spoonfeeding of exploits and exploit research you dissolve 
a large part of the problem. It's not like it would be some great unjustice, you're just forcing people to think for themselfs again.
Hopefully leading to a "you want the exploit? well go ahead and write
it"-mentality.

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.

With regards,
Mitch




Powered by blists - more mailing lists