Report: Vulnerability type distributions in CVE [LWN.net]

Steve Christey at MITRE has done a bunch of statistics crunching on five years of CVE vulnerability entries. The resulting report makes interesting reading. "Format string vulnerabilities appear more frequently in open source. There are probably several factors. First, susceptible API library calls such as printf() are easily found in source code using crude methods, whereas binary reverse engineering techniques are not conducted by many researchers (this might also be an explanation for symbolic link issues). Second, many format string problems seem to occur in rarely-triggered error conditions, which makes them more difficult to test with black box methods."

to post comments

Report: Vulnerability type distributions in CVE

Posted Oct 5, 2006 14:59 UTC (Thu) by ordonnateur (guest, #6652) [Link] (1 responses)

The percentage of "unknown" vulnerabilities - those that could not be classified due to lack of details - is significantly higher in closed source than open source advisories, [...] It should be noted that 10% of issues in open source advisories do not have enough details to classify the problem.

Seems like lazy research to me. If the source code is available, looking at the patches to fix the problem should be enough to classify the problem, even if the advisory is vague.

Report: Vulnerability type distributions in CVE

Posted Oct 5, 2006 19:26 UTC (Thu) by jbh (guest, #494) [Link]

Pragmatic, rather. Classifying those 1500 unspecified advisories would take (at a guess) about one man-month.

Report: Vulnerability type distributions in CVE

Posted Oct 5, 2006 15:09 UTC (Thu) by arjan (subscriber, #36785) [Link] (1 responses)

And... in Linux format string exploits are no longer actually exploitable anymore since about 2 years (or shorter, depending on your distro).

Report: Vulnerability type distributions in CVE

Posted Oct 5, 2006 16:00 UTC (Thu) by nix (subscriber, #2304) [Link]

For Gentoo and LFS users, you have to be using GCC 4.1 or later and glibc 2.3.5+ or (preferably) glibc 2.4, and you have to compile with -D_FORTIFY_SOURCE=2 (at least I think it's level 2 that finds this sort of thing).

PHP is the new C

Posted Oct 6, 2006 1:27 UTC (Fri) by gdt (subscriber, #6284) [Link] (7 responses)

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.

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.