From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id KPs1BtYwc2WJBxsAWB0awg (envelope-from ) for ; Fri, 08 Dec 2023 10:05:58 -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=XmFAZeZS; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 15A1C1E0D2; Fri, 8 Dec 2023 10:05:58 -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 F134F1E00F for ; Fri, 8 Dec 2023 10:05:55 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5A720385842F for ; Fri, 8 Dec 2023 15:05:55 +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 8F4CD3858CD1 for ; Fri, 8 Dec 2023 15:05:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8F4CD3858CD1 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 8F4CD3858CD1 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=1702047944; cv=none; b=acUqrC4CppwIitoT8xrulThtp81yQpML83Fz10D/bXONWQ5y/9a8k5Uh469fPi9BQPZVDVK1M0RliPbKvFAMXgbtypxqOqIS2fh9z2ywx9SL9/i8OnzTQTKpqtUjenTgeOv4hySNDASheiX/Cvz5SMTPofINkacQCpym95DR2zw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702047944; c=relaxed/simple; bh=9NFjEzjr+Cn5GN1OEvSIMG2UgK37lvd5j9Mp39B42HU=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=wXJPnRQR8NjxJGoYB7en7mF7xM0WvCMvol47xgZ3kgbIeCxSdNqG8u75/8ob/eBVTIaebhn6rKqvtPOFanlvfpn6cMWw22MJMgBH28n9rpQhJIrz/ppX+5QuJmwnlFr1A0vIWnKixETT0hN//TbaM5rWTlYFsS7aPbE4j1sriq0= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1702047941; 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=828pC/gImAPikTYodbGawRL+Agafty8Loph+mp2Yx/I=; b=XmFAZeZSNkys6lGOBm7wqNKW+6Y2aLluTbD0TfKywD78hBWtf+jFJ/P+oC/AnI+qRQ927v gIdf/+nUbRzZ87IA6PWJcduXMWajG4GuVZk5PaC5Zxt+rYtxChz1RcgEEiBqJqZHejXKgw Cb2w+JiXzfoMgLPmMlVLj40AulvbuGU= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-488-wFwpFLXxOCCeGka9-qy0qQ-1; Fri, 08 Dec 2023 10:05:39 -0500 X-MC-Unique: wFwpFLXxOCCeGka9-qy0qQ-1 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-334adbe43acso1359345f8f.0 for ; Fri, 08 Dec 2023 07:05:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702047937; x=1702652737; 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=828pC/gImAPikTYodbGawRL+Agafty8Loph+mp2Yx/I=; b=feyPC71YwS08bGgXTIRSvZxfI67wuhPHrPkAI85Z9/XPwJshLeK295/W4Rgj5WZicD FQd4+6ihNLWJhQoylWXIrtdA4LL5i1zz7EN6cWWMQ5owXEJIRVJcVdUFv1nQRENT4Op4 2GJqHeNLHe7F0KxZmbGT6xBezwaVPp5qKjsAN4lcam0r42hl+D8x9RTTful3ARJFL8G3 NK3vf50rNB9AT7E3sjtla9OHFzDEJTn+fAPoeH9YrHZQqR6VpWUI1uzFx25//9+KXXTQ HmKD4RDf+WqMUWLIR4O4hBrJ6Wgy9+9hohSkafcpapeQvDFJLD/0OkrQ7MC36ygOfvNJ VDPA== X-Gm-Message-State: AOJu0Yw4Dh6Jplxa3CzqPgMtS4p8QawDeiTFTV4RqILDF/VqN21VtduT 1jtvsF9aA2eB9BAoP+jOST2cFMppIUmWM5lb95JTxi2yDuStsZpxCMUmKtRDTewPctjjmMFjiv9 3hnvHBGlaVdjBZyGuA7Hn/Q5K1zL47KHpgE3s6pVOgoFHZH90VYYb4OY506hu0xW0Q+JugZGMf0 8bGwDHCw== X-Received: by 2002:a05:600c:808e:b0:40b:47d0:cff with SMTP id ew14-20020a05600c808e00b0040b47d00cffmr162830wmb.10.1702047937383; Fri, 08 Dec 2023 07:05:37 -0800 (PST) X-Google-Smtp-Source: AGHT+IE14Y1O7YJ3jVxXfiDmINrNdF2vNrOofbWCDOmraYtDGsNVYfKrjH9+QNHTVA8hQgKoo4rCGA== X-Received: by 2002:a05:600c:808e:b0:40b:47d0:cff with SMTP id ew14-20020a05600c808e00b0040b47d00cffmr162813wmb.10.1702047936722; Fri, 08 Dec 2023 07:05:36 -0800 (PST) Received: from localhost (105.226.159.143.dyn.plus.net. [143.159.226.105]) by smtp.gmail.com with ESMTPSA id u21-20020a05600c139500b00405d9a950a2sm5426195wmf.28.2023.12.08.07.05.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Dec 2023 07:05:36 -0800 (PST) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Siddhesh Poyarekar , Kevin Buettner , Simon Marchi , felix.willgerodt@intel.com, Paul Koning Subject: Re: [RFC] Adding a SECURITY policy for GDB In-Reply-To: <877cmvui64.fsf@redhat.com> References: <877cmvui64.fsf@redhat.com> Date: Fri, 08 Dec 2023 15:05:35 +0000 Message-ID: <87wmtog2f4.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.3 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_H3, 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! Apologies for taking so long to get a second version of this document prepared. I've been through several iterations of this text since I last posted trying to get something semi-reasonable... It would be great to get your feedback on this new text. This is basically a complete rewrite since V1, I'll try cover how this new text addresses the feedback on V1: 1. A part of the original hope was that I could write some text that would allow bugs triggered by just loading a binary into GDB (but not running it) as non-security bugs. Why? Well, most of the bugs we see in this area are from folk throwing fuzzed binaries at GDB, raising a bug, and then raising a CVE on the back of that. The first part of this process is useful for sure. The CVE part is just a resource drain for downstream distributions. I did make several attempts to write some text that would classify bugs in this way ... but, to be honest, after about my fourth attempt, all I'd managed to do was convince myself that this was not a good idea. So, instead, I've just given up on that. I think Simon, Paul, and Felix should find (at least this part of) the new text satisfactory; loading a binary, but not executing it, should be safe to do, and if that's not the case, then this is a security issue. 2. As an aside, but not really relevant to the new text, given my evolving position, I would say that I now disagree with the binutils SECURITY position w.r.t. tools like objdump and readelf that Felix mentioned. I think it's not unreasonable that a user might run an analysis tool on an untrusted binary, and if such a tool can be tricked (via a bug) into executing code, even with the permissions of the original user, then I would see this as a security risk. 3. Kevin asked for discussion about running crash diagnostic tools that wrap around GDB. I believe this is covered by the new text which discusses in more detail how to safely run against trusted vs untrusted binaries. Kevin: If you feel there are still things missing that you'd like to see, then maybe you could suggest at least some bullet points for what should be said, and I'll have a go at fleshing it out. One last thing, while writing this, I did wonder if this text would be better moved into the GDB manual, and the gdb/SECURITY.txt document should just say "See the GDB manual", but I figure that's a problem for future me, for now I just need to find some words we can all agree on. 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 each category of bug should be reported. Additionally, this policy will give some general advice to users on how to use GDB securely. 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 remote target. 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. 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 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. Running a program through GDB is no different than running a program directly. If debugging an untrusted program then the user should ensure that this is done in a secure environment. Additionally, it is possible for a program to detect when it is run under GDB and to change its behaviour, unwanted behaviour may only appear when a program is run under GDB. Any issues that arise from running an untrusted binary are not security bugs in GDB. 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 binary via gdbserver are not 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. 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 a user issued GDB command triggering execution (either from the GDB command line, a GDB configuration file, or from the GDB prompt) are considered security bugs. 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 which results in 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, for example, by simply loading the program into GDB or gdbserver, is considered a security bug. 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. Security Considerations ----------------------- Within this section, mention of 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 sandboxed environment. When using GDB or to examine an untrusted program (with gdbserver, the program can be started, but paused at the first instruction and never run), there should be no security risk, however, there are two things to consider: 1. The risk of inadvertently executing the untrusted program. It would be easy for a user to accidentally issue one of the many commands that would start the untrusted program executing. Even the 'start' command, which stops the program being debugged at the start of the main function might not be safe, a program can embed a malicious payload before the main function is reached. 2. It is possible that a malicious executable could trigger a bug in GDB to perform a malicious action. Such a bug would be a security bug, but it would be best practice to guard against such a bug if possible. Given these risks, the advice of the GDB project is, when using GDB with an untrusted binary, to do so in a sandboxed environment. When using GDB and gdbserver to perform remote debug, the connection between the two components in by design insecure. It is up to the user to protect this connection, for example, 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 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.