From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id oCO6GHX8A2bnHxgAWB0awg (envelope-from ) for ; Wed, 27 Mar 2024 07:01:09 -0400 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=B1qfFjTk; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 5F9451E0C0; Wed, 27 Mar 2024 07:01:09 -0400 (EDT) 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 4982A1E030 for ; Wed, 27 Mar 2024 07:01:07 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D3AA93864814 for ; Wed, 27 Mar 2024 11:01:06 +0000 (GMT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 033273860760 for ; Wed, 27 Mar 2024 11:00:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 033273860760 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 033273860760 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711537247; cv=none; b=Oo/R9SLdHEgSiaoUIpWpERGVbdZREkumGMmXhRP91gVpysk53CVNnsQ0pvTBgfBSA+VzK5NnAs5eR/XyZOuMOj52XwYheKkN0aRBu9GDa7P9ZugSz3lnsazT8HRKbqgJlOu67VKi/FohhuTWWkLtIyatMW//ch458HG17TK7J+g= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711537247; c=relaxed/simple; bh=/fDbFEqy3bsex4E0WI1JzfUgAaSNittnnp2Zm5j6iNc=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=H9+EzVA2xXPF9CF8pw8H8Ibn85G5cu2G3vzWUo6vl9eQ9y+igsVdGqyLhOVgJZ0gCF9ZuFqs8v5iJTxgeM3r0bxR7FDVuAHwIVqvGNtRwGwvxNOjEWfVdhVb5s8HIA+eJXRpI84rIeHXhrVcfS2tcjwS5xNxuAiw2vg3w0N6Sho= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1711537243; 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: in-reply-to:in-reply-to:references:references; bh=89aemevL9hul3titehCmCTIoCZFqTQkwJbJ9OKXvvhE=; b=B1qfFjTkV97tkbZmlEgMxZQ43V3hwt7nu0eiOwiG0dvHqrbQIxLELQVi+Wvy4MvvCBmjhV qV47+kQEySuM9Mpph2BcK8YOnUjquhGVZaHviZJAZM8qTvqR2uxNFRQBKYydmmswd/qJ6u capP4TvQ66DbR7w/p601C3dGEUUJZSo= Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-616-2EVKMHIWNYqhBAQCB6pFCA-1; Wed, 27 Mar 2024 07:00:42 -0400 X-MC-Unique: 2EVKMHIWNYqhBAQCB6pFCA-1 Received: by mail-ej1-f71.google.com with SMTP id a640c23a62f3a-a47416276c7so251881166b.3 for ; Wed, 27 Mar 2024 04:00:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711537240; x=1712142040; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=89aemevL9hul3titehCmCTIoCZFqTQkwJbJ9OKXvvhE=; b=doVYvYHpo8v3k/xpDyE402HjOdZ0z4tzkHci9fVmoOTgCymoJaSjncYW4+8rdb1ePP YCVez8Ze5nXh26B3Btv5FSRCKJFPrHXUCXDsBajvClm5pdXdEUQ8TiYe033183PerPck L9kywby1HLLLzFgk7UNl8W9u1TV/gXAaKT65ehWcCoi9BdQWx2flLQTRvRn7V8K/Syyt y9NXR3/wQ5jnlJONTqxOTIQES+0DlSF/FAB/tsmRjEpyiSzkLFnkNZMMg9ii8rO270l4 zHKWqId0k7H8XveiLkXf5+E1M9G3o3/eOGqWy6hF8zv9EpY/pfNzz1uDaP4a2qBS8rVL EmEA== X-Gm-Message-State: AOJu0YwoMUAvFAdXKtUbAN0uI/l5HWtGFUDw4gQ9yPxbxCtYzET/X2Xp iIvCnvDTOdBSXy0QrCm5T0Cu+iTxtWRxJ4FDAlvGQdog1CCLldy7vwPA7GHpUgbD5aiB5vxUBDF pmglkuPA3uZwHpQ4VrpaCG8+CCdBKatWdRGNJpacR7CQXXSzCDHJnAzWi+4kPuDUK9A7orHwR+X AjFAsdmyH9SANdbvbOHpd8znQfKIXNo35I0MtKkrCfI1g= X-Received: by 2002:a17:906:f209:b0:a47:3664:1b98 with SMTP id gt9-20020a170906f20900b00a4736641b98mr3252593ejb.7.1711537240006; Wed, 27 Mar 2024 04:00:40 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEXrvXmeVxAa7wJk8IrdhCL0LlF4yPGQHjXJ0vdRyolGQh8NS5kzmMr8r7kCSrFk2eElO0Zvw== X-Received: by 2002:a17:906:f209:b0:a47:3664:1b98 with SMTP id gt9-20020a170906f20900b00a4736641b98mr3252563ejb.7.1711537239164; Wed, 27 Mar 2024 04:00:39 -0700 (PDT) Received: from localhost (185.223.159.143.dyn.plus.net. [143.159.223.185]) by smtp.gmail.com with ESMTPSA id wk15-20020a170907054f00b00a4a3600d2absm3307920ejb.172.2024.03.27.04.00.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Mar 2024 04:00:38 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Siddhesh Poyarekar , Kevin Buettner , Simon Marchi , felix.willgerodt@intel.com, Paul Koning Subject: [V4] [RFC] Adding a SECURITY policy for GDB In-Reply-To: <87o7cd6fmk.fsf@redhat.com> References: <877cmvui64.fsf@redhat.com> <87wmtog2f4.fsf@redhat.com> <874jeo5jip.fsf@redhat.com> <87o7cd6fmk.fsf@redhat.com> Date: Wed, 27 Mar 2024 11:00:38 +0000 Message-ID: <87msqk3pnt.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.5 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 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 I realise I didn't tag my last update as V4. I wonder if anyone has any thoughts on this latest iteration. Andrew Burgess writes: > Thank you all for the continued feedback. > > In V4 I have: > > - Reordered some of the text. As I was adding/changing words I felt > the old order didn't make as much sense, so some of the paragraphs > have been shuffled around a little, > > - Added some text about per-project/per-program configuration files > not being auto-loaded unless the user specifically allows them, and > mentioned that a bug which allowed such auto-loading without a user > command would be a security issues, > > - Added some words to try and reflect the (current) reality which is > that the ELF/DWARF loaders are known/likely to contain bugs when > confronted with malformed input, which could result in undefined > behaviour, which could be a security issue. This effectively means > that, though we'd like to say it is safe to examine an untrusted > binary (so long as you don't execute it), in reality, it's not > really safe (currently) to do such a thing. > > In some ways this is a return to the position from V1, against which > there was some push back. However, the new text is slightly > different. While V1 basically said "it's never safe to touch an > untrusted binary with GDB (outside of a sandboxed environment)", the > new text is trying to say "we'd like it to be safe to examine (but > not run) and untrusted binary, but we're not there yet". > > This security document shouldn't be "final for all time", it should > be a living document, just like every other part of GDB. Hopefully, > in time, we might one day reach a position where we feel we can say > not only that we'd like such a use of GDB to be secure, but that it > actually _is_ secure (to the best of our knowledge). > > All feedback welcome. > > Thanks, > Andrew --- GNU Debugger Security Policy ============================ Introduction ------------ The GNU Debugger (GDB) is a tool for diagnosing issues "inside" another program. This can be done by controlling the execution of the program being debugged and allowing the user to inspect and modify the state of the running program. Or GDB can be used to analyse the program or a core file generated from the program without needing to execute the program. The program being debugged may be local i.e. on the system on which GDB runs or remote, on a different system. Policy Objectives ----------------- The objective of this policy is define what the GDB project considers a security bug and what is a non-security bug, and how bugs can be reported. Additionally this policy discusses areas of GDB in which there are known bugs, how these might lead to security issues, and how this risk can be mitigated. Scope Of This Policy -------------------- This policy covers all currently supported versions of GDB as released from the official GDB website and covers gdb, gdbserver, as well as gcore and gdb-add-index, which are packaged with each GDB release. The official GDB website can be found here: https://sourceware.org/gdb/ Remote debugging uses GDB to connect to a remote target. GDB sends commands to the remote target which then controls the process being debugged. The GDB project provides one remote target, gdbserver, which is included with official GDB releases. Bugs within gdbserver are in scope for this policy. Other projects also implement remote targets to which GDB can connect. Any bugs in these remote targets are out of scope for this policy and should be reported to the relevant project. However, any bugs in GDB caused by a misbehaving remote target, even when that target is not gdbserver, are in scope for this policy. What Is A Security Bug? ----------------------- Any bugs in GDB or gdbserver that result in an unexpected 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. Any bugs in GDB that result in execution of the program being debugged without the user issuing a GDB command triggering execution (either from the GDB command line, a GDB configuration file, or from the GDB prompt) are considered security bugs. GDB will check for and load multiple configuration files. When initially started GDB can load user and system specific configuration files, this is done unconditionally as it is assumed these files are under control of the user and are always safe to load. GDB can also load per-project and per-program configuration files, this is done when a program to debug is loaded into GDB. These configuration files will only be loaded if the use has given GDB permission to load these files. Any bug in GDB which allows per-project or per-program configuration files to be loaded without permission having been granted by the user is considered a security bug. When gdbserver is started, if it is passed a program on its command line then that program will be started, but paused before executing its first instruction. Any bug in gdbserver which results in further execution of the program being debugged without GDB first connecting to the target and sending a command that is intended to trigger execution is a security bug in gdbserver. Any bug in GDB or gdbserver that can trigger arbitrary code execution without the program being debugged having been executed by a user command, is considered a security bug, e.g. if loading a program into GDB could trigger arbitrary code execution, then this is a security issue. The additional tools gcore and gdb-add-index are scripts that wrap around GDB. Any issue in these tools that meet the above definitions of a security bug, are considered a security bug. What Is Not A Security Bug -------------------------- In the context of local debugging, when GDB is used to execute a program, the program runs with the same privileges as GDB itself. Any issues that arise from running an untrusted program outside of a secure environment are not security bugs in GDB. Any issues that arise from running an untrusted program through GDB inside a secure environment are only security bugs if GDB is required in order to trigger the issue. It is possible for a program to detect when it is run under GDB and to change its behavior so that unwanted behavior may only appear when a program is run under GDB. Any issues that arise due to an untrusted program detecting GDB and changing its behaviour are not security issues in GDB unless the issue also meet some other definition of a security bug. In the context of remote debugging, the program being debugged is run with the same privileges as gdbserver. As with GDB in the local debugging case, any issues that arise from running an untrusted program outside of a secure environment are not security bugs in gdbserver. 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. Any issues that arise due to a failure to protect the connection between GDB and a remote target are not security bugs in either GDB or gdbserver. Security Realities Of The GDB Project ------------------------------------- Within this section, references to GDB should be read as meaning GDB, gdbserver, gcore, or gdb-add-index, unless specifically stated otherwise. The most common use case for GDB is a developer trying to resolve issues within a program that they have either written themselves, or within a program that they trust not to be malicious. In this situation we would say GDB is being used to debug trusted code. There is no greater security risk from running the program to debug through GDB than there is running the program directly. Additional process isolation for the GDB process is only needed if additional isolation would have been applied anyway when running the program to debug. In some cases a developer may be given a program from an untrusted source and be asked to debug an issue. In this situation we would say GDB is being used to debug untrusted code. In this case the user should take all the precautions when running GDB that they would normally take when running an untrusted program outside of GDB, e.g. running within a secure, sandboxed environment. When using GDB to examine, but not execute, an untrusted program (with gdbserver, the program will be started, but paused at the first instruction and not run further), there should be no security risks, however the GDB maintainers don't currently believe that GDB or gdbserver is reliable enough to ensure that there are no security risks. There are known bugs in GDB related to loading malformed executables and parsing the debug information, a consequence of these bugs is that a malicious program could trigger undefined behaviour in GDB, which could be used to trigger arbitrary code execution. Given these risks, the advice of the GDB project is that, when using GDB with an untrusted binary, always do so in a secure, sandboxed environment. As there are already known bugs in GDB relating to undefined behaviour triggered from malformed programs, further bugs in this area should still be reported, but are unlikely to be given high priority. Bugs in GDB that are triggered by well-formed programs should also be reported, and are likely to be treated as higher priority as these are more likely to impact normal use of GDB. When using GDB and gdbserver to perform remote debug, the connection between the two components is by design insecure. It is up to the user to protect this connection, for example, by only starting gdbserver within a secure network. Reporting Non-Security Bugs --------------------------- NOTE: All bugs reported in the GDB Bugzilla are public. Non-security bugs, as well as any security bugs that pose limited risk to users should be reported in GDB's bugzilla system. Bugs reported in this way will be public. The bugzilla system can be found here: https://sourceware.org/bugzilla/ Reporting Security Bugs ----------------------- In order to report a private security bug that is not immediately made 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 keeping details of the bug private.