[rsyslog] SQL Injection Vulnerability in rsyslogd

[Rainer Gerhards]

An SQL injection vulnerability was found in all rsyslog releases prior
to the ones announced on 2005-09-23. An attacker can send a
specifically-crafted syslog message to rsyslogd and take ownership of
the machine.

This can be locally exploited if rsyslogd is listening on the local
socket. Wes assume it is doing this in almost all cases. It can also be
exploited remotely if rsyslogd is listening on network sockets and the
attacker is not blocked from sending messages to rsyslogd (e.g. if not
blocked by firewalling).

The vulnerability can be used to take full ownership of the computer a
compromised rsyslog is running on.

We do not know of any case where this was exploited in practice. The bug
was discovered during security-testing rsyslogd.

As of this writing, fixed versions exist both for the stable and the
development branch. They are named 1.0.1 and 1.10.1. They can be
obtained via the following links:

For 1.0.1 stable:
   http://www.rsyslog.com/Downloads-index-req-getit-lid-17.phtml

For 1.10.1 development:
   http://www.rsyslog.com/Downloads-index-req-getit-lid-18.phtml

As this is a serious vulnerability, we urge all users to update to the
fixed version as soon as possible.

If you have turned on NO_BACKSLASH_ESCAPES in MySQL, you MUST make
changes to your configuration file. Read DETAILS below to learn more.

DETAILS
While rsyslog currently supports MySQL only, it has a database-ignorant
design approach.  As part of it, SQL escaping is done inside the
template system and not inside the database layer. This is also
necessary because files can be used to store SQL commands that will be
imported offline to a database (the same for pipes and other data
destinations). Another reason for escaping in the template system is
that rsyslogd - by intention - allows the user to craft any SQL
statement with the template system. There is a special template option -
SQL - telling the template system that the template is to be used for
database and such escaping of special characters must occur.

During rsyslogd's design, care has been taken that only templates with
an active SQL option can be used together with the "write database"
action.

The template system uses standard SQL escapes. Unfortuantely, some
databases (MySQL is among them) violate the SQL standard and allow their
own escape sequences. These MySQL-extended escape sequences were not
properly escaped and could be used to circumvent the escaping mechanism
present in the template system. This has now been fixed.

The fix now provides two different escaping options for the template
system. One is "sql", which now supports the MySQL extensions. The other
one is "stdsql", which supports the standard escapes. The option naming
is not intuitive, one might have expected that "sql" would take care of
SQL-standard compliant databases. However, we have decided against this
because the way it is now allows users to fix the issue by just
upgrading rsyslogd. As the "old" name has the new encoding and rsyslogd
currently supports only MySQL, this will fix the issue. However, if the
user has turned on NO_BACKSLASH_ESCAPES in MySQL, further action is
required. The same is true if the SQL option was used to write log files
that were later manually feed into another database. In these cases,
review the new options, their meaning and restrictions in the
rsyslog.conf manual:

   http://www.rsyslog.com/Documentation-/rsyslog_conf.html.phtml


CREDITS
There was an anonymous poster quoting the possibility of a SQL injection
on the sourcefourge bug tracker. While his report was very generic, it
was one of the reasons a security audit was reapplied. Many thanks to
whoever that was.

QUESTIONS
... should be addressed either to the rsyslog mailing list or the
support forums at rsyslog.com.

Rainer Gerhards