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, 1 Jan 2007 16:02:40 -0800
From: "Jim Harrison" <Jim@...tools.org>
To: "Dana Hudes" <dhudes@...es.org>, <bugtraq@...urityfocus.com>
Subject: RE: PHP as a secure language? PHP worms? [was: Re: new linux malware]

..and similar statements can be made for Basic (pickyourflavor) as well.
This argument proves my point that there is no such thing as a truly
"secure" language; it's entirely dependent on the dev skills.


-----Original Message-----
From: Dana Hudes [mailto:dhudes@...es.org] 
Sent: Monday, January 01, 2007 2:37 PM
To: bugtraq@...urityfocus.com
Subject: Re: PHP as a secure language? PHP worms? [was: Re: new linux
malware]

While I agree that it is poor coding habits on the part of many
developers that are responsible for most PHP application security flaws,
nonetheless there are features in PHP4 which encourage these habits by
choosing insecure defaults. "Magic quotes" was one example.

One of the powerful aspects of PHP, and of Perl, is the string-oriented
"typeless" approach where things magically become the appropriate type
(as compared to e.g. C, where you can blithely stuff an integer value
into a float and thereby corrupt the value if not cause a crash of the
runtime library when you feed this garbage to it -- no type conversion. 
Strict typing requiring explicit conversion (with validation) improves
security by eliminating certain types of vulnerability. Java held some
promise in this regard but the associated libraries have many  bugs
(e.g. one I just hit in JDK 1.507 for http proxy. a bug that wasn't
there in 1.4.2).  Of course, the large number of available library code
is part of the attraction of Perl, Java and PHP; ML, for example, while
I have seen CGI code written in it lacks the broad developer community
(there is one, its just small compared to the more popular languages).


Jim Harrison wrote:
> <Peeve type="pet">
> "They" (developers) and "it" (the secure language) are both moving 
> targets.
> There is no "genetic memory" with the human race; any more than there 
> is an "inherently secure" language.  For every developer that learns 
> how to write "secure code", at least one more starts cutting his/her 
> teeth in the same language; possibly for the same reasons.  Anyone who

> insists that there either exists a "secure language" or that the 
> problem of "secure code" can be "completely solved" is IMHO, severely
deluded.
> Neither will ever be even remotely true.
> </Peeve type="pet">
>
> If you have issue with someone's code habits, address it with them 
> first.  This is part & parcel to the "education" process.  If this 
> fails because of their unwillingness or inability to adjust, then 
> you've done what you can.  If this unresolved problem presents a 
> public disservice, then you report it.  Public opinion is a powerful
motivator.
>
> Jim
>
>
> -----Original Message-----
> From: Tino Wildenhain [mailto:tino@...denhain.de]
> Sent: Monday, January 01, 2007 1:00 PM
> To: Bill Nash
> Cc: Kevin Waterson; bugtraq@...urityfocus.com
> Subject: Re: PHP as a secure language? PHP worms? [was: Re: new linux 
> malware]
>
> Bill Nash schrieb:
> ...
>   
>> 	*ANY* language implemented for *ANY* purpose is as secure as the
>>     
>
>   
>> programmer makes it. The way the original post is written, 
>> s/PHP/(Perl|ASP|C|bash|BASIC|four little buddhist monks fighting over

>> an abacus)/ is applicable. The vulnerabilities that we see, that Gadi

>> refers to, aren't widespread because PHP is widespread, but because 
>> insecure applications written in PHP are. A better use of energy 
>> would
>>     
>
>   
>> be focusing on the most vulnerable platforms and educating the
>>     
> developers.
>
> But aparently they aren't educatable - hence they stick to this 
> language. (Because of the many bad examples they can cut&paste code
> from)
>
> T.
>
> All mail to and from this domain is GFI-scanned.
>
>   


All mail to and from this domain is GFI-scanned.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ