SQL Injection Vulnerability in rsyslogd

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 potentially 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 potentially be used to take full ownership of the computer a compromised rsyslog is running on. The extend of the compromise is depending on the permissions of the user used to connect to MySQL.

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