[syslog-ng-announce] Critical error in syslog-ng PE version 4 F1

devel devel at balabit.hu
Mon Sep 5 12:54:49 CEST 2011

PACKAGE             : syslog-ng Premium Edition
VERSION             : 4 F1
SUMMARY             : Critical error in syslog-ng PE version 4 F1
DATE                : Sep 5, 2011

A critical error has been found in syslog-ng Premium Edition (PE) version 4
F1 that in certain situations causes the month information for September
to be interpreted as December in legacy-syslog formatted log messages.

This announcement contains important information about an error
that may affect your system logging infrastructure, and describes how to
assess and remedy the situation. Read the entire announcement thoroughly.

You will have to upgrade to the new, corrected version of syslog-ng 4 F1
no later than September 30 to avoid losing information. Performing the
upgrade is recommended as soon as possible.

syslog-ng Premium Edition 4.1.x (4 F1)

The syslog-ng Premium Edition application associates two timestamps with
every incoming log message: the timestamp that is included in the header
of the log message, and the time when syslog-ng actually receives the
log message. The information from the timestamp included in the log
message is available using the "S_"-prefixed macros of syslog-ng (for
example, "$S_DATE"), while the timestamp added when syslog-ng PE received the
log message is available using the "R_"-prefixed macros. Macros without
prefix (for example, "$DATE") are equivalent with the "S_"-prefixed macros.

Because of an error, the month information from September to December
will be interpreted as December in the timestamp of messages received by
syslog-ng Premium Edition 4 F1. This causes the month information in the
log messages and date-related macros to be incorrect.
Since the macro values are affected as well, filenames, pathnames, and
the names of database tables that have date-related macros in their names
will be misnamed as well.

For example, if a destination uses the "$YEAR/$MONTH/$DAY/$HOST.log"
filename template for log files, then the logs of the recent days
(that is, September 1-5) are incorrectly stored under the
"2011/12/$DAY/$HOST.log" directory instead of
"2011/09/$DAY/$HOST.log", and the timestamp of the stored log
messages contains December instead of September.

Your configuration is affected if the following is true:
     - You are using syslog-ng PE 4 F1, and:
     - At least one log source is define that uses the legacy-syslog
       (also called RFC3164, or BSD-syslog) message format. Such sources
       include, but are not limited to network sources (for example, the
       tcp() or udp() driver), sockets (for example, unix-stream()),
       and file or pipe sources. A source is not affected if the
       "flags(syslog-protocol)" option is set for the source.
     - At least one date-related macro that is not prefixed with "R_" is
       used in a filename, database table name, or other template.

Your configuration is NOT affected, if the following is true:
     - the "keep_timestamp(no)" global option is set, or
     - the "keep_timestamp(no)" option is set individually for every source, or
     - you use custom templates for every destination that explicitly use
       the "R_"-version of the date-related macros.

BalaBit will provide new, corrected syslog-ng PE 4 F1 packages by Tuesday,
September 6.
If you are using syslog-ng Premium Edition 4 F1 in a production environment
and your configuration is affected, please contact the BalaBit Support
Team at http://www.balabit.com/boss/ to help assess and remedy the situation.
The complete solution involves upgrading to the new, corrected version of
syslog-ng PE 4 F1, and correcting the problems resulting from the error
(for example, renaming misnamed files).

You will have to upgrade to the new, corrected version of syslog-ng 4 F1
no later than September 30 to avoid losing information.
Starting with October 1, uncorrected versions of 4 F1 will log the new
log messages as messages from December, possibly mixing or overwriting the
log files or database tables of September.

To have syslog-ng process the timestamps correctly until you upgrade to
the corrected packages, use the timestamp when the messages are received.
Note that in this case the information about when the log message was sent
is irrevocably lost.
To accomplish this, set the "keep_timestamp()" option to "no", either
globally, or locally for the affected sources.
Alternatively, replace the date-related macros (for example, $DATE, $ISODATE,
$S_MONTH, and so on) used in your configuration with their "R_"-prefixed
versions to use the received date of the log message.

Depending on your environment, certain further steps might be needed to
resolve the results of the issue. For example:
     - Backups and archives of the log files must be reviewed if log files
       of the affected period (September 1-5) have already been archived
       or backed up.
     - If you forward the log messages from syslog-ng Premium Edition to
       a SIEM or log analyzing application or device, the incorrect dates
       might appear in the SIEM reports as well, and might also affect the
       monthly statistics of the log messages.
     - Misnamed database tables, and the contents of database columns
       containing date-related information might have to be corrected.

  Kind Regards and Sincere Apologies,

  BalaBit IT Security

More information about the syslog-ng-announce mailing list