full-disclosure - automated vulnerability testing

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]

From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: automated vulnerability testing

"Jonathan A. Zdziarski" <jonathan@...learelephant.com> wrote:

> Everyone used to say Java was inherently secure, and look what happened
> to it... plagued with vulnerabilities.  No language is secure unless you
> make it so restrictive that it isn't capable of doing anything useful.

Methinks you are confusing your Javas...

There is "the Java runtime environment" (which is pretty much 
inherently secure by design) and "the Java programming language" (which 
is pretty much like any other programming language from the  
perspective of the security of standalone applications built with it).

The Java environment's design, of course, has to be implemented to be 
useful and guess what programming language many (most?) such 
implementations have used??  Yep, C and/or C++.  This was directly 
exploitable in at least one case where the underlying C/C++ function 
processing some data from the Java environment did not do suitable 
bounds checks allowing an integer overflow to "break" the underlying 
implementation.  The security of the Java runtime's design was still 
intact but the C programmer trying to implement it got it wrong.  I 
think most other failures of various Java runtime implementations have 
been "simpler" logical errors rather than being due to weaknesses in 
the programmer/implementation language interface but this is not an 
area I'm closely familiar with.

> Good programming relies on the programmer (as most have said in this
> thread). 

Yep, and when the programmers chosen cannot even correctly derive the 
logic tables for the many multifaceted decisions so many programmatic 
security decisions depend on then, as someone else pointed out recently 
in this thread, the language choice issue may be largely irrelevant.

> If you want to harden up your C programs, there are a few stack
> protectors and such out there you can compile/link with that will
> protect your code from typical stack smashing vulnerabilities and such. 
> There are also OS hardening tools out there to perform similar
> protection.

Aren't such measures -- especially the former -- simply crutches that 
effectively _encourage_ the continuation of poor (even downright 
negligent) programming practices?  (This does not mean that they cannot 
or do not help, especially if you are in the position of being able to 
build your own binaries but from source you have not the time/resources 
to audit, but advocating their use _by developers_ is, IMHO, a _VERY 
BAD THING_.

Regards,

Nick FitzGerald