Author : adisconteam

LogAnalyzer: Facility and Severity is missing

Question: I use a logfile of rsyslog as source type in LogAnalyzer, everything is good but the facility and severity information tabs of the messages are missing, like in this screenshot.

Answer: The solution is rather simple, your current file template does not contain syslog priority or facility. Kindly switch to RSYSLOG_SyslogProtocol23Format which is RFC5424 format which contains the required information. You can use the template for a single action or you can use it as the default template. Below you can find a example for both cases:
Please note that this example only apply to a single logfile:

mail.* /var/log/maillog;RSYSLOG_SyslogProtocol23Format

This is the example for a default template:

$ActionFileDefaultTemplate RSYSLOG_SyslogProtocol23Format

Please note that you need to change the logfile type to RSyslog Format23 in your Loganalyzer logstream sources as well. You can do that by editing the “config.php” of LogAnalyzer.
Open the “config.php” with your favourite editor and add the following line to the correct source:

$CFG[‘Sources’][‘Source1’][‘LogLineType’] = “Syslog23”;

Afterwards the configuration should look like this.
Don’t forget to save the changes. Now you can refresh the Webpanel of LogAnalyzer and then you should see the facility and severity missing information tabs, like in this screenshot.

Changelog for 8.8.0 (v8-stable)

Version 8.8.0 [v8-stable] 2015-02-24

  • omkafka: add support for dynamic topics and auto partitioning
    Thanks to Tait Clarridge for the patches.
  • imtcp/imptcp: support for broken Cisco ASA TCP syslog framing
  • omfwd: more detailled error messages in case of UDP send error
  • TLS syslog: enable capability to turn on GnuTLS debug logging
    This provides better diagnostics in hard-to-diagnose cases,
    especially when GnuTLS is extra-picky about certificates.
  • bugfix: $AbortOnUncleanConfig did not work
  • improve rsyslogd -v output and error message with meta information
    version number is now contained in error message and build platform in
    version output. This helps to gets rid of the usual “which version”
    question on mailing list, support forums, etc…
  • bugfix imtcp: octet-counted framing cannot be turned off
  • bugfix: build problems on Illuminos
    Thanks to Andrew Stormont for the patch
  • bugfix: invalid data size for iMaxLine global property
    It was defined as int, but inside the config system it was declared as
    size type, which uses int64_t. With legacy config statements, this could
    lead to misadressing, which usually meant the another config variable was
    overwritten (depending on memory layout).
    closes https://github.com/rsyslog/rsyslog/issues/205
  • bugfix: negative values for maxMessageSize global parameter were permitted

Changelog for 7.6.7 (v7-stable)

Version 7.6.7 [v7.6-stable] 2014-10-02

  • bugfix: the fix for CVE-2014-3634 did not handle all cases
    This is corrected now. See also: CVE-2014-3683
  • fixed a build problem on some platforms
    Thanks to Olaf for the patch
  • behaviour change: “msg” of messages with invalid PRI set to “rawmsg”
    When the PRI is invalid, the rest of the header cannot be valid. So
    we move all of it to MSG and do not try to parse it out. Note that
    this is not directly related to the security issue but rather done
    because it makes most sense.

rsyslog 8.4.2 (v8-stable) released

We have just released 8.4.2 of the v8-stable branch.

This is primarily a re-release of 8.4.2 because the patch for the PRI vulnerability was incomplete. Special thanks to “mancha” for notifying us and helping to get it right.

For more info, please see: http://www.rsyslog.com/remote-syslog-pri-vulnerability-cve-2014-3683/

Packages are also already available in the package archives..

Download: http://www.rsyslog.com/downloads/download-v8-stable/

As always, feedback is appreciated.

Best regards,
Tim Eifler

rsyslog 7.6.7 (v7-stable) released

This is primarily a re-release of 7.6.6 because the patch for the PRI vulnerability was incomplete. Special thanks to “mancha” for notifying us and helping to get it right.

For more info, please see: http://www.rsyslog.com/remote-syslog-pri-vulnerability-cve-2014-3683/

Packages are also already available in the package archives.

ChangeLog:

remote syslog PRI vulnerability – CVE: CVE-2014-3683

remote syslog PRI vulnerability
===============================

CVE: CVE-2014-3683

Status of this report
———————
FINAL
Updated 2014-10-06: effect on sysklogd milder than in initial assesment

Reporter
——-
mancha , intial detection and analysis
Rainer Gerhards , rsyslog project lead

Affected
——–
– rsyslog, most probably all versions (checked v3-stable and above)
– sysklogd (checked most recent versions)

Short Description
—————–
While preparing a fix for CVE-2014-3634 for sysklogd, mancha discovered and
privately reported that the initial rsyslog fix set was incomplete. It did
not cover cases where PRI values > MAX_INT caused integer overflows
resulting in negative values.

Root Cause
———-
A while parsing the syslog message’s PRI value, an integer overlow can
happen (for PRI > MAX_INT), which may cause negative PRI values. The
solutions provided in CVE-2014-3634 do not handle that case.

Effect in Practice
——————

General
~~~~~~~
Almost all distributions do ship rsyslog without remote reception by
default and almost all distros also put firewall rules into place that
prevent reception of syslog messages from remote hosts (even if rsyslog
would be listening). With these defaults, it is impossible to trigger
the vulnerability in v7 and v8. Older versions may still be vulnerable
if a malicious user writes to the local log socket.

Even when configured to receive remote message (on a central server),
it is good practice to protect such syslog servers to accept only
messages from trusted peers, e.g. within the relay chain. If setup in
such a way, a trusted peer must be compromised to send malfromed
messages. This further limits the magnitude of the vulnerability.

If, however, any system is permitted to send data unconditionally to
the syslogd, a remote attack is possible.

sysklogd
~~~~~~~~

This causes no extra problems as CVE-2014-3634 because negative
PRI values are masked off, so the overflow region is still at a
maximum of 104 bytes. For more detailsm see CVE-2014-3634.

rsyslogd
~~~~~~~~
Rsyslogd experiences the same problem as sysklogd.

As in CVE-2014-3634, rsyslog v7 and v8 have an elevated risk due to some
tables lookups used during writing. For details see CVE2014-3634.
Contrary to CVE-2014-3634, rsyslog v5 is also likely to segfault, if
and only if the patch for CVE-2014-3634 is applied.

Note that a segfault of rsyslog can cause message loss. There are multiple
scenarios for this, but likely ones are:

– reception via UDP, where all messages arriving during downtime are lost
– corruption of disk queue structures, which can lead to loss of all disk
queue contents (manual recovery is possible).

This list does not try to be complete. Note that disk queue corruption is likely
to occur in default settings, because the important queue information file (.qi)
is only written on successful shutdown. Without a valid .qi file, queue message
files cannot be processed.

How to Exploit
————–
A syslog message with a PRI > MAX_INT needs to be sent and the resulting
overflow must lead to a negative value. It is usually sufficient
to send just the PRI as in this example

“<3500000000>”

Severity
——–
Given the fact that multiple changes must be made to default system configurations
and potential problems we classify the severity of this vulnerability as

MEDIUM

Note that the probability of a successful attack is on LOW. However, the risk of
message loss is HIGH in those rare instances where an attack is successful. As
mentioned above, it cannot totally be outruled that remote code injection is
possible using this vulnerability.

Patches
——-

sysklogd
~~~~~~~~
A patch for version 1.5 is available at:
http://sf.net/projects/mancha/files/sec/sysklogd-1.5_CVE-2014-3634.diff

rsyslog
~~~~~~~
Patches are available for versions known to be in wide-spread use.

Version 8.4.2 is not vulnerable. Version 7.6.7, while no longer being project
supported, received a patch and is also not vulnerable.

Versions 8.4.1 and 7.6.6 do NOT handle integer overflows and resulting negative
PRI values correctly. So upgrading to them is NOT a sufficient solution. All
older v7 and v8 versions are vulnerable.

The rsyslog project also provides patches for older versions 5 and 3. This is
purely a convenience to those that still run these very outdated versions.
Note that these patches address the segfault issue. They do NOT offer all features
of the v7/8 series, as this would require considerate code changes. Most
importantly, the “invld” facility is not available in the v3 patch. Also,
the dead-version patches do not try to assing a specific severity to messages
with invalid PRI values nor do they prevent parsing those messages. In general,
it is suggested to upgrade to the currently supported version 8.4.2.

All patches and downloads can be found on http://www.rsyslog.com

Special thanks to mancha for his suggestions on how to fix the problem. The
core idea went into the rsyslog patches.

Scroll to top