From patchwork Thu Sep 28 11:55:41 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Siddhesh Poyarekar X-Patchwork-Id: 1840726 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gotplt.org header.i=@gotplt.org header.a=rsa-sha256 header.s=dreamhost header.b=Hlt2dtQL; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=server2.sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=patchwork.ozlabs.org) Received: from server2.sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4RxBlG15Skz1yp0 for ; Thu, 28 Sep 2023 21:56:10 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 35E37386187F for ; Thu, 28 Sep 2023 11:56:08 +0000 (GMT) X-Original-To: gcc-patches@sourceware.org Delivered-To: gcc-patches@sourceware.org Received: from antelope.elm.relay.mailchannels.net (antelope.elm.relay.mailchannels.net [23.83.212.4]) by sourceware.org (Postfix) with ESMTPS id C74013858C01 for ; Thu, 28 Sep 2023 11:55:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C74013858C01 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 BF3D48410E4; Thu, 28 Sep 2023 11:55:52 +0000 (UTC) Received: from pdx1-sub0-mail-a296.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 21204840FD2; Thu, 28 Sep 2023 11:55:52 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1695902152; a=rsa-sha256; cv=none; b=8jHALLAATqmOn8QOsTv6IIR5wCOrMVP0MOiyDNSsw+UlSfxF/SLzai+lRmVsoS1lT7iYf9 zuRGBL8g0S2maRLBKZKdS2A+lT5QftfXSrqI9nINHCVzV9WsmQPyhvBay9Wf5ouCLs5DU/ cvndR/kQqt5JlVitVSEumAhjaNuaRJ5hrzFrcycPiFKt43sgjNP8GPemc4Z8+uWeScHUW4 nB5jizf0So53gA9kTBmUMTO5zbo7fEFrCVohh21/wXTuLeLunmxvm+Wr9U7jCERAHcNOMV VwnkAlv92/AEI7RBY0Wx5YQ1ec+NXxLeG4EvM1B1id2YOy2GFe/6yMx6K6Odcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1695902152; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=CxaZWRa37cH7hfFYaNNJ0kZrm4bGDwvjqojQUYwf4Oc=; b=SdY1Q/xFfDQevxXT0sKKi7qQX9Q9JOXpIudNrF5Q1XuspenudzZoV9vrcK6yLU18jxABS/ CJ0EKcb+O8cSj1DzGD72zIp7Y1NHYUZGfKFfobaN10/m1FmuMKcBLfBzipqUCvMzWpEcoS fQHxVuglteKY/E21CVZA0gMqP1DJc08f0bzQMK+nC8J5YAf600UZxw0z/lZ4IaiIbASq07 Izt8IB7Y+qa8jiANFsVpa3E3pj91Gciu79FTaKCxFSo9gL+kf4B3wip+dMfPt385LRjcPt r4+hHwxQVVBcJaXH9c5AVy3QrTIVHojZFc4MwROmarACQVrI2wpsro/AVLRgsQ== ARC-Authentication-Results: i=1; rspamd-7d5dc8fd68-775pw; 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-Hook-Bored: 7829dd4a72dcbcbc_1695902152637_3128053948 X-MC-Loop-Signature: 1695902152637:2361923550 X-MC-Ingress-Time: 1695902152636 Received: from pdx1-sub0-mail-a296.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.109.110.212 (trex/6.9.1); Thu, 28 Sep 2023 11:55:52 +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-a296.dreamhost.com (Postfix) with ESMTPSA id 4RxBkv4x9qz1T; Thu, 28 Sep 2023 04:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1695902151; bh=CxaZWRa37cH7hfFYaNNJ0kZrm4bGDwvjqojQUYwf4Oc=; h=From:To:Cc:Subject:Date:Content-Transfer-Encoding; b=Hlt2dtQLRYEdG4CSJqe1PnF50ez/LQ1o+jLKwnpHtWBZ+TGq0G4QwKFO2sB9dGxKt RBNjIfP5myyyZUOCGBIbcBGRgU0q8ZmqizfIgbjuVL6DoLMV9t0piO3JFUwchAvNWp RLrRFm8+DFAnrf2SlON87CZpDOXbiABAvw8B9HvBE/qUSh4b/35i6VqHUkhbl5NQrA jS/7XSLrTAfPJu3HoyAu+PF0WQkaCQThzgDfD0xk66NU/41zb4BDEJsKT5ki11QRlK IJD9uJRqtDZ7V8s/cjZLnPLEf/Ir72K5QBYhnBnW53BVABUadwoEoleFRY1eqeFRYq 0cgwrmVhVcM9Q== From: Siddhesh Poyarekar To: gcc-patches@sourceware.org Cc: dje.gcc@gmail.com Subject: [PATCH v2] Add a GCC Security policy Date: Thu, 28 Sep 2023 07:55:41 -0400 Message-ID: <20230928115541.3454970-1-siddhesh@gotplt.org> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20230920115043.3434942-1-siddhesh@gotplt.org> References: <20230920115043.3434942-1-siddhesh@gotplt.org> 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_H5, 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+incoming=patchwork.ozlabs.org@gcc.gnu.org Define a security process and exclusions to security issues for GCC and all components it ships. Signed-off-by: Siddhesh Poyarekar --- SECURITY.txt | 205 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 205 insertions(+) create mode 100644 SECURITY.txt diff --git a/SECURITY.txt b/SECURITY.txt new file mode 100644 index 00000000000..14cb31570d3 --- /dev/null +++ b/SECURITY.txt @@ -0,0 +1,205 @@ +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 some common scenarios are detailed below. + + If you're reporting a security issue and feel like it does not fit + into any of the descriptions below, you're encouraged to reach out + through the GCC bugzilla or if needed, privately by following the + instructions in the last two sections of this document. + +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. + + Libraries such as libiberty, libcc1 and libcpp are not distributed + for runtime support and have similar challenges to compiler drivers. + While they are expected to be robust against arbitrary input, they + should only be used with trusted inputs when linked into the + compiler. + + 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 + * libitm + * libobjc + * libphobos + * libquadmath + * 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 +-------------------- + + Libraries like libvtv and the sanitizers are intended to be used in + diagnostic cases and not intended for use in sensitive environments. + As a result, bugs in these libraries 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/