[prev in list] [next in list] [prev in thread] [next in thread] 

List:       slashcode-general
Subject:    [Slashcode-general] CVS Slash Security Advisory: Full Disclosure and Patches
From:       Jamie McCarthy <jamie () mccarthy ! vg>
Date:       2004-12-20 18:11:08
Message-ID: r02010400-1037-86334DE152B211D9A737000A95959922 () [192 ! 168 ! 0 ! 159]
[Download RAW message or body]

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 <http://www.mikx.de/>,
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 webpage notes, discussion about
and help for the upgrade are available on IRC and on the mailing
list.

<http://www.slashcode.com/article.pl?sid=04/12/15/1540200>

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%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 first change shown on this webpage:

<http://cvs.sourceforge.net/viewcvs.py/slashcode/slash/plugins/Search/search.pl?r1=1.86&r2=1.87>


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):

<http://cvs.sourceforge.net/viewcvs.py/slashcode/slash/Slash/Utility/Environment/Environment.pm?r1=1.154&r2=1.155>


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/slashcode-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.
-- 
  Jamie McCarthy
 http://mccarthy.vg/
  jamie@mccarthy.vg


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Slashcode-general mailing list
Slashcode-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/slashcode-general


[prev in list] [next in list] [prev in thread] [next in thread]