From patchwork Wed Sep 20 11:50:43 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Siddhesh Poyarekar X-Patchwork-Id: 142370 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:172:b0:3f2:4152:657d with SMTP id h50csp4074058vqi; Wed, 20 Sep 2023 04:51:30 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFmvto8e6nkNpqghOMngoDJkVI65dF3Rh/RfFGgPJXOr5wlOxSgPnj26+aHmlxAI7JSXQAu X-Received: by 2002:a17:906:30c5:b0:9ad:e20f:142f with SMTP id b5-20020a17090630c500b009ade20f142fmr1870357ejb.22.1695210690569; Wed, 20 Sep 2023 04:51:30 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1695210690; cv=pass; d=google.com; s=arc-20160816; b=oHboH8cr3bFg+4XwGPJ9QCGjbT0Sjfm5iD9peGb/5ha4aVAcB4XAB6DmWyPr5dwm9f XpNHd8gUQEYJJKceEIe+fTTLEREu/qbJQpzLGEvEG+soSh9KXlvuKUJEMTuR2vIOWYZv 1hs+Pl5A/1zTkIHLmbODc3hPTUqTDfhPZg0mVBufPOOwg4zznkAUoOoeyRlAHs7L7+EG h2Wq3gFOjkrJ5LD1mFGPGXa1GoORNzCoyXD50N3LCCPs+Y5PIMGErlms9Rzl09bU8w2t ohEQ9rIXrioTxY5f+GzArj+F5+TvYgHbtvNBAjTvK/5kMxz2ReH0Q4lIjw3OO/aBGFCv 4O/w== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=errors-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:content-transfer-encoding :mime-version:message-id:date:subject:cc:to:from:dkim-signature :dmarc-filter:delivered-to; bh=XVSVXmLwaNpEDUbN3F6hsfp6JVRSg3lY75iWrqL4UN0=; fh=EaPcEp04wdCAk8wTHzsONqWscpl46moZgxJ8rZbNZ/k=; b=BIsiGcxx/FqWhBSAj3kMUQ2JQ7krJ73L2jwY4xibL+j7MvyRRVToOtZXwZ1mXfOwC2 A/AOOS4aSSrRllqmXYHoAhT1UfqE2OZFs1YcNtDpN/jCYVvfwi6wVl7C2Fq0Kc4M0lBy Yo2btLA0ZMy+SPPGIYIq70qSl14XMGVfvOuPfRMWeS3as7LUi/Wr01PzXe7fj7XVtcZG Ib3HI1EeadVGmYEmrP2zes2FYRWd47W/eMYTrQ7f9d+ILWgY07CETqsnkWq+v/D5Qxha E4KfODZKckoqUuIzRcy9vcGtOG6wD/SYPrGOHq3YpjY0aEH1oBmDsU8QQx4sBj27Hu8Q NTUw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gotplt.org header.s=dreamhost header.b=xFWn+ytK; arc=pass (i=1); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org" Received: from server2.sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id j19-20020a170906255300b0099bce4aa78dsi12311050ejb.865.2023.09.20.04.51.30 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Sep 2023 04:51:30 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@gotplt.org header.s=dreamhost header.b=xFWn+ytK; arc=pass (i=1); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org" Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 737763856944 for ; Wed, 20 Sep 2023 11:51:18 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from dormouse.elm.relay.mailchannels.net (dormouse.elm.relay.mailchannels.net [23.83.212.50]) by sourceware.org (Postfix) with ESMTPS id 733603858C27 for ; Wed, 20 Sep 2023 11:50:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 733603858C27 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org 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 C3E49411AC; Wed, 20 Sep 2023 11:50:48 +0000 (UTC) Received: from pdx1-sub0-mail-a316.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 1D54C41A72; Wed, 20 Sep 2023 11:50:48 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1695210648; a=rsa-sha256; cv=none; b=kRLNAdQu62JoFWfomD4kZw1lM36kYHlSv6KZLpc9tWOfOWM6dAc6dnJfGTjwLEK/+oZVbX TmqKMqsRccqGwH5b7rstXadeW7iN03r2es54jooLuuU5mrOelQhtjYo+4eZ+/apMeGvf7A Z4hueNzdXq3BoJz3XmjUPAXKw8cN5KXHdKv7iSqu2/4Mj2rWxon5OUNRlGaV+38K81oAf0 +5tyZtN2xACsV2DQaWWoDX33WY1wQ9oCzUgQcQ6krExcgu0fItFgZuwe1Vk/TSVcu+cJNx c71SZo4hHwj1KwaLOIZfcWc4CdM2suyLsHgsfvxKH5XDt0/3ZwiGz4xm1HUZRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1695210648; 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:dkim-signature; bh=XVSVXmLwaNpEDUbN3F6hsfp6JVRSg3lY75iWrqL4UN0=; b=k7uX6KE0R8ZsppeLkbqLxt1igfz//TQvidvgxCxN2SlLtpbQhSx1viTAhjokAMq8cMlKdp cs4T1TRVG7MIHRp0LyFpPiMSpFGNYK6XaqKmsiVxpBIsWbEwnBfOT69AdhfGBpH44ShNMR 8w87RrFhfDtXofVHGYWrHPjpTN0UPWYe9dzpLv8WYj1Z95bmeUesoJp/q9rtRtKtZeS2a5 KLPCaUfItVb0U9TliCuCBdqVH/YCUGt2IsoyxUtfAiefMyL3alr9/eB4/2pUpwGWgM0Qgt 17uRwML3mVaxD6f7grLiLXGNdWarN0ldgOrNE44tOuWM5GztXMn6aPYxcA2saw== ARC-Authentication-Results: i=1; rspamd-7d5dc8fd68-dwsg9; auth=pass smtp.auth=dreamhost smtp.mailfrom=siddhesh@gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Madly-Descriptive: 7873309710fa0181_1695210648659_716495614 X-MC-Loop-Signature: 1695210648659:3384717495 X-MC-Ingress-Time: 1695210648658 Received: from pdx1-sub0-mail-a316.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.99.54.157 (trex/6.9.1); Wed, 20 Sep 2023 11:50:48 +0000 Received: from fedora.redhat.com (bras-vprn-toroon4834w-lp130-02-142-113-138-41.dsl.bell.ca [142.113.138.41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a316.dreamhost.com (Postfix) with ESMTPSA id 4RrH0l4vxZzRV; Wed, 20 Sep 2023 04:50:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1695210647; bh=XVSVXmLwaNpEDUbN3F6hsfp6JVRSg3lY75iWrqL4UN0=; h=From:To:Cc:Subject:Date:Content-Transfer-Encoding; b=xFWn+ytKwCKBxY1q9OW42M2kgNzHgO8cfWbk0AW/vNmfl4mJyHpzD864M9u8ivQJp 3eXUjcippDyaL99VuZDErr0eJFLzkbg22kW7C5qS9Wi8KJlAWFjHtb6Swo86GoG5mC fWii/eMnjsfHMd+TQHTLNhT2D/5Z0GE3CVyL0844Egn9zijT8akoArSeqFN6SjMYh0 cgsd++cfzGgO4PH8POe5k2VpQUo0Tb/MTXpXZQ+uTRhze8yWRWqO2QyORg7p93OTYT wkyw7FUMdLWQyd44UUPHS4ywpj4UTRGM6hGvoQw6QHOqVegizhcKl5ID96dXjz5x1r uC+jxuQVv/FNw== From: Siddhesh Poyarekar To: gcc-patches@gcc.gnu.org Cc: dje.gcc@gmail.com Subject: [PATCH] Add a GCC Security policy Date: Wed, 20 Sep 2023 07:50:43 -0400 Message-ID: <20230920115043.3434942-1-siddhesh@gotplt.org> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 X-Spam-Status: No, score=-3036.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_ASCII_DIVIDERS, KAM_SHORT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP 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: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777557244569850848 X-GMAIL-MSGID: 1777557244569850848 Define a security process and exclusions to security issues for GCC and all components it ships. Signed-off-by: Siddhesh Poyarekar --- Sending as a proper patch since there have been no further comments on the RFC. I toyed with the idea of making the distinction of "exploitable vulnerability" vs "missed hardening" more explicit near the top of the document but decided against further tinkering in the end since we already have a proper section dealing with it. Instead I made the language in the hardening section a bit more explicit, clarifying that missed hardening is not an *exploitable vulnerability*, which hopefully resolves the contradication of a bug in a security feature not being a security bug. I also added the AdaCore security contact at Arnaud's request. Thanks, Sid SECURITY.txt | 202 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 202 insertions(+) create mode 100644 SECURITY.txt diff --git a/SECURITY.txt b/SECURITY.txt new file mode 100644 index 00000000000..d2161f03bf5 --- /dev/null +++ b/SECURITY.txt @@ -0,0 +1,202 @@ +What is a GCC security bug? +=========================== + + A security bug is one that threatens the security of a system or + network, or might compromise the security of data stored on it. + In the context of GCC there are multiple ways in which this might + happen and they're detailed below. + +Compiler drivers, programs, libgccjit and support libraries +----------------------------------------------------------- + + The compiler driver processes source code, invokes other programs + such as the assembler and linker and generates the output result, + which may be assembly code or machine code. Compiling untrusted + sources can result in arbitrary code execution and unconstrained + resource consumption in the compiler. As a result, compilation of + such code should be done inside a sandboxed environment to ensure + that it does not compromise the development environment. + + The libgccjit library can, despite the name, be used both for + ahead-of-time compilation and for just-in-compilation. In both + cases it can be used to translate input representations (such as + source code) in the application context; in the latter case the + generated code is also run in the application context. + + Limitations that apply to the compiler driver, apply here too in + terms of sanitizing inputs and it is recommended that both the + compilation *and* execution context of the code are appropriately + sandboxed to contain the effects of any bugs in libgccjit, the + application code using it, or its generated code to the sandboxed + environment. + + Support libraries such as libiberty, libcc1 libvtv and libcpp have + been developed separately to share code with other tools such as + binutils and gdb. These libraries again have similar challenges to + compiler drivers. While they are expected to be robust against + arbitrary input, they should only be used with trusted inputs. + + Libraries such as zlib that bundled into GCC to build it will be + treated the same as the compiler drivers and programs as far as + security coverage is concerned. However if you find an issue in + these libraries independent of their use in GCC, you should reach + out to their upstream projects to report them. + + As a result, the only case for a potential security issue in the + compiler is when it generates vulnerable application code for + trusted input source code that is conforming to the relevant + programming standard or extensions documented as supported by GCC + and the algorithm expressed in the source code does not have the + vulnerability. The output application code could be considered + vulnerable if it produces an actual vulnerability in the target + application, specifically in the following cases: + + - The application dereferences an invalid memory location despite + the application sources being valid. + - The application reads from or writes to a valid but incorrect + memory location, resulting in an information integrity issue or an + information leak. + - The application ends up running in an infinite loop or with + severe degradation in performance despite the input sources having + no such issue, resulting in a Denial of Service. Note that + correct but non-performant code is not a security issue candidate, + this only applies to incorrect code that may result in performance + degradation severe enough to amount to a denial of service. + - The application crashes due to the generated incorrect code, + resulting in a Denial of Service. + +Language runtime libraries +-------------------------- + + GCC also builds and distributes libraries that are intended to be + used widely to implement runtime support for various programming + languages. These include the following: + + * libada + * libatomic + * libbacktrace + * libcc1 + * libcody + * libcpp + * libdecnumber + * libffi + * libgcc + * libgfortran + * libgm2 + * libgo + * libgomp + * libiberty + * libitm + * libobjc + * libphobos + * libquadmath + * libsanitizer + * libssp + * libstdc++ + + These libraries are intended to be used in arbitrary contexts and as + a result, bugs in these libraries may be evaluated for security + impact. However, some of these libraries, e.g. libgo, libphobos, + etc. are not maintained in the GCC project, due to which the GCC + project may not be the correct point of contact for them. You are + encouraged to look at README files within those library directories + to locate the canonical security contact point for those projects + and include them in the report. Once the issue is fixed in the + upstream project, the fix will be synced into GCC in a future + release. + + Most security vulnerabilities in these runtime libraries arise when + an application uses functionality in a specific way. As a result, + not all bugs qualify as security relevant. The following guidelines + can help with the decision: + + - Buffer overflows and integer overflows should be treated as + security issues if it is conceivable that the data triggering them + can come from an untrusted source. + - 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. + +Diagnostic libraries +-------------------- + + The sanitizer library bundled in GCC is intended to be used in + diagnostic cases and not intended for use in sensitive environments. + As a result, bugs in the sanitizer will not be considered security + sensitive. + +GCC plugins +----------- + + It should be noted that GCC may execute arbitrary code loaded by a + user through the GCC plugin mechanism or through system preloading + mechanism. Such custom code should be vetted by the user for safety + as bugs exposed through such code will not be considered security + issues. + +Security features implemented in GCC +------------------------------------ + + GCC implements a number of security features that reduce the impact + of security issues in applications, such as -fstack-protector, + -fstack-clash-protection, _FORTIFY_SOURCE and so on. A failure in + these features functioning perfectly in all situations is not an + exploitable vulnerability in itself since it does not affect the + correctness of programs. Further, they're dependent on heuristics + and may not always have full coverage for protection. + + Similarly, GCC may transform code in a way that the correctness of + the expressed algorithm is preserved, but supplementary properties + that are not specifically expressible in a high-level language + are not preserved. Examples of such supplementary properties + include absence of sensitive data in the program's address space + after an attempt to wipe it, or data-independent timing of code. + When the source code attempts to express such properties, failure + to preserve them in resulting machine code is not a security issue + in GCC. + +Reporting private security bugs +=============================== + + *All bugs reported in the GCC Bugzilla are public.* + + In order to report a private security bug that is not immediately + public, please contact one of the downstream distributions with + security teams. The following teams have volunteered to handle + such bugs: + + Debian: security@debian.org + Red Hat: secalert@redhat.com + SUSE: security@suse.de + AdaCore: product-security@adacore.com + + Please report the bug to just one of these teams. It will be shared + with other teams as necessary. + + The team 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 +============================== + + It is expected that critical security bugs will be rare, and that most + security bugs can be reported in GCC, thus making + them public immediately. The system can be found here: + + https://gcc.gnu.org/bugzilla/