Re: Bug#413926: wordpress: Should not ship with Etch
* Anthony Towns:
>> Viewed this way, wordpress definitely appears to have one of the /highest/
>> rates of security holes for webapps of its class.
>
> 14 bugs per year versus 12 for moodle and phpbb2 doesn't seem that big
> a difference to me.
>
> I'm not sure that bug counts like this are really useful though -- they
> don't measure the severity of the problems, and could be indicative of
> popular code that's being regularly fixed as much as low quality code
> that's being regularly broken.
Unfortuantely, our severity ratings aren't very good (this covers only
bugs from 2005 onwards):
moodle|low|5
moodle|medium|4
moodle|unimportant|5
moodle|unknown|9
phpbb2|high|1
phpbb2|low|4
phpbb2|medium|5
phpbb2|unimportant|16
phpbb2|unknown|15
wordpress|high|1
wordpress|low|5
wordpress|medium|7
wordpress|unimportant|11
wordpress|unknown|15
Apart from that, I'm not sure how much meaning we should attach to
these numbers, even if we had a higher number of vulnerabilities and
more rigorous analysis of each one. (For instance, #363580 is
apparently not included in the counts above.)
>From a software quality point of view, wordpress shares many of the
design flaws typically found in PHP applications. For instance, it
does not use prepared statements, and consequently does not separate
SQL statements and their parameters in a way that can be audited in a
straightforward manner:
wp-includes/registration.php: return $wpdb->get_var("SELECT ID FROM $wpdb->users WHERE user_email = '$email'");
The function that guards $email against malicious characters is
contained in the file wp-includes/formatting.php, without any hint
that it is security-relevant.
In another case, it's less clear if it's impossible to inject SQL via
the configuration option "start_of_week".
wp-includes/general-template.php: $arcresults = $wpdb->get_results("SELECT DISTINCT WEEK(post_date, $start_of_week) AS `week`, YEAR(post_date) AS yr, DATE_FORMAT(post_date, '%Y-%m-%d') AS yyyymmdd, count(ID) as posts FROM $wpdb->posts WHERE post_type = 'post' AND post_status = 'publish' GROUP BY WEEK(post_date, $start_of_week), YEAR(post_date) ORDER BY post_date DESC" . $limit);
AFAICS, that option is not properly sanitized when it is being set.
Wordpress includes a private copy of ezSQL (LGPLed, according to an
extremly brief statement by upstream), without proper attribution in
the debian/copyright file.
But all that can be considered best current practice, so to speak, and
should not necessarily be a reason to exclude a package from a stable
release. There might be non-technical concerns regarding the promises
of security support or the maintenance status in Debian, but I'm not
qualified to judge that.
Reply to: