PHP is the new C [LWN.net]

PHP is the new C

Posted Oct 6, 2006 1:27 UTC (Fri) by gdt (subscriber, #6284)
Parent article: Report: Vulnerability type distributions in CVE

The most worrying trend is that a relatively new open source language, PHP, is responsible for a huge number of vulnerabilities.

And of course, the design limitations of C continue to make themselves felt, retaining the number 1 position.

Also interesting is that use of the system() call is responsible for a lot of vulnerabilities, as opposed to fork() and exec*() which does not interpret shell characters, A system() alternative which calls a program directly rather than via the shell would overcome this class of error.

to post comments

PHP is the new C

Posted Oct 6, 2006 9:04 UTC (Fri) by dark (guest, #8483) [Link] (6 responses)

It's often annoyed me that scripting languages tend to provide an insecure interface to system() by default, and you have to jump through all sorts of hoops to get access to fork/exec, if you can do it at all. All I'm asking for is something similar to system() that takes an array of arguments and bypasses the shell. Giving programmers easy access to that would avoid a huge number of vulnerabilities.

Very true

Posted Oct 6, 2006 11:08 UTC (Fri) by scottt (subscriber, #5028) [Link]

Easy access to a fork and exec function that takes an argument list instead of a string is indeed key.

In python you do:
    r = subprocess.call(['ls', '/tmp'])
and you can pass a string through the shell if you really want to:
    r = subprocess.call(['ls /tmp'], shell=True)

You can also pass in a function to be executed between fork and exec to set resource usage limits, redirect standard input/output etc. One part of the python standard library that I really appreciate.

PHP is the new C

Posted Oct 12, 2006 9:15 UTC (Thu) by jschrod (subscriber, #1646) [Link] (4 responses)

Actually, Perl does this. Still, it seems that many programmers don't know it since I see lots of code where system() is called with a string (going via /bin/sh) instead of an array (going via fork/exec). Therefore, it's not only a matter of providing the functionality, it's a matter of promoting it and making it the `typical' method to do.

Joachim

PHP is the new C

Posted Oct 12, 2006 13:32 UTC (Thu) by mtk77 (guest, #6040) [Link] (3 responses)

The other problem with perl is that you can't use the array version of system() if you don't want to pass any args.

PHP is the new C

Posted Oct 12, 2006 13:38 UTC (Thu) by jschrod (subscriber, #1646) [Link] (2 responses)

That's not a problem; Perl uses execvp as long as there are no shell metacharacters in the string. Check out perldoc -f system, at the end of the first paragraph. And you can force it to sidestep the /bin/sh route by supplying the PROGRAM argument in any case.

Joachim

PHP is the new C

Posted Oct 12, 2006 16:47 UTC (Thu) by mtk77 (guest, #6040) [Link] (1 responses)

Yes, but. If I have a sub like:

sub system_list_or_die
{
    my $ret = system @_;
    return 0 unless $ret;
    # yes, this should use posix wait.h constants
    my $xval = $ret >> 8;
    die "@_ exited with status $xval" if $xval;
    die "@_ exited with signal ".($ret & 0xff);
}

then I might call it like:

system_list_or_die("/bin/ls", "-l");

OK so far. If I call it as:

system_list_or_die("/some path with spaces/ls", "-l")

all is well. But if I don't want any parameters:

system_list_or_die("/some path with spaces/ls")

it doesn't work as hoped, and there is no way to force it to (that I have been able to find). This is a big problem with hiding both versions behind the same API.

PHP is the new C

Posted Oct 12, 2006 16:51 UTC (Thu) by mtk77 (guest, #6040) [Link]

I retract all the above. The trick is:

system {$_[0]} @_;

Some more obvious syntaxes don't work.