Report: Vulnerability type distributions in CVE
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."
Posted Oct 5, 2006 14:59 UTC (Thu)
by ordonnateur (guest, #6652)
[Link] (1 responses)
Posted Oct 5, 2006 19:26 UTC (Thu)
by jbh (guest, #494)
[Link]
Posted Oct 5, 2006 15:09 UTC (Thu)
by arjan (subscriber, #36785)
[Link] (1 responses)
Posted Oct 5, 2006 16:00 UTC (Thu)
by nix (subscriber, #2304)
[Link]
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.
Posted Oct 6, 2006 9:04 UTC (Fri)
by dark (guest, #8483)
[Link] (6 responses)
Posted Oct 6, 2006 11:08 UTC (Fri)
by scottt (guest, #5028)
[Link]
Easy access to a fork and exec function that takes an argument list instead of a string is indeed key.
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.
Posted Oct 12, 2006 9:15 UTC (Thu)
by jschrod (subscriber, #1646)
[Link] (4 responses)
Joachim
Posted Oct 12, 2006 13:32 UTC (Thu)
by mtk77 (guest, #6040)
[Link] (3 responses)
Posted Oct 12, 2006 13:38 UTC (Thu)
by jschrod (subscriber, #1646)
[Link] (2 responses)
Joachim
Posted Oct 12, 2006 16:47 UTC (Thu)
by mtk77 (guest, #6040)
[Link] (1 responses)
Posted Oct 12, 2006 16:51 UTC (Thu)
by mtk77 (guest, #6040)
[Link]
Report: Vulnerability type distributions in CVE
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.
Pragmatic, rather. Classifying those 1500 unspecified advisories would take (at a guess) about one man-month.Report: Vulnerability type distributions in CVE
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
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).Report: Vulnerability type distributions in CVE
PHP is the new C
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.PHP is the new C
Very true
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)
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.PHP is the new C
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
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.PHP is the new C
Yes, but. If I have a sub like:
PHP is the new C
then I might call it 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);
}
OK so far. If I call it as:
system_list_or_die("/bin/ls", "-l");
all is well. But if I don't want any parameters:
system_list_or_die("/some path with spaces/ls", "-l")
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.
system_list_or_die("/some path with spaces/ls")
I retract all the above. The trick is:
PHP is the new C
Some more obvious syntaxes don't work.
system {$_[0]} @_;