From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id SE/WAFWLVmVmEAgAWB0awg (envelope-from ) for ; Thu, 16 Nov 2023 16:36:21 -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=VoI7qTot; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id F33361E0D2; Thu, 16 Nov 2023 16:36:20 -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 DD9861E00F for ; Thu, 16 Nov 2023 16:36:18 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6C5CE3858C5E for ; Thu, 16 Nov 2023 21:36:18 +0000 (GMT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id AC7E93858C42 for ; Thu, 16 Nov 2023 21:36:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AC7E93858C42 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 AC7E93858C42 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700170567; cv=none; b=YTxLuJYe6/yXko2TYDf4C+j2OHlc1HuGMLFKAZdN6+x3I7p2UXJyzNwbQpw1iSniK4aGhQaIfgAR3fGQgbdU12PwNXBRuFumPY589c2SXbqtiVg9TAReRV/fFIqH8+Yfh1ZM0aNvkA/VfjryXkQCIBtWP5YP/HfAshtqQfsFydA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700170567; c=relaxed/simple; bh=0iIwr2+AKwxeabD+lqmGAOHIyt4x3koRtG0zr7llnEo=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=qfg/LHrRmHSCrwuEIaPqQWR0xP//i5vbH3WjxSlYfu6+tLS4HsRhDbdHH31SQ2SzyUd2JrFz0wWxVrRATGVLQABBtmHKOjpszeAG3zGUsIq7CjUF9QC7UrSlFFxtg44cS38QKIb0j0vTV9aqdcaXhtn1oPoJV56sWDsM+KxrRE0= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1700170562; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ECnH+64N85CUYXZzZ6qu6SRMpoaHv+KQZgtyq1JerAA=; b=VoI7qTotPpk6U9646jaz88EosTn7KpnzjZ7pdl6LxhBw6u+3migwfamIoPEcFQ8ZaPoyx+ DsihIl4CG7rlq2T1g56Fw+tTYDkWQTaf22S32RNNVkpAwKeMjwS5KOqSsO+0Rtj/SrsrC6 uYIOwI2bLKYPFyqJOhKQbgWg06IT7m8= Received: from mail-oa1-f70.google.com (mail-oa1-f70.google.com [209.85.160.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-127-R2NWcwcyOWKnL9GglxKt-g-1; Thu, 16 Nov 2023 16:36:01 -0500 X-MC-Unique: R2NWcwcyOWKnL9GglxKt-g-1 Received: by mail-oa1-f70.google.com with SMTP id 586e51a60fabf-1e9bc53c828so1186377fac.1 for ; Thu, 16 Nov 2023 13:36:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700170560; x=1700775360; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ECnH+64N85CUYXZzZ6qu6SRMpoaHv+KQZgtyq1JerAA=; b=W2D8QDH/lBoqae4MvUcgVEyyZc8GVDSZBOiyVDpZLE22gvYJkkXW1/gu+7+fqzthvM aBDCOgOlat+4RwqRQB2+ZoR1Yo0P2VuvpWupm1DtuJHZTsF3CCL/ggXx2N5IdiusW/gu qLZPExrYQKwpdh24zpZhmLV32CW9EIm7ySgUC2B5YHiifQSeBPE5uuTNI7KldpLZuycF BCG5zxdxN9u9ACbEeUwYxJ54aMRnA4+LiKX2vSEUGTjqoSxMuwZF9XbO0MJonp7oBTLc nrwf1x3V9X5P02rLju2OkMy+Y7rVgIOb0mvz0n1j69SogHsCnrZPraEppQcOl0cwaaHl 1NxQ== X-Gm-Message-State: AOJu0YwmF6wJiYAX985ApECZLzKfPgdfpp/clB/K3HaKH2fYZ2iw0N8+ 4iaBRoO0uen4TkqDl6fAYhZ1NyydHNs7jtfzqHfEFFzI92UlT+sJGWlEP/lRK9e4FlcZUeVKMXw qRFaOTnLQLdmeTul7o66fgOk8IY3NR2F3h2hTfw== X-Received: by 2002:a05:6870:c988:b0:1ef:bd6e:f4c6 with SMTP id hi8-20020a056870c98800b001efbd6ef4c6mr24032385oab.41.1700170560350; Thu, 16 Nov 2023 13:36:00 -0800 (PST) X-Google-Smtp-Source: AGHT+IFYEa+EGeDd13tEgkDVG+RnvL9btxOztOWnE7UK2PpsU6d2kiV/r9C2Jjl3COXQeAsknPbseq0iAyLeWkQVK+M= X-Received: by 2002:a05:6870:c988:b0:1ef:bd6e:f4c6 with SMTP id hi8-20020a056870c98800b001efbd6ef4c6mr24032375oab.41.1700170560073; Thu, 16 Nov 2023 13:36:00 -0800 (PST) MIME-Version: 1.0 References: <877cmvui64.fsf@redhat.com> <874jhlr4y3.fsf@redhat.com> <8662D372-9C8D-4391-B2F4-F6871618136B@comcast.net> In-Reply-To: <8662D372-9C8D-4391-B2F4-F6871618136B@comcast.net> From: Siddhesh Poyarekar Date: Thu, 16 Nov 2023 16:35:23 -0500 Message-ID: Subject: Re: [RFC] Adding a SECURITY policy for GDB To: Paul Koning Cc: Andrew Burgess , Simon Marchi , gdb-patches@sourceware.org, felix.willgerodt@intel.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-15.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, 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 Thu, Nov 16, 2023 at 12:29=E2=80=AFPM Paul Koning wrote: > > And if we accept that such a bug could exist, then it seems like we hav= e > > 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 coul= d > > be considered security issues. > > I would lean towards "security issue". Yes, the paranoid can use sandbox= es, but that's a pain in the neck that people would not expect to do for so= ftware that by design and intent should not need such precautions. With GD= B, the expectation is that it executes supplied binaries, with all that imp= lies, if and only if you ask it to do so. There are cases where that happe= ns 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 t= o 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. > That does not reflect reality though. Given how bfd, etc. are today, the idea of gdb being able to securely load untrusted binaries (even without running them) is a pretty ambitious target IMO. Basically all bfd memory safety bugs become *gdb* memory safety bugs and all of the current fuzzing results then become incredibly relevant as security issues because then it's just a matter of tricking users into loading/inspecting arbitrary binaries to compromise their systems. They're no longer just minor annoyances that distract us from regular development. Bubbling up and out a bit, when we state some threat scenario as being accepted as a security issue in the security policy, we not only promise users that we'll treat those issues as security issues, we also make the implicit statement that gdb protects them from that threat scenario, thus endorsing such use. This implicit statement has more serious consequences and based on the current state of bugs, does not correspond to reality. The promise of treating such bugs as security issues however is subjective, i.e. it depends on whether the gdb community considers that it has the resources to respond to all such bugs as if they were security issues, i.e. promptly fix them in master, all supported release branches and then in downstream packages. Even if this were fixed with that en vogue holy grail of rewriting things in rust, I would hesitate to make such a guarantee without sandboxing (e.g. with a --insecure flag that does the loading and inspection in an isolated namespace with a limited set of fds), but that's just my personal opinion. Thanks, Sid