bugtraq - Re: Openssl proof of concept code?

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] [thread-next>] [day] [month] [year] [list]

Date: Thu, 08 Jan 2004 19:44:23 -0300
From: Ivan Arce <ivan.arce@...est.com>
To: "Lachniet, Mark" <mlachniet@...uoianet.com>
Cc: bugtraq <bugtraq@...urityfocus.com>, pen-test@...urityfocus.com
Subject: Re: Openssl proof of concept code?

Lachniet, Mark wrote:

> ...
> 
> Is anyone aware of a reasonable way for an analyst to definitively
> demonstrate if the vulnerabilities exist in a particular product?  Since
> some of the bugs deal with bad client certificates, some might be as
> easy as getting a copy of a "bad" client certificate and connecting to
> the server using a program such as stunnel, but I have yet to see
> anything about this.  Alternately, has anyone written a good program to
> remotely identify what SSL codebase is in use, other than looking for it
> in HTTP server headers?  Nessus' ssltest.nasl can allegedly distinguish
> between a openssl and MS CryptoAPI or Novell, but this isn't really
> enough in my opinion.  If conventional tools (i.e. Nessus and other
> scanners) can't really fingerprint it, how might one go a little further
> and determine this from a "black box" perspective?  I understand that
> with a good deal of development time and effort, this can probably be
> done, but this is probably not realistic for most organizations to do on
> their own.

Here is were the usefulness of exploit code is demostrated.

The best way to determine if a system is vulnerable to a given vulnerability 
is to actually try to exploit it. If you had a reliable exploit for the bug
you wouldnt care that much about putting a great effort into identifying
the specific codebase and version of the SSL implementation you are
testing.

Writing a good-enough vulnerability check without explotation is sometimes 
as hard or even harder than writing a working exploit.

And while we are at this. Has anybody done any research on the possibility
of stack overflows due to infinite recursion on windows or linux systems?

-ivan

---
Ivan Arce
CTO
CORE SECURITY TECHNOLOGIES

46 Farnsworth Street
Boston, MA 02210
Ph: 617-399-6980
Fax: 617-399-6987
ivan.arce@...esecurity.com
www.coresecurity.com

PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836  B25D 207B E78E 2AD1 F65A

---------------------------------------------------------------------------
----------------------------------------------------------------------------