From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id vzbCH9A/SWVB7j8AWB0awg (envelope-from ) for ; Mon, 06 Nov 2023 14:34:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1699299280; bh=dhWFz/OcmJQbbORmj0lNoIxHf1Cn/5qqv4EoFt5Z7cs=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=BpvcF3MNyDhPPRkqUTIOR744GB8mi8iDFRWeHD6bHhRm5r/66or3xnHlT+b9Rz4Rp 7K7X6iFkV7+iomzcoH4Gi4EJpoqsTBHix12sYnA59/1MfbD4o+Vlh5Gr/dvgnUiYDU pT4O5CNk9skbD9tvADiQA1P1G8z7XalxXDGkN6A4= Received: by simark.ca (Postfix, from userid 112) id 735281E0D2; Mon, 6 Nov 2023 14:34:40 -0500 (EST) Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=aLJWKtAF; dkim-atps=neutral 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 62AD31E098 for ; Mon, 6 Nov 2023 14:34:38 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 15FEF3858031 for ; Mon, 6 Nov 2023 19:34:38 +0000 (GMT) Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 303DE3858C50 for ; Mon, 6 Nov 2023 19:34:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 303DE3858C50 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 303DE3858C50 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699299268; cv=none; b=ZmK+3jzh41u+BgQtceIqy5DyvX8OFqWf9p+ssaTjprV5BCeJ6qGQdCk4ET0rLHISrpksOKAYQ8gV7IOpSWdP9tYQjlfy7m9F+VNltdpgAuS+B5v5Dgbm5dZaNQlp1fQtLY6TM2IGtTpfQ8OPHLGTM8MIFrs8fIbR0EpK16qneow= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699299268; c=relaxed/simple; bh=dhWFz/OcmJQbbORmj0lNoIxHf1Cn/5qqv4EoFt5Z7cs=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=a6XOov0M+xYtA8C4X4KKoz8NxTmgY38LzPPa6jejolpCfM8dQAAZmc15V+NQUp7l/vNpW2YKdamIjvj5H38gLawYJf4pZQeJscz7Op/DiZH9w7qlLj/7h+qnGxWPquJjRZL7AFXgxIAUiASjd4R7C7tzTMAcK0FVbrrDYSfoaR0= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1699299265; bh=dhWFz/OcmJQbbORmj0lNoIxHf1Cn/5qqv4EoFt5Z7cs=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=aLJWKtAFv4Sea5RJdk1nFNsicoW6x1gOPN6goJWHsBxjZnpbJusPThqqSYeNlB45O o++VszpjNUhBmv2N0rOzQunrdBNGH80suEJCbuG+tT8nSAn8pyCWSwyO/dydT/Xp+D g0Fcnzi4eU86gWQ95yNqakFDLECtZvUaSePxusrE= Received: from [172.16.0.192] (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 8C2CC1E00F; Mon, 6 Nov 2023 14:34:25 -0500 (EST) Message-ID: Date: Mon, 6 Nov 2023 14:34:24 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] Adding a SECURITY policy for GDB Content-Language: fr To: Andrew Burgess , gdb-patches@sourceware.org Cc: Siddhesh Poyarekar References: <877cmvui64.fsf@redhat.com> From: Simon Marchi In-Reply-To: <877cmvui64.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, 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 On 11/6/23 08:26, Andrew Burgess wrote: > 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. Do you have examples of this? It seems like any bug in that category would be bugs in the platform / OS, not GDB. If such a bug is possible to exploit with GDB, the user could another program to exploit the same bug. > 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. My opinion would have been that just loading a file in GDB just to inspect it statically should be a safe thing to do, even with a malicious binary. It's possible to do in theory, by being defensive and very careful of everything we read. In practice, I understand that it might not be a realistic goal, given the complexity and the current state of BFD / GDB. And since most of the CVEs you got (IIUC) were of this kind, that wouldn't help you much. So, I'm fine with that you have, given that I'm not the one who has to deal with these annoyances. Simon