From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 6OAGJgZRVmXr7AcAWB0awg (envelope-from ) for ; Thu, 16 Nov 2023 12:27:34 -0500 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=comcast.net header.i=@comcast.net header.a=rsa-sha256 header.s=20190202a header.b=etZM6v8K; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 97D801E0D2; Thu, 16 Nov 2023 12:27:34 -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 876A31E091 for ; Thu, 16 Nov 2023 12:27:32 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1F8DA385841D for ; Thu, 16 Nov 2023 17:27:32 +0000 (GMT) Received: from resdmta-c1p-023854.sys.comcast.net (resdmta-c1p-023854.sys.comcast.net [IPv6:2001:558:fd00:56::d]) by sourceware.org (Postfix) with ESMTPS id 3CD3E38582BC for ; Thu, 16 Nov 2023 17:27:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3CD3E38582BC Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=comcast.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=comcast.net ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 3CD3E38582BC Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:558:fd00:56::d ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700155640; cv=none; b=wI0ed+gLbcx1Cg65hN4vp4l4m4yyUpO1X5PJvdjK/LPV9f2TNjer5HCUAHGYPwg1693QaRKoypn8KjA7gl2VtApA41xVYGKLOAvgcoyFeqtdUELV7zfWB2nHQYsswUf0BIskKOnvcIlspOKeBXxcG7R7h+wrVjIbVNviWV13LXE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700155640; c=relaxed/simple; bh=mnXOVg+OMndhhOKcjD6jorVHBOb5/uzgr8P2n2iEmNc=; h=DKIM-Signature:Mime-Version:Subject:From:Date:Message-Id:To; b=czdqOd7+q2CLBjUt+zqH6F2YFBIHVTrgJLFfigMS5FxxOGAaKX1I+ZJUfb3c3A/ak8ba9FAux2ETApxF2qPCswmDK9sCdcOgiw5q/MhU6/yRacal72Xk0QJyrTJ6EHuLcsZ1PiQJdyync78b3xUZwhSyK3sqFNcoF+mn95/Y8P4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from resomta-c1p-022592.sys.comcast.net ([96.102.18.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resdmta-c1p-023854.sys.comcast.net with ESMTP id 3cuNrNTZV19Bh3g98re0P0; Thu, 16 Nov 2023 17:27:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1700155638; bh=67sffbwIKOO77Zuqo3ihHdT7Bg03fmftwuXcg2BoGqU=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To:Xfinity-Spam-Result; b=etZM6v8K47IxGh+RoHIWugubBadqNn5KfLWebEbREfp6ri3w6+KqZ+eisI4gyskEU 8IUtawIAjNtalw/dMAiafjtXPfbvg6R4rB6rcgpc+oToN2u4D2a1WXkIq6u271ePnj 86cZer/DjMOynQjkWqVpch9LeGlmYejy7bq98qOt/vV7p3wuYGzoTZApJBmi7NurIW HrV+zPORhF/g7b6ZqMa5i2KmgbpBbuY2TbwDWk341uH4Ns55LBKcKxLZiukAZZFK7r 72o8b3YC6VdoBKgCu0b4zWbs5cSr2c7Qq/seCDrHnXRmLlwvecqxzyveGMo9aQdUZk wUyk8I5FV5e8w== Received: from smtpclient.apple ([73.60.223.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resomta-c1p-022592.sys.comcast.net with ESMTPSA id 3g96rLOdJ6BkD3g96r20qT; Thu, 16 Nov 2023 17:27:17 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\)) Subject: Re: [RFC] Adding a SECURITY policy for GDB From: Paul Koning In-Reply-To: <874jhlr4y3.fsf@redhat.com> Date: Thu, 16 Nov 2023 12:27:16 -0500 Cc: Simon Marchi , gdb-patches@sourceware.org, Siddhesh Poyarekar , felix.willgerodt@intel.com Content-Transfer-Encoding: quoted-printable Message-Id: <8662D372-9C8D-4391-B2F4-F6871618136B@comcast.net> References: <877cmvui64.fsf@redhat.com> <874jhlr4y3.fsf@redhat.com> To: Andrew Burgess X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, 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 Nov 16, 2023, at 12:19 PM, Andrew Burgess = wrote: >=20 > Simon Marchi writes: >=20 >>> ... >>=20 >> 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. >=20 > In an ideal world I'd love to say that just loading a binary for > inspection is a safe thing to do. But I think the concern would be, > could we imagine a situation where a malicious binary could somehow > trigger GDB to start executing the inferior without any user > interaction? >=20 > Given the complexity of the DWARF parser, I'm not sure we can't say = for > certain that such a bug couldn't exist. >=20 > And if we accept that such a bug could exist, then it seems like we = have > a choice: we can declare that a user should sandbox GDB before = touching > an untrusted binary, or we can say that any bugs in GDB related to > simply inspecting a binary that might cause undefined behaviour in = GDB, > could, potentially, cause GDB to execute the inferior unasked, and = could > be considered security issues. I would lean towards "security issue". Yes, the paranoid can use = sandboxes, but that's a pain in the neck that people would not expect to = do for software that by design and intent should not need such = precautions. With GDB, the expectation is that it executes supplied = binaries, with all that implies, if and only if you ask it to do so. = There are cases where that happens even if you didn't say "run" = (invoking target functions from the command line, for example). But = loading and examining a binary are not expected to cause execution, so a = hypothetical bug that does execute bits other than GDB itself in such a = case are very much unexpected and deserve to be called a security bug. paul