bugtraq - RE: PHP as a secure language? PHP worms?

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: Tue, 2 Jan 2007 06:17:42 -0800
From: "Jim Harrison" <Jim@...tools.org>
To: <bugtraq@...urityfocus.com>
Subject: RE: PHP as a secure language? PHP worms?

Actually, that's my point.
By definition, such a language would prevent any insecure coding.
Simply making it difficult only increases the "security index" (new
rating system?); it does not make the language "secure".

-----Original Message-----
From: Duncan Simpson [mailto:dps@...pson.demon.co.uk] 
Sent: Tuesday, January 02, 2007 4:02 AM
To: Jim Harrison
Cc: bugtraq@...urityfocus.com
Subject: Re: PHP as a secure language? PHP worms?

Nobody has seen fit to point this out but there *are* secure languages.
In general these languages have limited feature sets or, at least in the
case of java, explicit sandbox features intended to stop bad things
happenning. Groups of monks competing for an abacus are probably unable
to read your password file, for example.

Some languages make particular vsorts of vulnerability easy to implement
and arguably this is a bad thing. Nobody would not be hit if they did
proper input validation but that requires real effort and is tedious to
implement.

PHP's URL as filename and register_globals features make several sorts
of abuse trivial.
I know the latter is off by default but lots of vulnerable scripts
require you to enable this feature.

C makes bofs and integer overflows easy to implement but fopen(3) lacks
magic features, so putting http://evil.example.com/evilcode? in front of
a filename gets the crackers nowhere. Arguably writing CGI applications
is harder too, so those that do have more clues.

perl is nice but you have to wacth out for strings containing nulls and
the magic features of perl's open function.

etc ad infinitum.

I am currently using C for my CGI programs but that is because several
large operations that get used a lot are a few thousands lines of C for
speed. My choice of CGI library also offers ZIP arhive expansion and
there are multiple instance where this is useful (the filenames in the
ZIP acrhive are ignored).

AFAIK there are no bof, integer overflow or SQL injection features yet
:-)
--
Duncan (-:
"software industry, the: unique industry where selling substandard goods
is legal and you can charge extra for fixing the problems."

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

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