Security Advisories

librelp stack buffer overflow vulnerability (CVE-2018-1000140)

On Monday March 19th, 2018, the librelp development team was informed by the security team at lgtm.com (Semmle) about a critical security vulnerability in librelp. The vulnerability is a long-standing bug that exists since version 1.1.1 (2013-06-11). It affects the client certificate validation in TLS mode which can lead to a stack buffer overrun and thus remote code execution.

Users of librelp are strongly advised to upgrade their packages as a matter of urgency.

Affected packages and versions

  • librelp 1.2.14 down to 1.1.1

Disclosure process

The security team followed best practices when they notified the librelp development team, who subsequently validated their claim. As agreed, one of the researchers applied for a CVE but unfortunately made a mistake in the afternoon of March 20th, which lead to high-level information about the vulnerability becoming public via the Distributed Weakness Filing Project [1].


We have to assume that the vulnerability became publicly known at that point. The librelp team finalized a patch [2] on March 20th, and a new release of librelp was released on March, 21st. It is available in both source and binary form from the project’s package repository. Note that the patch commit message is intentionally vague so as not to attract additional attention while details of the vulnerability were being disclosed.

The vulnerability

The vulnerability is caused by a call to snprintf on line 1205 of tcp.c [3].

This coding pattern is dangerous, because snprintf returns the number of bytes that it would have written if the buffer had been big enough. Most notably, that number is not necessarily equal to the number of bytes that it actually wrote. It is a common mistake to assume that snprintf returns the number of bytes written. In certain situations and if the data provided to snprintf is controlled by an attacker, this can lead to a stack overflow and the potential to remotely execute code. The code analysis provided by lgtm.com detects potentially dangerous uses of snprintf in open source projects: https://lgtm.com/rules/1505913226124/

Unfortunately, librelp is indeed vulnerable. In order to exploit this vulnerability, an attacker needs to be able to connect to a TLS-enabled RELP logging interface provided by librelp (for example, as can be provided by rsyslog). The attacker then needs to supply an X.509 certificate containing more than 32KB of “subject alt names”. One of these strings needs to overlap the 32KB boundary. For example, if one of the strings starts 10 bytes before the end of the 32KB buffer but is 100 bytes long, then the loop in librelp’s tcp.c will write the first 10 bytes of the string to the buffer but still increment iAllNames by 100. On the next iteration of the loop, the next string will be written at a starting offset of 32KB + 90. An attacker can control the size of this “gap” by varying the length of the overlapping string and utilize it to control exactly which part of the stack they want to overwrite. In particular, this means that they can avoid overwriting the stack canary, which makes the vulnerability significantly easier to exploit.

The teams at librelp and lgtm.com have not yet released a proof-of-concept exploit for this vulnerability.

Severity and mitigation

In the opinion of the librelp/rsyslog development team:

  1. the vulnerability is unquestionably critical as it could lead to RCE
  2. depending on GnuTLS, it may be hard to actually exploit the vulnerability
  3. the severity is mitigated if security recommendations are followed

The use of GnuTLS

librelp uses GnuTLS for handling TLS connections. GnuTLS’s behaviour and handling of overly large fields therefore influences this vulnerability in librelp.

The maximum size of the name fields in question is specified in RFC5280 as follows:

Section 4.1:

SubjectAltName ::= GeneralNames
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

 

Appendix B imposes the following “restriction”:

The construct “SEQUENCE SIZE (1..MAX) OF” appears in several ASN.1 constructs.  A valid ASN.1 sequence will have zero or more entries. The SIZE (1..MAX) construct constrains the sequence to have at least one entry.  MAX indicates that the upper bound is unspecified.
Implementations are free to choose an upper bound that suits their environment.

As such, much depends on the actual GnuTLS binary that is linked to librelp. If it imposes a limit of 32KB (or less), the vulnerability cannot be exploited. We are currently trying to understand the default behavior of GnuTLS in this regard and will update this advisory when we receive new information.

RFC5280 Sect. 4.2.1.6 imposes restrictions on which characters can be used inside the “subject alternative name”. Brief review indicates that some byte sequences are not permitted. If so, and if GnuTLS implements these validations, the ability of an attacker to inject arbitrary code is reduced, making it harder to craft a workable exploit.

Nevertheless, it should be assumed that GnuTLS does not provide any safeguards. Even if there are, and if those safeguards are enabled  by default, we have to consider the possibility of any checks being disabled in a specific binary.

Trusted networks

Regarding the mitigation of the severity of this vulnerability: users are strongly advised not to expose logging port like syslog TCP and RELP to a public network; these ports are best firewalled to make them available only on a dedicated network. If that advice is followed, the risk is significantly reduced to already-compromised systems on a trusted network.

However, some logs-as-a-service providers do expose RELP on the public Internet. The rsyslog team has been in touch with and/or reviewed documentation for leading providers. Those we checked either do not expose RELP at all or do not support TLS with RELP, and are therefore not at risk.

Credit

  • Bas van Schaik; lgtm.com / Semmle
  • Kevin Backhouse; lgtm.com / Semmle

References

[1] https://docs.google.com/spreadsheets/d/1PlDOsZ4Q36JU4Dz9zyBB2F3814dScppCRCe1muCT7JI
[2] https://github.com/rsyslog/librelp/commit/2cfe657672636aa5d7d2a14cfcb0a6ab9d1f00cf
[3] Affected line in tcp.c (ibrelp version 1.2.14): https://github.com/rsyslog/librelp/blob/532aa362f0f7a8d037505b0a27a1df452f9bac9e/src/tcp.c#L1205

 

 

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.

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

===============================

CVE: CVE-2014-3634

Status of this report
———————
FINAL

Reporter
——-
Rainer Gerhards, rsyslog project lead

Affected
——–
– rsyslog, most probably all versions (checked 5.8.6+)
– sysklogd (checked most recent versions)
– potentially others (see root cause)

Root Cause
———-
Note: rsyslogd was forked from sysklogd, and the root cause applies to
both. For simplicity, here I use sysklogd as this is the base code.

The system header file /usr/include/*/syslog.h contains the following definitions

#define    LOG_NFACILITIES    24    /* current number of facilities */
#define    LOG_FACMASK    0x03f8    /* mask to extract facility part */
/* facility of pri */
#define    LOG_FAC(p)    (((p) & LOG_FACMASK) >> 3)

[This is from Ubuntu 12.04LTS, but can be found similarly in most, if
not all, distributions].

The define LOG_NFACILITIES is used by sysklogd to size arrays for facility
processing. In sysklogd, an array for selector matching is using this. Rsyslog
has additional array. The macro LOG_FAC() is used to extract the facility from
a syslog PRI [RFC3164, RFC 5424]. Its result is used to address the arrays.
Unfortunately, the LOG_FACMASK permits PRI values up to 0x3f8 (1016 dec). This
translates to 128 facilities. Consequently, for PRI values above 191 the
LOG_NFACILITIES arrays are overrun.

Other applications may have similar problems, as LOG_NFACILITES “sounds” like
the max value that LOG_FAC() can return. It would probably make sense to
check why there is a difference between LOG_NFACILITES and LOG_FACMASK, and
if this really needs to stay. A proper fix would probably be to make LOG_FAC
return a valid (maybe special) facility if an invalid one is provided. This
is the route taken in rsyslog patches.

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
~~~~~~~~
Sysklogd is mildly affected. Having a quick look at the current git master
branch, the wrong action may be applied to messages with invalid facility.

A segfault seems unlikely, as the maximum misadressing is 104 bytes of the
f_pmask table, which is always within properly allocated memory (albeit to
wrong data items). This can lead to triggering invalid selector lines and
thus wrongly writing to files or wrongly forwarding to other hosts.

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

However, more severe effects can occur, BUT NOT WITH THE DEFAULT CONFIGURATION.
The most likely and thus important attack is a remote DoS. Some
of the additional tables are writable and can cause considerable misadressing.
This is especially true for versions 7 and 8. In those versions, remote code
injection may also be possible by a carefully crafted package. It sounds hard
to do, but it cannot be totally outruled [we did not check this in depth].

A segfault (and thus Dos) has the following preconditions:
– the rsyslog property “pri-text” must be used, either in
* templates
* conditional statements (RainerScript and property-based filters)
– the property must actually be accessed
With traditional selector lines, this depends on the facility causing
a misadressing that leads to reading a 1 from the misaccessed location.

When the preconditions are met, misadressing happens. The code uses a string
table and a table of string lengths. Depending on memory layout at time of
misadressing and depending on the actual invalid PRI value, the lookup to
the string table can lead to a much to long length, which is the used in
buffer copy calculations. High PRI values close to the max of 1016 potentially
cause most problems, but we have also seen segfaults with very low invalid
PRI values.

Note that, as usual in such situations, a segfault may not happen immediately.
Instad some data structures may be damaged (e.g. from the memory allocator)
which will later on result in a segfault.

In v5 and below, a segfault is very unlikely, as snprintf() is used to generate
the pri-text property. As such, no write overrun can happen (but still garbagge
be contained inside the property). A segfault could theoretically happen if the
name lookup table indices cause out-of-process misadressing. We could not manage
to produce a segfault with v5.

Versions 7.6.3 and 7.6.4 already have partial fixes for the issue and will not
be vulnerable to a segfault (but the mild other issues described).

All other versions 7 and 8 are vulnerable. Version 6 was not checked as it seems
no longer be used in practice (it was an interim version). No patch for version 6
will be provided.

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 an invalid PRI value needs to be sent. It is sufficient
to send just the PRI as in this example

“<201>”

Any message starting with “<PRI>” where PRI is an integer greater than 191
can trigger the problem. The maximum offset that can be generated is with
PRI equal to 1016, as this is the modulus used due to LOG_FACMASK.

Note that messages with
– PRI > 191  and
– PRI modulus 1016 <= 191
will not lead to misadressing but go into the wrong bin.

Messsages with
– PRI > 191
– PRI modulus 1016 > 191
will go into the wrong bin and lead to misadressing.

Severity
——–
Given the triggering scenarios, 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 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.

This vulnerability is at least not publicly know. Based on (no) bug reports, it
seems unlikely that it is being exploited, but that’s obviously hard to know for
sure.

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

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

New patches for the article available http://www.rsyslog.com/remote-syslog-pri-vulnerability-cve-2014-3683/

Potential DoS with malformed TAG

If a malformed, severely too long TAG is used in legacy (RFC3164) syslog messages, rsyslog can abort based on the conditions described in this security advisory.

CVE: CVE-2011-3200

Affected Stable Versions:
v4.6.0 to 4.6.7 (inclusive)
v5.2.0 to 5.8.4 (inclusive)

Devel and Beta versions are probably also affected, but are not suitable for production and thus not analyzed in detail. Version 3 is not affeceted. Versions prior to 3 have not been analyzed.

Fix:
Update to 4.6.8 or 5.8.5.  The fix is also included in the following non-beta versions: 4.7.5, 5.9.3, 6.1.12, 6.3.5.
For non current affected versions, the following patches can most probably be applied: v4, v5. Note that due to the myriad of different versions we can not provide individual patches for all outdated versions (and in general it is less secure to run outdated versions).

Short Description:
An excessively long TAG inside a legacy syslog message can lead to a two-byte stack buffer overflow. If rsyslog has been compiled with stack guard, this can lead to an abort. This has been seen on 32bit platforms, but not on 64 bit ones (though not outruled there). If not compiled with stack guard, no fatal problem occurs and the tag character is usually just truncated. Exact behaviour depends on the platform and may be slightly different on compilers different from gcc and/or non-Intel architecture machines.

Continue reading “Potential DoS with malformed TAG”

$AllowedSender not honored

A primitive way of access control is offered in rsyslog via the $AllowedSender configuration directive. It permits the operator to specify hosts from which messages are being accepted. If the directive is not specified, messages from all hosts are accepted. If it is, the set is limited to those senders that match the configured criteria (this can be network addresses or host name). Access control can be configured for UDP- based and TCP-based protocols independently.

Note that this directive may be used to simplify firewall setup, where the firewall permits incoming traffic from all remote machines on the port in question. Then rsyslog ACLs are used to control who is actually permitted. The down-side of this approach is that the packets reach rsyslog and any vulnerability in it can be exploited. Please note that UDP addresses can easily be spoofed (though thankfully not as easy any longer on the public Internet thanks to more careful configuration on most ISP’s side). So an IP-based access control does not work very well for UDP (neither at the firewall nor at the rsyslog level – but the firewall may have more options at hand, given its comparatively broad knowledge of the perimeter). Continue reading “$AllowedSender not honored”

SQL Injection Vulnerability in rsyslogd

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 potentially 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 potentially be used to take full ownership of the computer a compromised rsyslog is running on. The extend of the compromise is depending on the permissions of the user used to connect to MySQL.

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. Continue reading “SQL Injection Vulnerability in rsyslogd”

Scroll to top