-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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: the vulnerability is unquestionably critical as it could lead to RCE depending on GnuTLS, it may be hard to actually exploit the vulnerability 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/532aa362f0f7/src/tcp.c#L1205 -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJauSJ6AAoJEAy2sqi+gLSZBbIQAIde/I9qDN/n9zGAS8tbRMS4 ibgQFI6hT5RtHY8dx+K1EyKScDV1DsJcT5MYxV+GeubcxN29Gdywk8tudwamNOH+ 5VRmAt/UhS/poC+cM4uJ0ECSbZM4dsQLwPrf+qDAj8MgDF8Id8uGxOE93TkJGP9T M3ZFiaWAfJFLnOAavivy4uZ6Lh++YEfda+wbqOiIUPXvj9FgCwKIQUbuptSBuMKy hKD2G/uq1wACK7V4FXydji9pZ7h8Qa+vYHK+SJg6HL6l5teVHMFHK+f4Ngy9CYA5 XvCw9gIqKaaMRez0q5Exs1SJxkvRHPjL25gJRMF4yHCfbZjVr0iLeAsqXca2NszO TTQF17b+6qlq5F7krq4s8ylv8yeGuK9eUAHVWWQgnmPBal3Gdv3T/Ge2DgrLn6sg 3I+3vTP8ZVWLMSDE5d1CcbeAIYxMjEhUMzjSvRtsaypn+5DylkOPBBBtKmuPle4K 2iQlYsxnU/nFPcWI7K8K5b+JGoAdCWGZvLJjGLklgAyTBj0FfwQkP0aNw64230Wc 0Fqp1WedIVSUMfGPtIrL7dqqUSClBJHXpgqXsCcjPGusaxsMrUkY8cr9/vC9wUAH KQbo3nOOnIFa7VBJSXpvHC94rn740FkQ+BThUhyUrVoq9wfMQak1e7dpPfaj3WB1 rkEEv0xrHUWjoSzx4ZFz =xsEq -----END PGP SIGNATURE----- _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
