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 for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 30 Jun 2005 15:40:27 -0400 (EDT)
From: "J. Oquendo" <sil@...iltrated.net>
To: bugtraq@...urityfocus.com
Cc: full-disclosure@...ts.grok.org.uk,
	Skip Carter <skip@...geta.com>, devnull@...ents.Montreal.QC.CA
Subject: RE: Published exploit codes foo foo foo




On Thu, 30 Jun 2005, Skip Carter wrote:

> I think its a question of what the role of the 'security administrator' is within
> the enterprise.  If their job is primarily threat evaluation and appropriate
> patching/updating in response, then I agree that the publication of an exploit
> is not very helpful.  If, however, the job is firewall/IDS management or
> incident investigation, then having access to actual exploit code is
> extremely valuable to have.
>
>
> --
>  Dr. Everett (Skip) Carter           Phone: 831-641-0645 FAX:  831-641-0647
>  Taygeta Network Security Services   email: skip@...geta.net
>  1340 Munras Ave., Suite 314         WWW: http://www.taygeta.net/
>  Monterey, CA. 93940

Personally I think the whole "security administrator/engineer" has become
nothing more than bloat and FUDWORK. Personally if I was hiring someone
under the guise of "security *ANYTHING*" they'd better have a clue and not
be segragated to simply compiling and running exploits. They'd better know
their IDS', firewalls, networking and systems.

One of the problems with defining who's on first, what's on second (and
I'm referring to the "if however, the job is firewall/IDS management"
quote) is having no one to pull the trigger at (meaning pink slips) for
someone's irresponsibility. Some of these corporations need to get their
act together when directing job duties and descriptions. Instead of hiring
someone who claims to have a clue and has refreshed their memory before an
interview, they should start putting them through the test before hiring
them. Throw someone on some segmented network with flaws and have the
pending employee one securely configure it then pentest it. If there is an
in house tiger team, they could then go about checking on whether or not
the pending employee has a clue... Enough ranting about this...

On Thu, 30 Jun 2005 devnull@...ents.Montreal.QC.CA wrote:

> Well, I'm not an end-user organization, but as an end user[%], the
> major benefit I see to full disclosure is that it appears to be close
> to the only thing that has any real success at getting vendors to fix
> bugs.  (In general.  There certainly are vendors that stay on top of
> things without needing the prod of public exploit disclosure.  But they
> are notable by their rarity.)

Funny these arguments over full disclosure. Vendors will be vendors.
Employees at these vendors (and I mean the bigger boys like MS and
such) normally have nothing ventured, nothing gained so coding is
probably not double checked. Thinking twice about this, I wonder how
many of these bigger boys' products that have had vulnerabilities
discovered, I wonder how many of that coding came from outsourced vendors.
Meaning... "Well we thought we would save money by having
_INSERT_COUNTRY_HERE code for us." Would be interesting to see where the
majority of sloppy coders, whose projects have been exploited, come from.

On Thu, 30 Jun 2005, Jason Coombs wrote:

> Shut 'em all down. They're a big waste of time and money, and they only
> help the bad guys on all sides of the bellum omnium contra omnes. The
> good guys get what they need by reading glossy print magazines.
>
> Regards,
>
> Jason Coombs
> jasonc@...ence.org

I'd like to know what magazines you're reading. Hopefully by your address
you aren't stuck on a Star Trek like planet where an empire is defined
by who has the biggest guns to fry anyone who opposes that empire. It's a
dual edged sword when you think about it. If everyone was an angel there
would be no need for law enforcement would there. There would be no need
for creating scenarios. Now take your ideal little planet and throw in
Murphy's Law, what a scene it would be to see those in the empire
scrambling like chickens with their heads cut off when something obscure
does happen.

...

Full disclosure has become just like some of these lists... Overrated.
Sure there is a need to publish exploits, sure there is a need to withhold
them. Just like someone elses post about guns and cars, what should be
done? Legislation? Sure by whom? That would be an altogether other
humorous vision to see countries duke it out via the WTO because Company X
outsourced to Company Y and Company Y caused portion of Company X's
product to become unstable or insecure or something along those lines.
Pray for the best expect the worst.... Common rule of thumb.


On Thu, 30 Jun 2005, James Wicks wrote:

> As far as software vendors go, if their products have an issue, it
> should be addressed.  If they cannot (or will not) address it, then I
> get a new vendor.  I cannot have business-critical applications
> operating unpatched because the vendor does not want to address it.
> My business assets are vulnerable, and that is not acceptable.  If
> Symantec personnel have to stay up 48 hours in a row to fix a flaw
> that can be exploited, I am ok with that.  That is what we pay them
> thousands of dollars a year to do.  As long as the software company is
> given the opportunity to address the exploit before the release of the
> exploit code, there is really no real issue.

Who dictates whether or not someone publishing code give a vendor
an opportunity to provide a patch. What makes you think this is practical
most of the times. Think about someone _NOT_ publishing a code...
No one would know therefore vendors wouldn't rush to get a patch, they
wouldn't have to no one would know... On the other hand if no exploit
was released people seem to assume there would be no break ins.
One study I haven't seen done is, the exploit used to break into systems.
There to date not to my knowledge has been an assessment of what
exploits are dominant on systems that have been compromised.

We all see coding and many of them are trivial at best considering
there are many who wouldn't even know what to do with an "unpatched"
system smacking them in the face. As for "I can get a new vendor", I
would love to pull everyone's card on that absurd comment. Go right
ahead and either pay an admin (security admin, sys admin, whomever)
about $5,000.00 to get it fixed while you wait for a lazy vendor to get
a patch, or go right ahead and replace your entire infrastructure which
would likely cost you an arm and a leg.

Whatever. Security has become boring.


=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
GPG Key ID 0x97B43D89
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x97B43D89

To conquer the enemy without resorting to war is the most
desirable.  The highest form of generalship is to conquer
the enemy by strategy." - Sun Tzu
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ