Slash Open Source Project

Title    Full disclosure on Friday's security issue, and new patch
Date    Monday January 07 2008, @06:25PM
Author    jamiemccarthy

On Friday, January 4, 2008, a serious security vulnerability was discovered, and an exploit demonstrated, in the then-current version of Slash. The vulnerability was an SQL injection. Its effect was to allow a user with no special authorization to read any information from any table the Slash site's mysql user was authorized to read (which may include other databases, including information_schema).

This vulnerability has been present in Slash for years. We are not going to list which specific versions of Slash are vulnerable, because as far as we know, they all are. Fortunately for those of you who are not running near-current CVS, the patch is easy to apply to all versions of Slash.

The Slash programming team would like to thank blackybr, of the Russian web-security portal site, for bringing this to our attention in a responsible manner.

The ability of an attacker to read the users table is why we urged Slash sites on Friday to change their admins' passwords. Whether the threat rises to the level of requiring all your users to change their passwords, we leave up to site administrators. Mitigating factors include:

One of the first things that an attacker would likely do is to obtain an administrator's password. Since Slash keeps permanent records of all administrator accesses, you may wish to scan that log for unexpected and possibly unauthorized logins. For example:

mysql> SELECT uid, host_addr, MIN(ts), MAX(ts), COUNT(*) FROM accesslog_admin WHERE ts >= '2007-12-01 00:00:00' GROUP BY uid, host_addr;

Today, I have committed two more fields in the $form hashref to be run through filter_params. They are content_type, for which I could find no vulnerabilities, and userfield, for which a XSS vulnerability (less serious than blackybr's) was found. We therefore again urge Slash site administrators to either update to the latest version in CVS, or to manually add those two fields to the alphanumeric $form field filtering done in, as follows:

diff -U3 -r1.224 -r1.225
--- Slash/Utility/Environment/	4 Jan 2008 19:14:07 -0000	1.224
+++ Slash/Utility/Environment/	7 Jan 2008 21:30:09 -0000	1.225
@@ -1856,8 +1856,8 @@

 	# fields that have ONLY a-zA-Z0-9_
 	my %alphas = map {($_ => 1)} qw(
-		fieldname formkey commentstatus filter
-		hcanswer mode op section thisname type reskey
+		content_type fieldname formkey commentstatus filter
+		hcanswer mode op section thisname type reskey userfield
 	# Survey

Again, this is in addition to the patch mentioned on Friday, which added id.

As a personal note: none of us who work on Slash are very pleased with this, of course. The last time we made this kind of announcment was just over three years ago, which, while long, is not long enough.

We regret the oversight, and we will be taking additional steps in the coming weeks to make similar types of vulnerability both less likely and less serious. Please feel free to post any questions on this story, or to email me (Jamie McCarthy) with private concerns at To notify us of additional security issues we may not be aware of, please email If you are a Slash site administrator, please subscribe to slashcode-general (it's low-traffic). Thank you.


  1. "the patch" -
  2. "blackybr" -
  3. "" -
  4. "mentioned on Friday" -
  5. "just over three years ago" -
  6. "" -
  7. "" -
  8. "slashcode-general" -

© Copyright 2012 - Me, All Rights Reserved

printed from Slashcode, Full disclosure on Friday's security issue, and new patch on 2012-02-06 23:21:39