Bazsi's blog

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.