From patchwork Wed May 17 23:44:46 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Siddhesh Poyarekar X-Patchwork-Id: 69563 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DDF8F3857735 for ; Wed, 17 May 2023 23:45:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DDF8F3857735 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1684367116; bh=MyX7D1sXyn4Cqrl2Xn8J/G8bQY4BECEyMD2HbIxDCl0=; h=To:Cc:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=sReORdSHT5nwwTF3KF0QqL6URMMbYJLZkfG4F+dLYdol4z97ZFu8eW9APdRdvNbNj G8gsewYHaxBlXk/lIssUz980NF3wbor1B8eq0HSZPEsIOCT2VL6YpUsSw6L/vBsncl xD5OXwjv1v+QfonWhkTaNTl6c64OQ6M6VrtlrbLc= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from bird.elm.relay.mailchannels.net (bird.elm.relay.mailchannels.net [23.83.212.17]) by sourceware.org (Postfix) with ESMTPS id B97343858C5F for ; Wed, 17 May 2023 23:44:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B97343858C5F X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 7D818141422; Wed, 17 May 2023 23:44:50 +0000 (UTC) Received: from pdx1-sub0-mail-a305.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 20BAA1417BB; Wed, 17 May 2023 23:44:50 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1684367090; a=rsa-sha256; cv=none; b=YkRq92a3Mf22Bojp9tUj3szglfrZNTNlj1ZM78L2aKO4M5GIc8NjY/I2Y7xWo07h20O34+ /iY5MtDapO3pErE92w3p8DZGq+AYYyz4PmaTFOkWRvmRFnrv4ulYa40FrqaVgMIc8CkW7x GQJnUSffPdVK9DkHVvdSruzp6eevkQTrP+bXe0BzY95MSqAiXbiEnPiYIr2TdPRbqUiD6D oMFGcJkLgHTBKUmBXtu9FJ3RPIlpS2VUiYnPOOFEPBdOSgUQ4nueC/sHg1BnG+XpO029rk az8fiyXH+UrPv/96MxiVgsIrlF062UDPySO8iFwRemS+BW3wOiepQj5QxR0ZaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1684367090; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=MyX7D1sXyn4Cqrl2Xn8J/G8bQY4BECEyMD2HbIxDCl0=; b=YFlJMbzIfrAN9fUKCCYoWWt/5moGxoI/kBq6md5iLNZVRiOLeFI0yVCMotpovtbjlqHIcK eZTLBqo//urxHcmrZ0qBBIauVgwStlVecYL4/Na+iRkU9fuTyKaxfrbpoVgQmwBB+nN6sm 7Hms5NL6SsaVMswUpqk01ieUuHBK7kuAqr5lScJNQLrLBhGWM5eWtCucAUAd7hEXcNZV08 Fy3gZIKbA0emswelHN9Yg2b+zFzQ+dp1iALV5aEe0dNFPI1xLpNuUnWr0pEjQIcCPNrwM/ FAWIqeyl3U7mmg4lo2jPekqFh/KaAfQv/NaCkW87J0m4Jryx4D1R+3bvPoBT3g== ARC-Authentication-Results: i=1; rspamd-5cdf8fd7d9-fw8rh; auth=pass smtp.auth=dreamhost smtp.mailfrom=siddhesh@sourceware.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org X-MC-Relay: Neutral X-MC-Copy: stored-urls X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Unite-Chief: 0a82d43736f43a1a_1684367090368_2905257258 X-MC-Loop-Signature: 1684367090368:796483942 X-MC-Ingress-Time: 1684367090368 Received: from pdx1-sub0-mail-a305.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.103.24.74 (trex/6.8.1); Wed, 17 May 2023 23:44:50 +0000 Received: from fedora.. (bras-vprn-toroon4834w-lp130-02-142-113-138-85.dsl.bell.ca [142.113.138.85]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a305.dreamhost.com (Postfix) with ESMTPSA id 4QM8pn4pQPzQf; Wed, 17 May 2023 16:44:49 -0700 (PDT) To: libc-alpha@sourceware.org Cc: carlos@redhat.com Subject: [PATCH] Add a SECURITY.md Date: Wed, 17 May 2023 19:44:46 -0400 Message-Id: <20230517234446.2408459-1-siddhesh@sourceware.org> X-Mailer: git-send-email 2.40.1 MIME-Version: 1.0 X-Spam-Status: No, score=-1168.7 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_NONE, KAM_DMARC_STATUS, MEDICAL_SUBJECT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_SOFTFAIL, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Siddhesh Poyarekar via Libc-alpha From: Siddhesh Poyarekar Reply-To: Siddhesh Poyarekar Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" Move content from the Security Process[1] and Security Exceptions[2] wiki documents into the repository so that it is in a standard place for analysis tools to look for the glibc security policy. This is a more or less verbatim port of the wiki document with some restructuring for a more coherent layout since the two pages are now merged. There should be no change in messaging in this commit. Signed-off-by: Siddhesh Poyarekar Reviewed-by: Carlos O'Donell --- For a preview of what the markdown might look like when rendered, I have posted the change on github: https://github.com/siddhesh/glibc/blob/securitymd/SECURITY.md SECURITY.md | 209 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 209 insertions(+) create mode 100644 SECURITY.md diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000000..a5f679f69b --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,209 @@ +# The GNU C Library Security Process + +This document describes the process followed by the GNU C Library maintainers +to handle bugs that may have a security impact. This includes determining if a +bug has a security impact, reporting such bugs to the community and handling +such bugs all the way to resolution. This process may evolve over time, so if +you're reading this from a release tarball, be sure to check the latest copy of +the [SECURITY.md in the +repository](https://sourceware.org/git/?p=glibc.git;a=blob;f=SECURITY.md), +especially for instructions on reporting issues privately. + +## What is a security bug? + +Most security vulnerabilities in the GNU C Library materialize only after an +application uses functionality in a specific way. Therefore, it is sometimes +difficult to determine if a defect in the GNU C Library constitutes a +vulnerability as such. The follow guidelines can help with a decision. + +* Buffer overflows should be treated as security bugs if it is conceivable that + the data triggering them can come from an untrusted source. +* Other bugs that cause memory corruption which is likely exploitable should be + treated as security bugs. +* Information disclosure can be security bugs, especially if exposure through + applications can be determined. +* Memory leaks and races are security bugs if they cause service breakage. +* Stack overflow through unbounded alloca calls or variable-length arrays are + security bugs if it is conceivable that the data triggering the overflow + could come from an untrusted source. +* Stack overflow through deep recursion and other crashes are security bugs if + they cause service breakage. +* Bugs that cripple the whole system (so that it doesn't even boot or does not + run most applications) are not security bugs because they will not be + exploitable in practice, due to general system instability. +* Bugs that crash `nscd` are generally security bugs, except if they can only + be triggered by a trusted data source (DNS is not trusted, but NIS and LDAP + probably are). +* The [Security Exceptions](#SecurityExceptions) section below describes + subsystems for which determining the security status of bugs is especially + complicated. +* For consistency, if the bug has received a CVE name attributing it to the GNU + C library, it should be flagged `security+`. +* Duplicates of security bugs (flagged with `security+`) should be flagged + `security-`, to avoid cluttering the reporting. + +In this context, _service breakage_ means client-side privilege escalation +(code execution) or server-side denial of service or privilege escalation +through actual, concrete, non-synthetic applications. Or put differently, if +the GNU C Library causes a security bug in an application (and the application +uses the library in a standard-conforming manner or according to the manual), +the GNU C Library bug should be treated as security-relevant. + +### Security Exceptions + +It may be especially complicated to determine the security status of bugs in +some subsystems in the GNU C Library. This subsection describes such +subsystems and the special considerations applicable during security bug +classification in them. + +#### Regular expression processing + +Regular expression processing comes in two parts, compilation (through regcomp) +and execution (through regexec). + +Implementing regular expressions efficiently, in a standard-conforming way, and +without denial-of-service vulnerabilities is very difficult and impossible for +Basic Regular Expressions. Most implementation strategies have issues dealing +with certain classes of patterns. + +Consequently, certain issues which can be triggered only with crafted patterns +(either during compilation or execution) are treated as regular bugs and not +security issues. Examples of such issues would include (but is not limited +to): + + * Running out of memory through valid use of malloc + * Quadratic or exponential behaviour resulting in slow execution time + * Stack overflows due to recursion when processing patterns + +Crashes, infinite loops (and not merely exponential behavior), buffer overflows +and overreads, memory leaks and other bugs resulting from the regex +implementation relying on undefined behavior should be treated as security +vulnerabilities. + +#### wordexp patterns + +`wordexp` inherently has exponential memory consumption in terms of the input +size. This means that denial of service flaws from crafted patterns are not +security issues (even if they lead to other issues, such as NULL pointer +dereferences). + +#### Asynchronous I/O + +The GNU C Library tries to implement asynchronous I/O without kernel support, +which means that several operations are not fully standard conforming. Several +known races can cause crashes and resource leaks. Such bugs are only treated +as security bugs if applications (as opposed to synthetic test cases) have +security exposures due to these bugs. + +#### Asynchronous cancellation + +The implementation of asynchronous cancellation is not fully +standard-conforming and has races and leaks. Again, such bugs are only treated +as security bugs if applications (as opposed to synthetic test cases) have +security exposures due to these bugs. + +#### Crafted binaries and ldd + +The `ldd` tool is not expected to be used with untrusted executables. + +#### Post-exploitation countermeasures + +Certain features have been added to the library only to make exploitation of +security bugs (mainly for code execution) more difficult. Examples includes +the stack smashing protector, function pointer obfuscation, vtable validation +for stdio stream handles, and various heap consistency checks. Failure of such +countermeasures to stop exploitation of a different vulnerability is not a +security vulnerability in itself. By their nature, these countermeasures are +based on heuristics and will never offer complete protection, so the original +vulnerability needs to be fixed anyway. + +## Reporting private security bugs + +**IMPORTANT: All bugs reported in Bugzilla are public.** + +As a rule of thumb, security vulnerabilities which are exposed over the network +or can be used for local privilege escalation (through existing applications, +not synthetic test cases) should be reported privately. We expect that such +critical security bugs are rare, and that most security bugs can be reported in +Bugzilla, thus making them public immediately. If in doubt, you can file a +private bug, as explained in the next paragraph. + +If you want to report a _private_ security bug that is not immediately +public, please contact _one_ of our downstream distributions with security +teams. The follow teams have volunteered to handle such bugs: + +* Debian: security@debian.org +* Red Hat: secalert@redhat.com +* SUSE: security@suse.de + +Please report the bug to _just one_ of these teams. It will be shared with +other teams as necessary. + +The team you contacted will take care of details such as vulnerability rating +and [CVE assignment](http://cve.mitre.org/about/). It is likely that the team +will ask to file a public bug because the issue is sufficiently minor and does +not warrant an embargo. An embargo is not a requirement for being credited +with the discovery of a security vulnerability. + +## Reporting public security bugs + +We expect that critical security bugs are rare, and that most security bugs can +be reported in Bugzilla, thus making them public immediately. When reporting +public security bugs the reporter should provide rationale for their choice of +public disclosure. + +## Triaging security bugs + +This section is aimed at developers, not reporters. + +Security-relevant bugs should be marked with `security+`, as per the [Bugzilla +security flag +documentation](https://sourceware.org/glibc/wiki/Bugzilla%20Procedures#security), +following the guidelines above. If you set the `security+` flag, you should +make sure the following information is included in the bug (usually in a bug +comment): + +* The first glibc version which includes the vulnerable code. If the + vulnerability was introduced before glibc 2.4 (released in 2006), this + information is not necessary. +* The commit or commits (identified by hash) that fix this vulnerability in the + master branch, and (for historic security bugs) the first release that + includes this fix. +* The summary should include the CVE names (if any), in parentheses at the end. +* If there is a single CVE name assigned to this bug, it should be set as an + alias. + +The following links are helpful for finding untriaged bugs: + +* [Unprocessed bugs](https://sourceware.org/bugzilla/buglist.cgi?f1=flagtypes.name&o1=notsubstring&product=glibc&query_format=advanced&v1=security) +* [`security?` review requests](https://sourceware.org/bugzilla/buglist.cgi?f1=flagtypes.name&o1=substring&product=glibc&query_format=advanced&v1=security%3f) +* [Open `security+` bugs](https://sourceware.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&bug_status=VERIFIED&f1=flagtypes.name&o1=substring&product=glibc&query_format=advanced&v1=security%2B) + +## Fixing security bugs + +For changes to master, the regular [consensus-driven +process](https://sourceware.org/glibc/wiki/Consensus) must be followed. It +makes sense to obtain consensus in private, to ensure that the patch is likely +in a committable state, before disclosing an emboargoed vulnerability. + +Security backports to release branches need to follow the +[release process](https://sourceware.org/glibc/wiki/Release#General_policy). + +Contact the [website +maintainers](https://sourceware.org/glibc/wiki/MAINTAINERS#Maintainers_for_the_website) +and have them draft a news entry for the website frontpage to direct users to +the bug, the fix, or the mailing list discussions. + +## CVE assignment + +Security bugs flagged with `security+` should have [CVE identifiers](http://cve.mitre.org/about/). + +For bugs which are public (thus all bugs in Bugzilla), CVE assignment has to +happen through the [oss-security mailing +list](http://oss-security.openwall.org/wiki/mailing-lists/oss-security). +(Downstreams will eventually request CVE assignment through their public +Bugzilla monitoring processes.) + +For initially private security bugs, CVEs will be assigned as needed by the +downstream security teams. Once a public bug is filed, the name should be +included in Bugzilla.