From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id aJJhOtZHdGXZsxsAWB0awg (envelope-from ) for ; Sat, 09 Dec 2023 05:56:22 -0500 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=qJJhAvi8; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id EBE781E0D2; Sat, 9 Dec 2023 05:56:22 -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 DF7C01E00F for ; Sat, 9 Dec 2023 05:56:20 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E63353858419 for ; Sat, 9 Dec 2023 10:56:19 +0000 (GMT) Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 540CA3858CD1 for ; Sat, 9 Dec 2023 10:56:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 540CA3858CD1 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 540CA3858CD1 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702119369; cv=none; b=HCeY0TCzTMYeKyYpOHZ91AuUWEUX39oS+cLwS6lKwwTrr/pLcnYr99j0OJh6X/Ey3ikhr0LjqwQrpmHd58UScU2PU3VQhIcjREyguykRFVDbMw8nMDxk2FXYca8B5xJNxTWz1OyK06/xac+qK550YhsJjhVW2p9qoOniQmfin1U= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702119369; c=relaxed/simple; bh=MVFSQ6FJQ01HTZCfa527Qil9FPgNqcceWPfD7fDtOKk=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=dl4fIi2+4WBPfzTKzAJJ0Wm4duD0iTDr0bHwTkblQoORstGpnv+Y9i8xenH9AyHFFwk4qXMys906c6WVQaBpTUmdqzL28nCANoKLVf++hBHx8atKQ7qoAiKu/E/LShXQCn5S4OH7eSCXq6f52+TMvzqVFwB9k9CBQxdWIC6VG7g= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rBv06-0002Uj-Md; Sat, 09 Dec 2023 05:56:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Gir3ZQW6hGCxDfa+QgqNSXDjkbFY1c3+NXw4pxPGa8M=; b=qJJhAvi8pA2u ZzhYSVdWrNM3oI5TATdM9f+EFjDOpR7WA3/QK8w8XbPc/NSw5ZsQ1fjdzUNm+DBmEgb1QxPeR8Q3+ D70UoxuADYGi897lYyyY2eLzUi70jf5Kk3u2QkZBcHUXxlPIF7yH6FGa1H7lELy/wveXMEaoCDh0T bTYLFcdyHH6JXmM9dy3tExAqPjsdc/EGVa8/OMWtLu6guOBYjuU+ZQ7DIt6kOHmIdoER3i1U/6GfP QNJ9obb0IMygfPH++FYt4CWiT5iTqTYe25FIFSPhe7zb+N8mZM8wvicuWrGc7+g61eLomUOVFbTeb AiLWOH22yKWEGjYHL41Jtw==; Date: Sat, 09 Dec 2023 12:55:33 +0200 Message-Id: <83cyvfy7a2.fsf@gnu.org> From: Eli Zaretskii To: Andrew Burgess Cc: gdb-patches@sourceware.org, siddhesh@redhat.com, kevinb@redhat.com, simark@simark.ca, felix.willgerodt@intel.com, paulkoning@comcast.net In-Reply-To: <87wmtog2f4.fsf@redhat.com> (message from Andrew Burgess on Fri, 08 Dec 2023 15:05:35 +0000) Subject: Re: [RFC] Adding a SECURITY policy for GDB References: <877cmvui64.fsf@redhat.com> <87wmtog2f4.fsf@redhat.com> X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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: 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 > From: Andrew Burgess > Cc: Siddhesh Poyarekar , Kevin Buettner > , Simon Marchi , > felix.willgerodt@intel.com, Paul Koning > Date: Fri, 08 Dec 2023 15:05:35 +0000 > > Remote debugging uses GDB to connect to a remote target. GDB sends > commands to the remote target which then controls the remote target. The last sentence above has some kind of typo in it: it basically says that "remote target controls the remote target", which makes no sense. So either "controls" should be "control" (plural), which would then mean it refers to "commands", or the sentence should be reworded to clarify the meaning (perhaps it conflated between gdbserver and the program it controls?) > 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. I suggest to prepend "However," to the last sentence, to make it clear that it is contrary to the sentence before it. > 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. Suggest to reword the last two sentence into one: Since running a program through GDB is no different from running a program directly, it follows that when debugging an untrusted program, 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. I don't think I understand what this attempts to say. Maybe this sentence should be moved to after the previous one. Like this: Running a program through GDB is no different than running a program directly. Additionally, it is possible for a program to detect when it is run under GDB and to change its behavior, so that the unwanted behavior may only appear when a program is run under GDB. Therefore, when debugging an untrusted program, the user should ensure that this is done in a secure environment. > Any issues that arise from running an untrusted binary are not > security bugs in GDB. This is too general, I think. Perhaps you meant Any issues that arise from running an untrusted binary not inside a secure environment 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. Same here: too general? > The connection between GDB and a remote target is not protected by > either authentication, or encryption. ^ That comma is redundant and should be deleted. > 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. There should be a comma after "As such" in the last sentence, otherwise it reads as an incomplete sentence. > Any issues that arise due to a failure to protect the connection > between GDB and a remote target are not security bugs. ^^^^^^^^^^^^^^^^^^^^^ "are not security bugs in GDB." > 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 ^ That semi-colon should be a colon. > Any bugs in GDB that result in execution of the program being > debugged without a user issued GDB command triggering execution ^^^^^^ "issuing" > (either from the GDB command line, a GDB configuration file, or from > the GDB prompt) are considered security bugs. Is any execution of the program triggered by starting GDB considered "a command issued by the user"? IOW, are we sure GDB will never cause some program code to be executed just as result of the user saying $ gdb ./program ? The above text seems to assume that any such execution at startup must be the result of some command-line argument or some configuration file, but is that 110% certain, and are we sure this will _never_ change? > 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. Similar issue here: when this says "having been executed", does it mean executed explicitly by a user command, or does it also mean executed as part of the administrivia of loading the program? > Within this section, mention of GDB should be read as meaning GDB, ^^^^^^^^^^^^^^ "references to GDB", not "mention of GDB" > 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. This text contradicts the remark above that a malicious program could change its behavior when running under GDB. > When using GDB or to examine an untrusted program (with gdbserver, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Something is wrong here: some word missing or maybe "or" should be deleted. > 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 ^^^^^^^^^^^^^^^^^^^^^ Did you mean "would not be"? otherwise this sentence makes no sense, because of what follows starts with "but": > security bug, but it would be best practice to guard against such > a bug if possible. > When using GDB and gdbserver to perform remote debug, the connection > between the two components in by design insecure. It is up to the ^^ "is" > In order to report a private security bug that is not immediately > public, please contact one of the downstream distributions with "immediately public"? what's that? > 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. This doesn't explain what is "embargo". Should it? I, for one, don't know what that means. Thanks.