Archive for July, 2011
It seems that the BalaBit syslog-ng team that produces the Premium Edition of syslog-ng has beaten the community project this time, at least in terms of release date.
syslog-ng Premium Edition 4F1 (e.g. the first feature release past 4.0) has been released this week. It is the first release of PE in a long time that is actually based on an actual OSE core, namely 3.3.
I still have about 100 patches to review and integrate into OSE, hopedully with community involvement. But more about that in an upcoming post.
It is also interesting that some performanc testing was also done, and the new core does pretty well, and scales nicely on an 8 core machine, up to 800k msg/sec in @some onfigurations. Here’s the post the has some more details.
Now, if only the fixes they did were integrated properly to the OSE repository. but hey, life would be easy without challenges.
There’s an ongoing debate on the Linux Kernel Mailing List, whether security issues need separate attention. While I agree that distributing available information on security relevance is a good thing, I can also understand the concerns about the “security circus”. Being the finder of a security bug has value in one’s reputation, and building that reputation is a priority for some. Positioning mere bugs as security problems is quite simple: any crash-bug can easily become ‘Denial of Service’.
Certainly, crashes in a piece of the critical infrastructure is a severe problem, and addressing those bugs is important, but pinpointing a single case over the other ones withdraws energy from other, perhaps more important efforts.
syslog-ng had a bug in its PCRE support code: whenever the PCRE engine returned an error code when performing a match on a global (/g) pattern, it entered into an infinite loop, eating up memory and CPU cycles until memory runs out or it gets killed. It is important to note that at this point the regular expression is already compiled, so triggering this condition is not as easy as specifying an incorrect regular expression in the syslog-ng configuration file.
But anyway, mishandling error returns is bad, especially as starting with PCRE version 8.12 always returns an error because of the bug in the glue code. This new version is popping up in various distros, and was the first hint to find this bug.
This means, that you always get the infinite loop with a recent PCRE version in case you have a subst() rewrite rule in global mode and there comes a message which does not match. I’d translate this as the most obvious case when testing one’s deployment.
And quite possibly this bug is never triggered in any other cases.
Is this bug serious? Well, for those affected this can certainly cause some trouble. Is it worth fixing? Of course. Is it a security problem on a production system, with a stable software and configuration environment? Well, doubtful.
But still, syslog-ng is being patched with feverish pace in distros, and probably by users with custom compiled packages. This effort could perhaps be used to test and provide feedback on the syslog-ng version in development: 3.3.