From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id SFeBNaHpSGWswz8AWB0awg (envelope-from ) for ; Mon, 06 Nov 2023 08:26:57 -0500 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=B+ySixvA; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id CEAC11E1A7; Mon, 6 Nov 2023 08:26:57 -0500 (EST) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id B04261E0C1 for ; Mon, 6 Nov 2023 08:26:55 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id AB4113858415 for ; Mon, 6 Nov 2023 13:26:54 +0000 (GMT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 86D1B3858D28 for ; Mon, 6 Nov 2023 13:26:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 86D1B3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 86D1B3858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699277204; cv=none; b=I/UIaw0yc4WJwDoVPfm9kerH7H5Q8f7cBdlsrRO/JUiexK9IyhTyypT5zwZzWm8EFPp1gLb5o/GP+CX+Uv84xraPHNvY1zrBmVpMl7TSusBln9/XOHIKqSE5DaJlBnbfm8IOi/QMZnk4tcF+ybejjoxLBRQxo8UVyg25H60l1oc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699277204; c=relaxed/simple; bh=rc4DEPVv9TJthIHA9bm6IJaXVtXRVwgS1dZtoAirR9E=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=u0LjEaf/sBpBiGQ6iapEcp00LV/NmTw8w3jKxDsaMFkVNDqE/npNzQ6gES1UX7W9jstl93oIN6K7c9dUKM4EbDpN8+kAYPo9VwRGT2ehzuT+DSlLMYbgobxymoIU/09GuhK6eHrAGh4T3Gmg1R9P80erTfEfB9ML2YUlniBxfcA= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1699277202; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=MzJMevHtoOEdE3WjDUwLPsVafezg6U1omSprQS4mUQY=; b=B+ySixvA6sI1f8KhynGxBB3qPAuo/kbECZghVBHgHDD1M1uFvXhlcxVUHBwGwdX/Gwhnwp /+QPpPJX6mHo9mVK6EP7fPAZjbnfQfhuXCBKuX9V/PD36iSBHqu17w6QkX7PgCF9VjMW2P pLsJ9OSRJDVSt6iKf2nIFwLxTo8pxO4= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-457-J6lVel6ZNGORNmgexrcv5w-1; Mon, 06 Nov 2023 08:26:31 -0500 X-MC-Unique: J6lVel6ZNGORNmgexrcv5w-1 Received: by mail-qk1-f198.google.com with SMTP id af79cd13be357-7788ce62d50so490528585a.3 for ; Mon, 06 Nov 2023 05:26:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699277190; x=1699881990; h=mime-version:message-id:date:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=MzJMevHtoOEdE3WjDUwLPsVafezg6U1omSprQS4mUQY=; b=OAL9JjXf1KZll6FysdO6KY6OheUShViWv3gN01gavYum4mzEVZbhxgy/6Wg52s6nis qZHTI+mToHelKDlKQq3YY0Wa+X3vEusTkSOvT+bdeHawUKIRvF+DpfvCNAqxz66ZU9ki wTEZwv+nOwhCfP4PlsQypESje+hqpsDkj9aD007dYYWAU6kZT4hWb29mfUdfsYiutRrc n88TbbxBdewBOcgFBqlN6rj8algpmxFeNsy9FXBXPRFQnSS6WZj+yJY+NkDRsiZAPv5d TZQLZvTIK97EY+AgmCQJRHmruF19d9czl4Sp4zfAz1mpHUjDHUN0POKABqFOyHDggMS/ /sLw== X-Gm-Message-State: AOJu0YxemoBtqSLK/Oa00RfXJrdNi54ZpvPrdaxGLNFZmvqsfuHuxbZN Na7SQpanau3g1YUwMmihvcH8GLHU4dzkCSp3WffSkMOl4mF5//2AkrLhm8+aTMpmkNfIME/7sq+ tGcb0fRX2WXRohE9MGehdeI9A8jQmwuE9lMIWM0MsHwgG/a/hXWa6pR8LKGnkJEBnBtufdWhciW Ic7OJOAg== X-Received: by 2002:a05:620a:38c1:b0:77a:6f81:59c1 with SMTP id qq1-20020a05620a38c100b0077a6f8159c1mr7759544qkn.10.1699277190361; Mon, 06 Nov 2023 05:26:30 -0800 (PST) X-Google-Smtp-Source: AGHT+IF9kiQB+QT1621LpYBkbD/7CtEkVzxkVS8gIdA7xKFMi6WeWXFPX8+9YMrxrUXa5mVKi/UVow== X-Received: by 2002:a05:620a:38c1:b0:77a:6f81:59c1 with SMTP id qq1-20020a05620a38c100b0077a6f8159c1mr7759529qkn.10.1699277189991; Mon, 06 Nov 2023 05:26:29 -0800 (PST) Received: from localhost (105.226.159.143.dyn.plus.net. [143.159.226.105]) by smtp.gmail.com with ESMTPSA id 6-20020a05620a04c600b007749dc7881dsm3270870qks.48.2023.11.06.05.26.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Nov 2023 05:26:29 -0800 (PST) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Siddhesh Poyarekar Subject: [RFC] Adding a SECURITY policy for GDB Date: Mon, 06 Nov 2023 13:26:27 +0000 Message-ID: <877cmvui64.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_ASCII_DIVIDERS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Hello! I'd like to add a SECURITY policy document to the GDB project. The purpose of this policy would be to define what we, the upstream GDB project, consider to be a security issue (within GDB) in contrast to what is just a non-security bug within GDB. At Red Hat we see a consistent stream of CVEs filled against GDB. When we discuss these issues internally, we have, at least recently, been of the opinion that these issues are not really security bugs, but are just standard, non-security bugs. Now, that doesn't mean that a non-security bug shouldn't be fixed. But having issues labelled as CVE often leads to pressure for an immediate resolution, and often the effort spent fixing a crash within e.g. the DWARF reader triggered by an invalid ELF, would be better spent fixing other bugs in GDB. So, the purpose of this email is to start a discussion about how the upstream GDB project feels about security vs non-security issues. If we can reach agreement, and establish an upstream GDB SECURITY policy, then this might allow downstream distributors of GDB to push back against CVEs based on the upstream policy document. It is worth noting that binutils has already adopted a SECURITY policy, which can be found in binutils-gdb/binutils/SECURITY.txt. There is also binutils-gdb/SECURITY.txt, which does refer readers to binutils-gdb/gdb/SECURITY.txt, even though this file does not yet exist! Below is my straw-man proposal for a SECURITY.txt document. Given the position I've outlined above, this document does try to make it clear that pretty much no bugs in GDB should be considered a security issue. I'd be interested to hear: * Do people feel I'm being too restrictive in what I consider a security issue? Are there any additional classes of bug that you would see as a security issue within GDB? * I've tried to highlight areas of GDB that might pose a risk if run in a non-secure setting, e.g. GDB run the inferior, so using GDB to debug unknown inferiors can allow arbitrary code execution, or that gdbserver on an open network would allow access to the machine running gdbserver. Are there any other areas of GDB for which we should list as being potentially dangerous if not run in a secure (sandboxed) environment? Thanks, Andrew --- GDB Security Process ==================== What is a GDB 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. The primary use case of GNU GDB is to diagnose issues in programs. These programs may be local, i.e. on the system on which GDB runs or remote, on a different system. In the context of local debugging, any bugs in GDB that result in crossing of a privilege boundary are considered security bugs. Some examples of crossing a privilege boundary include; being able to execute code as an arbitrarily different user, or accessing resources (e.g. files, sockets, etc) for which the original user would not normally have access. In the context of remote debugging, there are two components of relevance; GDB running on the local machine, and a remote target running as a potentially different user, with different permissions, on a remote machine. The GNU GDB project provides one remote target, gdbserver. As with GDB, any bugs in gdbserver that result in crossing of a privilege boundary are considered security bugs. Other projects also implement remote targets to which GDB can connect. Any bugs in these remote targets are out of scope for the GNU GDB project, and should be reported to the relevant project. The connection between GDB and a remote target is not protected by either authentication, or encryption. Connecting to a remote target allows for arbitrary code execution on the remote system with the same privileges as the remote user, and any resource that the remote user can access can be read by GDB, and downloaded to the local machine on which GDB is running. As such users need to take independent measures to secure the connection between GDB and the remote target. While GDB is intended to be robust against untrusted binaries, it is not responsible for arbitrary code execution on a system. As a result, any bugs exposed by untrusted binaries will be accepted and treated with appropriate urgency, but will not be considered security issues. This applies to local as well as remote debugging; any bugs in gdbserver, exposed by untrusted binaries will be accepted and treated with appropriate urgency, but will not be considered security issues. GDB assumes that the remote target is trusted. While GDB is intended to be robust against incorrectly behaving remote targets, a malicious remote target could trigger bugs within GDB. Any bugs exposed by connecting to an untrusted remote target will be accepted and treated with appropriate urgency, but will not be considered security issues unless the bug triggers a privilege boundary crossing. Reporting private security bugs =============================== NOTE: All bugs reported in the GDB 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: 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 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 GDB Bugzilla system, thus making them public immediately. The system can be found here: https://sourceware.org/bugzilla/