bugtraq - Re: How secure is software X?

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]

Message-ID: <OFEE784DE9.82EAFD3A-ON8525716F.0049E677-0425716F.004B7865@mailrouter.net>
Date: Mon, 15 May 2006 09:44:35 -0400
From: Matt.Carpenter@...icor.com
To: neonomicus@....de
Cc: bugtraq@...urityfocus.com
Subject: Re: How secure is software X?

Fabian Becker <neonomicus@....de> wrote on 05/12/2006 03:12:32 PM:

> Dear David
> in my opinion a software can either be secure or not secure. 
> I think it's a bit like a woman cannot be "a bit pregnant".
> But the protocol you are talking about can be used to tell the secure
> from the insecure pieces of software. By applying a test for these rules
> against systems, security will definitely be enhanced since software
> brandmarked with "insecure" will simply loose it's value. 
> Another question is how to verify that authors check their own software?
> If they do not do it by now, why then? The only reason I could imagine
> would be a raise in value by beeing able to say "My software is a tested
> 'secure' one".

Hello Fabian,
Respectfully, to classify security like that would be to condemn every 
software as "insecure".  What I see David proposing is more akin to "how 
far along in her pregnancy".  It is a measurement.  Hopefully we can all 
agree that with large applications (eg. Oracle, WebSphere, Windows, 
etc...) there are bugs.  While the desired direction may be 100% security 
(much like the desired personal goal is perfection), we need to be able to 
qualify how difficult it is to break applications in a standardized 
fashion.

The one caveat I might bring up is the topic of false security. 
It is difficult to prove, in a standardized methodology, that an 
application is difficult to break;  only that our methodology has failed 
to do so.  How in-depth a fuzzing to we apply for this standard?  Does the 
standard include significant levels of reverse engineering?  If so, who 
does this (since some are more proficient than others)?  If not, what true 
value does this standard prove, except that the application can withstand 
yet another script?

In concept, I agree wholeheartedly that a security qualification could be 
beneficial.  And perhaps, with all the brainpower involved, an relatively 
reliable automated method could be achieved.  There are many details which 
would need to be sorted out.  Some applications are more easily fuzzed 
than others... For example, SMTP servers have a pretty standard interface, 
they have to.  Database servers do not, although they do have underlying 
language similarities.  Web app servers, such as WebSphere and Oracle app 
server, may have commonalities, but have such a breadth of testing 
required to give any comprehensive qualification, to do so seems rather 
overwhelming.

In my own little portable mind, such a standard would require an 
infrastructure of standards, with each "class" of application being 
represented and handled separately.

One alternative proposition would be to provide a difficulty rating for 
the security researchers to apply to their vulnerability reports/analysis. 
 Simply an appendage to our normal bugtraq traffic.  Let the researchers 
grade the difficulty.  Perhaps this would be problematic as well, since it 
would take me far longer to find a vuln in Oracle than it would for 
someone like David.  But it would be a start.

$0x02