Full Disclosure mailing list archives
Re: automated vulnerability testing
From: Nick FitzGerald <nick () virus-l demon co uk>
Date: Mon, 01 Dec 2003 10:15:20 +1300
"Jonathan A. Zdziarski" <jonathan () nuclearelephant 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 _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- automated vulnerability testing, (continued)
- automated vulnerability testing Choe.Sung Cont. PACAF CSS/SCHP (Nov 29)
- Re: automated vulnerability testing Todd Burroughs (Nov 29)
- RE: automated vulnerability testing Bill Royds (Nov 29)
- RE: automated vulnerability testing Peter Moody (Nov 29)
- RE: automated vulnerability testing Bill Royds (Nov 29)
- Re: automated vulnerability testing Michael Gale (Nov 29)
- Re: automated vulnerability testing Frank Knobbe (Nov 29)
- Re: automated vulnerability testing Gadi Evron (Nov 29)
- Re: automated vulnerability testing Valdis . Kletnieks (Nov 29)
- Re: automated vulnerability testing Jonathan A. Zdziarski (Nov 30)
- Re: automated vulnerability testing Nick FitzGerald (Nov 30)
- Re: automated vulnerability testing Jonathan A. Zdziarski (Nov 30)
- automated vulnerability testing Choe.Sung Cont. PACAF CSS/SCHP (Nov 29)
- Re: automated vulnerability testing Valdis . Kletnieks (Nov 29)
- Re: automated vulnerability testing Devdas Bhagat (Nov 29)