bugtraq - Re: Misinformation in Security Advisories (ASN.1)

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: Mon, 16 Feb 2004 13:57:16 -0600 (CST)
From: evol@...ner.halo.nu
To: John Compton <john_compton24@...oo.com>
Cc: bugtraq@...urityfocus.com
Subject: Re: Misinformation in Security Advisories (ASN.1)


> reasons. I'd like to point out a couple examples, and
> promote discussion as to how this misinformation
> affects the security community and the non-experts who
> rely on this information to be valid.
This problem has been solved in several other sectors of buisness.  If
you're relying on contractual statements to be valid in court you should
rely on an attorney.  You will feel more secure if your attorney has a
good track record, and is respected by peers of both the attorney and
corporations such as yourself.  You can't be 100% sure that everything's
going to hold up until you go to trial.  The same is true with software
vulnerabilities.  Any researcher who's worth his salt has been up against
software that has an error condition whose parameters are not straight
forwardly exploitable yet has found a way to exploit it.  I am aware of
two or three organizations that are in the top of the game with respect to
this type of information and if I could speak openly about such
organizations a lot of the information I have would suprise you.  Not all
top 5 security corporations are what their websites/client lists would
make them out to be.

> You are likely not going to see any more than the DoS
You just had to use the term likely which softens the impact of this
sentence.  Rightly so too.  You have not thoroughly investigated all of
the attack vectors and the memory layout of each process, and the
internals of the functions in question, etc.  When it gets down to it,
proving something isn't exploitable can be quite like mathematically
proving an operating system is secure.  As I said previously, there are
some vendors who you can trust with their opinion to a sound level and
some who are snake oil.

Regards,
  Evol