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