Main Stories
Slash Boxes

Slash Open Source Project

Full Disclosure and Patches on CVS Vulnerability

posted by jamiemccarthy on 02:50 PM December 20th, 2004   Printer-friendly   Email story
The "security issue" described on the morning of Dec. 15th is actually two separate and unrelated cross-site scripting (XSS) bugs. We're disclosing all of what we know about them at this point to allow site admins to patch sites which cannot reasonably be upgraded to the latest, fixed version of the code, the Dec. 8th build R_2_5_0_41.

Both of these issues were found by Michael Krax who we understand will be publishing something about them shortly. Again, we thank Mr. Krax for responsibly reporting these issues to us and letting us give administrators running Slash time to upgrade their code.

The first security bug was introduced to Slash in May 2002. The second was introduced in October 2004. Both have been fixed in CVS since Dec. 8, 2004. Neither is present in our last official release, version 2.2.6.

Impact and Recommended Action

Since today we are providing full disclosure, every Slash site administration should assume that attackers have this information and are actively trying to use it to steal users' and admins' cookies. (Unless you are running MySQL in an unusual and highly discouraged configuration, this would be the extent of the damage that could be caused to your site.)

If you are not familiar with XSS attacks, please Google and read about them. In this type of attack, someone can steal a user's Slash site cookie by tricking them into clicking on a link to a specially-crafted URL on that Slash site. If your Slash site uses logtokens, which it probably does if it was running code from January 2004 or later, the impact of this is limited: the cookie will only work to log the attacker in to your account from the victim's Class B subnet (by default). It is possible but unlikely that an attacker could gain an admin's password. Nevertheless, we would advise you, as a precaution, to force password changes for all your site admins.

If your site's code was from December 2003 or older, however, an XSS attack can steal your users' and admins' passwords. If that is the case, we would strongly advise you to force password changes for all your site admins, and furthermore to scan your site's accesslog_admin table looking for anomalous connections. For example, one helpful command to find unexpected admin logins is:

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

Obviously, stealing users' passwords has a serious impact as well. Forcing or advising all your site users to change their passwords is often not a step to take lightly; that, of course, is up to you. Again, if the code your site has been running is from January 2004 or later, what is in user cookies is a logtoken which, while it can allow an attacker to impersonate a user or admin, cannot help an attacker to discover a password.

Patching

At this time, our recommendation is that all CVS Slash sites be upgraded to the CVS tag R_2_5_0_41. Brief instructions for doing so are here, and as this story notes, discussion about and help for the upgrade are available on IRC and on the mailing list.

If your site is running a CVS version of Slash from which it is not currently feasible to upgrade to tag R_2_5_0_41, here are the steps to patch your site and eliminate these two bugs.

(We are describing the changes in English, here, because a single patch in computer-readable format may not successfully apply on all versions of Slash from the past two years.)

First Bug

The first bug is in plugins/Search/search.pl, versions 1.41 to 1.86 inclusive. (To determine version number: "grep '$Id' search.pl".)

A quick way to try to determine whether your site is vulnerable is to try loading this URL on a javscript-enabled browser:

http://your.site.address/search.pl?topic="%3e%3csc ript%3ealert("hello")%3c/script%3e

If an alert window is created, your site is definitely vulnerable. If not, your site may or may not be vulnerable.

To fix it, apply the first change shown on this webpage:

In other words, change this code in search.pl:

# Backwards compatibility, we now favor tid over topic
$form->{tid} ||= $form->{topic};

To this:

# Backwards compatibility, we now favor tid over topic
if ($form->{topic}) {
 if ($form->{topic} =~ s/^([+-]?[\d.]+).*$/$1/s) {
  $form->{tid} ||= $form->{topic};
 }
 delete $form->{topic};
}

That fixes the XSS bug introduced in May of 2002.

Second Bug

The second bug was introducted in Slash/DB/MySQL/MySQL.pm, versions 1.702 and later. The fix for this bug is is Slash/Utility/Environment/Enviroment.pm, versions 1.155 and later. In other words, your site is vulnerable if the installed version of MySQL.pm is version 1.702 or later, but the installed version of Environment.pm is version 1.154 or earlier.

This second XSS vulnerability shows up in submit.pl.

A quick way to try to determine whether your site is vulnerable is to try loading this URL on a javscript-enabled browser that is logged in as an admin:

http://your.site.address/submit.pl?op=list&filter= "%3e%3cscript%3ealert("hello")%3c/script%3e

If an alert window is created, your site is definitely vulnerable. If not, your site may or may not be vulnerable.

To fix it, apply the second change shown on this webpage (the first one won't hurt either if you want to do that):

In other words, in Environment.pm, append the word "filter" here, as shown in this code:

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

That fixes the XSS bug introduced in October 2004.

Final Notes

If you are a Slash site administrator, you should be subscribed to the slashcode-general mailing list, so you can receive timely notifications of security issues:

https://lists.sourceforge.net/lists/listinfo/slash code-general

We regret these security issues. This is the first security notification issued for Slash in over two years, but one is too many, and we are reviewing our programming process to try to prevent this from happening again.

Private questions about these issues can be addressed to me on IRC (user "jamie" in #slash on irc.slashnet.org) or in email at jamie@slashdot.org; to notify us of additional security issues we may not be aware of, please email security@slashcode.com. Thank you.

Related Stories

Slash: Full disclosure on Friday's security issue, and new patch 3 comments [+]

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 forum.antichat.ru, 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:

  • We are not aware of this attack actually having been used. Of course, since we are providing full information today, every Slash site administrator should assume that attackers are now actively trying to penetrate your site using this information.
  • Passwords are MD5'd in the users table, so an attacker does not learn them directly. (It is of course likely that one or more of your users has an MD5 that shows up in a dictionary hash table, and/or than an attacker can brute-force the hashes offline.)
  • If your site is running MySQL 4.0 or earlier, we do not know of any way that significant data could be retrieved. SQL injections on MySQL do not allow for multiple queries in the default configuration, so the way to retrieve data is to inject an ANDed subquery into a WHERE clause known to be true and see whether the expected data is successfully returned. This tells the attacker one bit of information, for example, whether ASCII(SUBSTRING((SELECT x FROM y WHERE z), 1, 1)) > 90. Absent subqueries, which were added in MySQL 4.1, only data from the main query's table can be retrieved. In this case, the only known exploitable table is journals, from which not much interesting can be learned.
  • As far as we know, numerous requests in this fashion are required to obtain each byte of data. On the order of 100 requests are needed to obtain a user password. You may be able to scan your site's web logs to see if you can locate multiple suspicious-looking requests, especially to journal.pl. The word "select" in a query string would be a giveaway.

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 Environment.pm, as follows:

diff -U3 -r1.224 -r1.225
--- Slash/Utility/Environment/Environment.pm	4 Jan 2008 19:14:07 -0000	1.224
+++ Slash/Utility/Environment/Environment.pm	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
 		comments_control
 	),
 	# 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 slashcode.com story, or to email me (Jamie McCarthy) with private concerns at jamie@slashdot.org. To notify us of additional security issues we may not be aware of, please email security@slashcode.com. If you are a Slash site administrator, please subscribe to slashcode-general (it's low-traffic). Thank you.

This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login
Loading... please wait.