[Slashcode-general] Security: details on Friday's issue, and new patch

[Jamie M. <ja...@mc...>]

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
=46ROM 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 >=3D '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 =3D map {($_ =3D> 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 with private concerns at
ja...@sl.... To notify us of additional security issues we
may not be aware of, please email sec...@sl....

This email is a copy of the text posted to slashcode.com at
<http://www.slashcode.com/article.pl?sid=3D08/01/07/2314232>.
Public comments are welcome both on this list and on the website.
We post to slashcode.com infrequently, and when we do it's usually
important.  We recommend all site admins subscribe to its
newsletter.  Please go to <http://www.slashcode.com/my/messages>
and make sure "Daily Newsletter" is set to "E-mail."
--=20
  Jamie McCarthy
 http://mccarthy.vg/
  ja...@mc...