From rgerhards at hq.adiscon.com Mon Sep 5 15:04:49 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 5 Sep 2005 15:04:49 +0200 Subject: [rsyslog] rsyslog 0.9.8 released - soon to be final Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3990@grfint2.intern.adiscon.com> Hi all, today, I have released rsyslog 0.9.8. This release has only minor changes compared to the previous one. Most importantly the startup and shutdown messages are now more consistent and informative. Which, of course, is not a big deal. The main reason for this release was to have one final shot before the release of the first 1.0 final. I have withhold any updated during the past 3 weeks and fortunately did not get any error reports (but there was some user activity, so it is save to assume rsyslog did receive some further testing. As I made changes, I would like to have this code run at least a little while before moving it to final. If nothing goes wrong, I'll do that towards the end of the week or early next week. Most probably, new features will be introduced after that. Rainer From rgerhards at hq.adiscon.com Mon Sep 12 18:18:32 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 12 Sep 2005 18:18:32 +0200 Subject: [rsyslog] rsyslog 1.0.0 stable released Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E39E8@grfint2.intern.adiscon.com> Hi all, I have just released rsyslog 1.0.0, the first (officialy) stable version of rsyslog. Feature-wise there is no difference to 0.9.8, it just has some minor doc changes plus a very little bug fix in the usage() function. >From the release point of view, however, this release is a very important achivement. It provides a solid basis for those interested in running a stable release. The 1.0.0 codebase has been run for several weeks now without any error reports. It has also been reviewed, and all issues have been ironed out. 1.0.0 creates the stable branch. Please note that the stable branch will primarily receive fixes. The unstable branch (to be created soon) will have all the new cool features. For details on release naming, please see http://www.rsyslog.com/index.php?module=Static_Docs&func=view&f=/version _naming.html If you run any version of rsyslog, I recommend moving to 1.0.0. I hope this release is helpful. Rainer Gerhards From rgerhards at hq.adiscon.com Tue Sep 20 18:33:18 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 20 Sep 2005 18:33:18 +0200 Subject: [rsyslog] rsyslog 1.10.0 released - major new features Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3A72@grfint2.intern.adiscon.com> I am proud to announce release 1.10.0, the first development release after 1.0.0 stable. Release 1.10.0 contains major new features, most importantly the ability to filter on any syslog message property, not just facility and severity. For example, it can now be filtered based on the content of the message itself (e.g. log to a different file if it contains the string "error"). Other new features include the ability to conditionally discard messages, regular expression support inside templates, performance improvements, and more. Find the full change log at http://www.rsyslog.com/Article32.phtml I hope this work is useful. Feedback is appreciated. Rainer Gerhards From rgerhards at hq.adiscon.com Fri Sep 23 13:58:45 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 23 Sep 2005 13:58:45 +0200 Subject: [rsyslog] SQL Injection Vulnerability in rsyslogd Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3AAD@grfint2.intern.adiscon.com> 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 From rgerhards at hq.adiscon.com Fri Sep 23 16:53:21 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 23 Sep 2005 16:53:21 +0200 Subject: [rsyslog] rsyslog 1.10.1 released Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3AB2@grfint2.intern.adiscon.com> I have just released rsyslog 1.10.1. This release is slightly unscheduled. It orginally should have been released in a few days with some more enhancements. However, we have discovered a SQL injection vulnerability in rsyslog and decided to release a fix for the development branch as soon as possible (thankfully the code was at an interim milestone, so it was easy to do). The most important feature of 1.10.1 obviously is the fix for the SQL injection vulnerability. Besides that, it offers a fix in handling broken MySQL connections. Feature-wise, it adds the ability to execute scripts (and other programs) on message reception. Together with the new filtering engine, this can, for example, be used to generate email alerts on important events. The change log can be found at http://www.rsyslog.com/Article36.phtml. I hope this release is useful. Please expect the originally scheduled feature set some time next week. Among others, it will bring additional comparison operations for the new filter engine. Rainer From rgerhards at hq.adiscon.com Tue Sep 27 17:27:29 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 27 Sep 2005 17:27:29 +0200 Subject: [rsyslog] rsyslog 1.10.2 released Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3AD6@grfint2.intern.adiscon.com> Hi all, I am glad to announce rsyslog 1.10.2, the regularly scheduled release. The main improvements are: - ability to limit the systems rsyslogd accepts messages from - new comparison operations for the property-based filters Of course, there are also some other new features as well as some bug fixes. With the two new major feature additions rsyslog now has great flexibility in filter processing as well as good security hardening abilities. I will now most probably turn back to the protocol support modules and look at RFC 3195 and syslog-protocol (if no urgent other need arises). I recommend upgrading to 1.10.2 if you are running any release of the development branch. Full details can be found in the change log at http://www.rsyslog.com/Article38.phtml Because I was often asked what can be done with new features, I have included some lines from the sample configuration file after my signature. I hope they are useful. As always, feedback is deeply appreciated. Rainer -- excerpt from sample.conf -- # We limit who can send us messages: $AllowedSender UDP, 192.0.2.0/24, 10.0.0.1 # all machines in 192.0.2 as well as 10.0.0.1 $AllowedSender TCP, 10.0.0.1 # for TCP, we allow only 10.0.0.1 # remove the AllowedSender directives if you do not want to limit # who can send rsyslogd messages (not recommended) # We also support property-based filters, which allow for nice # things. Let's for example assume that you receive a lot of # nonsense messages with "ID-4711" in the message text. You know # that you will never need these messages. So you simply discard them :msg, contains, "ID-4711" ~ # or you would like to store messages from a specific host to # a different file: :FROMHOST, isequal,"myhost.example.com" /var/log/myhost.log # everyting that does not contain "error" should also be # discarded :msg, !contains, "error" ~ # and the rest go to a seperate file *.* /var/log/error # (keep in mind that the two directives shown immediately # above must be kept in that order to actually work) # you can also execute a script. Let's assume, for example, you need # to execute "turn-diesel-generator-on" when "power failed" is contained # in a message... ;) :msg, contains, "power failed" ^turn-diesel-generator-on # (The script is passed the syslog message as first and only paramter. # Other parameters can currently not be specified.) From rgerhards at hq.adiscon.com Mon Sep 5 15:04:49 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 5 Sep 2005 15:04:49 +0200 Subject: [rsyslog] rsyslog 0.9.8 released - soon to be final Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3990@grfint2.intern.adiscon.com> Hi all, today, I have released rsyslog 0.9.8. This release has only minor changes compared to the previous one. Most importantly the startup and shutdown messages are now more consistent and informative. Which, of course, is not a big deal. The main reason for this release was to have one final shot before the release of the first 1.0 final. I have withhold any updated during the past 3 weeks and fortunately did not get any error reports (but there was some user activity, so it is save to assume rsyslog did receive some further testing. As I made changes, I would like to have this code run at least a little while before moving it to final. If nothing goes wrong, I'll do that towards the end of the week or early next week. Most probably, new features will be introduced after that. Rainer From rgerhards at hq.adiscon.com Mon Sep 12 18:18:32 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 12 Sep 2005 18:18:32 +0200 Subject: [rsyslog] rsyslog 1.0.0 stable released Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E39E8@grfint2.intern.adiscon.com> Hi all, I have just released rsyslog 1.0.0, the first (officialy) stable version of rsyslog. Feature-wise there is no difference to 0.9.8, it just has some minor doc changes plus a very little bug fix in the usage() function. >From the release point of view, however, this release is a very important achivement. It provides a solid basis for those interested in running a stable release. The 1.0.0 codebase has been run for several weeks now without any error reports. It has also been reviewed, and all issues have been ironed out. 1.0.0 creates the stable branch. Please note that the stable branch will primarily receive fixes. The unstable branch (to be created soon) will have all the new cool features. For details on release naming, please see http://www.rsyslog.com/index.php?module=Static_Docs&func=view&f=/version _naming.html If you run any version of rsyslog, I recommend moving to 1.0.0. I hope this release is helpful. Rainer Gerhards From rgerhards at hq.adiscon.com Tue Sep 20 18:33:18 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 20 Sep 2005 18:33:18 +0200 Subject: [rsyslog] rsyslog 1.10.0 released - major new features Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3A72@grfint2.intern.adiscon.com> I am proud to announce release 1.10.0, the first development release after 1.0.0 stable. Release 1.10.0 contains major new features, most importantly the ability to filter on any syslog message property, not just facility and severity. For example, it can now be filtered based on the content of the message itself (e.g. log to a different file if it contains the string "error"). Other new features include the ability to conditionally discard messages, regular expression support inside templates, performance improvements, and more. Find the full change log at http://www.rsyslog.com/Article32.phtml I hope this work is useful. Feedback is appreciated. Rainer Gerhards From rgerhards at hq.adiscon.com Fri Sep 23 13:58:45 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 23 Sep 2005 13:58:45 +0200 Subject: [rsyslog] SQL Injection Vulnerability in rsyslogd Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3AAD@grfint2.intern.adiscon.com> 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 From rgerhards at hq.adiscon.com Fri Sep 23 16:53:21 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 23 Sep 2005 16:53:21 +0200 Subject: [rsyslog] rsyslog 1.10.1 released Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3AB2@grfint2.intern.adiscon.com> I have just released rsyslog 1.10.1. This release is slightly unscheduled. It orginally should have been released in a few days with some more enhancements. However, we have discovered a SQL injection vulnerability in rsyslog and decided to release a fix for the development branch as soon as possible (thankfully the code was at an interim milestone, so it was easy to do). The most important feature of 1.10.1 obviously is the fix for the SQL injection vulnerability. Besides that, it offers a fix in handling broken MySQL connections. Feature-wise, it adds the ability to execute scripts (and other programs) on message reception. Together with the new filtering engine, this can, for example, be used to generate email alerts on important events. The change log can be found at http://www.rsyslog.com/Article36.phtml. I hope this release is useful. Please expect the originally scheduled feature set some time next week. Among others, it will bring additional comparison operations for the new filter engine. Rainer From rgerhards at hq.adiscon.com Tue Sep 27 17:27:29 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 27 Sep 2005 17:27:29 +0200 Subject: [rsyslog] rsyslog 1.10.2 released Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3AD6@grfint2.intern.adiscon.com> Hi all, I am glad to announce rsyslog 1.10.2, the regularly scheduled release. The main improvements are: - ability to limit the systems rsyslogd accepts messages from - new comparison operations for the property-based filters Of course, there are also some other new features as well as some bug fixes. With the two new major feature additions rsyslog now has great flexibility in filter processing as well as good security hardening abilities. I will now most probably turn back to the protocol support modules and look at RFC 3195 and syslog-protocol (if no urgent other need arises). I recommend upgrading to 1.10.2 if you are running any release of the development branch. Full details can be found in the change log at http://www.rsyslog.com/Article38.phtml Because I was often asked what can be done with new features, I have included some lines from the sample configuration file after my signature. I hope they are useful. As always, feedback is deeply appreciated. Rainer -- excerpt from sample.conf -- # We limit who can send us messages: $AllowedSender UDP, 192.0.2.0/24, 10.0.0.1 # all machines in 192.0.2 as well as 10.0.0.1 $AllowedSender TCP, 10.0.0.1 # for TCP, we allow only 10.0.0.1 # remove the AllowedSender directives if you do not want to limit # who can send rsyslogd messages (not recommended) # We also support property-based filters, which allow for nice # things. Let's for example assume that you receive a lot of # nonsense messages with "ID-4711" in the message text. You know # that you will never need these messages. So you simply discard them :msg, contains, "ID-4711" ~ # or you would like to store messages from a specific host to # a different file: :FROMHOST, isequal,"myhost.example.com" /var/log/myhost.log # everyting that does not contain "error" should also be # discarded :msg, !contains, "error" ~ # and the rest go to a seperate file *.* /var/log/error # (keep in mind that the two directives shown immediately # above must be kept in that order to actually work) # you can also execute a script. Let's assume, for example, you need # to execute "turn-diesel-generator-on" when "power failed" is contained # in a message... ;) :msg, contains, "power failed" ^turn-diesel-generator-on # (The script is passed the syslog message as first and only paramter. # Other parameters can currently not be specified.) From rgerhards at hq.adiscon.com Mon Sep 5 15:04:49 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 5 Sep 2005 15:04:49 +0200 Subject: [rsyslog] rsyslog 0.9.8 released - soon to be final Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3990@grfint2.intern.adiscon.com> Hi all, today, I have released rsyslog 0.9.8. This release has only minor changes compared to the previous one. Most importantly the startup and shutdown messages are now more consistent and informative. Which, of course, is not a big deal. The main reason for this release was to have one final shot before the release of the first 1.0 final. I have withhold any updated during the past 3 weeks and fortunately did not get any error reports (but there was some user activity, so it is save to assume rsyslog did receive some further testing. As I made changes, I would like to have this code run at least a little while before moving it to final. If nothing goes wrong, I'll do that towards the end of the week or early next week. Most probably, new features will be introduced after that. Rainer From rgerhards at hq.adiscon.com Mon Sep 12 18:18:32 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 12 Sep 2005 18:18:32 +0200 Subject: [rsyslog] rsyslog 1.0.0 stable released Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E39E8@grfint2.intern.adiscon.com> Hi all, I have just released rsyslog 1.0.0, the first (officialy) stable version of rsyslog. Feature-wise there is no difference to 0.9.8, it just has some minor doc changes plus a very little bug fix in the usage() function. >From the release point of view, however, this release is a very important achivement. It provides a solid basis for those interested in running a stable release. The 1.0.0 codebase has been run for several weeks now without any error reports. It has also been reviewed, and all issues have been ironed out. 1.0.0 creates the stable branch. Please note that the stable branch will primarily receive fixes. The unstable branch (to be created soon) will have all the new cool features. For details on release naming, please see http://www.rsyslog.com/index.php?module=Static_Docs&func=view&f=/version _naming.html If you run any version of rsyslog, I recommend moving to 1.0.0. I hope this release is helpful. Rainer Gerhards From rgerhards at hq.adiscon.com Tue Sep 20 18:33:18 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 20 Sep 2005 18:33:18 +0200 Subject: [rsyslog] rsyslog 1.10.0 released - major new features Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3A72@grfint2.intern.adiscon.com> I am proud to announce release 1.10.0, the first development release after 1.0.0 stable. Release 1.10.0 contains major new features, most importantly the ability to filter on any syslog message property, not just facility and severity. For example, it can now be filtered based on the content of the message itself (e.g. log to a different file if it contains the string "error"). Other new features include the ability to conditionally discard messages, regular expression support inside templates, performance improvements, and more. Find the full change log at http://www.rsyslog.com/Article32.phtml I hope this work is useful. Feedback is appreciated. Rainer Gerhards From rgerhards at hq.adiscon.com Fri Sep 23 13:58:45 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 23 Sep 2005 13:58:45 +0200 Subject: [rsyslog] SQL Injection Vulnerability in rsyslogd Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3AAD@grfint2.intern.adiscon.com> 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 From rgerhards at hq.adiscon.com Fri Sep 23 16:53:21 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 23 Sep 2005 16:53:21 +0200 Subject: [rsyslog] rsyslog 1.10.1 released Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3AB2@grfint2.intern.adiscon.com> I have just released rsyslog 1.10.1. This release is slightly unscheduled. It orginally should have been released in a few days with some more enhancements. However, we have discovered a SQL injection vulnerability in rsyslog and decided to release a fix for the development branch as soon as possible (thankfully the code was at an interim milestone, so it was easy to do). The most important feature of 1.10.1 obviously is the fix for the SQL injection vulnerability. Besides that, it offers a fix in handling broken MySQL connections. Feature-wise, it adds the ability to execute scripts (and other programs) on message reception. Together with the new filtering engine, this can, for example, be used to generate email alerts on important events. The change log can be found at http://www.rsyslog.com/Article36.phtml. I hope this release is useful. Please expect the originally scheduled feature set some time next week. Among others, it will bring additional comparison operations for the new filter engine. Rainer From rgerhards at hq.adiscon.com Tue Sep 27 17:27:29 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 27 Sep 2005 17:27:29 +0200 Subject: [rsyslog] rsyslog 1.10.2 released Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3AD6@grfint2.intern.adiscon.com> Hi all, I am glad to announce rsyslog 1.10.2, the regularly scheduled release. The main improvements are: - ability to limit the systems rsyslogd accepts messages from - new comparison operations for the property-based filters Of course, there are also some other new features as well as some bug fixes. With the two new major feature additions rsyslog now has great flexibility in filter processing as well as good security hardening abilities. I will now most probably turn back to the protocol support modules and look at RFC 3195 and syslog-protocol (if no urgent other need arises). I recommend upgrading to 1.10.2 if you are running any release of the development branch. Full details can be found in the change log at http://www.rsyslog.com/Article38.phtml Because I was often asked what can be done with new features, I have included some lines from the sample configuration file after my signature. I hope they are useful. As always, feedback is deeply appreciated. Rainer -- excerpt from sample.conf -- # We limit who can send us messages: $AllowedSender UDP, 192.0.2.0/24, 10.0.0.1 # all machines in 192.0.2 as well as 10.0.0.1 $AllowedSender TCP, 10.0.0.1 # for TCP, we allow only 10.0.0.1 # remove the AllowedSender directives if you do not want to limit # who can send rsyslogd messages (not recommended) # We also support property-based filters, which allow for nice # things. Let's for example assume that you receive a lot of # nonsense messages with "ID-4711" in the message text. You know # that you will never need these messages. So you simply discard them :msg, contains, "ID-4711" ~ # or you would like to store messages from a specific host to # a different file: :FROMHOST, isequal,"myhost.example.com" /var/log/myhost.log # everyting that does not contain "error" should also be # discarded :msg, !contains, "error" ~ # and the rest go to a seperate file *.* /var/log/error # (keep in mind that the two directives shown immediately # above must be kept in that order to actually work) # you can also execute a script. Let's assume, for example, you need # to execute "turn-diesel-generator-on" when "power failed" is contained # in a message... ;) :msg, contains, "power failed" ^turn-diesel-generator-on # (The script is passed the syslog message as first and only paramter. # Other parameters can currently not be specified.)