From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id OLFnJ0hPVmWM6wcAWB0awg (envelope-from ) for ; Thu, 16 Nov 2023 12:20:08 -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=BSwoFne4; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 9E7721E0D2; Thu, 16 Nov 2023 12:20:08 -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 8DF401E091 for ; Thu, 16 Nov 2023 12:20:06 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9950E3858015 for ; Thu, 16 Nov 2023 17:20:05 +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 EEB543858CD1 for ; Thu, 16 Nov 2023 17:19:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EEB543858CD1 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 EEB543858CD1 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=1700155195; cv=none; b=PX7iamRIta2P3p33DExV2D934yyAopruP1OCXw5xo+Hf61GyvqgUQ/NzulxrBTfVewxCGXIxU16y7tTBzC6pAOtKSqXPG5CvEsi7+zMIxUw187jI1TOAlr/d2lI02oiPj5Mtsec06HdxoY2dOGzmuTyloZ7repWTKHaGipunBdY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700155195; c=relaxed/simple; bh=VDAbTDNvXw/eqqnPI6eaM2dChsXFgUQK3shl12c3J6Y=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=MJHIjYyCYABnOtMTRjoXgx9GQlylnr3VoPE5gH2eYZE7pVjGd3CsnGSRKjKpfudnASEmTBNMesYdFDzjDxeyKXS95lu3IDLrpltFwCuakZwCk8Sjv3IuAuVJ/UGgEiSL5YKcGhRUCDLZbJcZcwocQTmcPhqFpsaPv+hc5RU8nqc= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1700155193; 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=OVzTh32i97YKGvnI0Ne3GrdM/tfWN66SomkAzN2jaS8=; b=BSwoFne4fC3AF/FWUF5S7vGbn3ai4ki+pCIRvBeP68VamfJSJPU6gr46ZqalMd18VrNTJw LW8YPdIfpCW+T1s33mUjmaV3hxKUqisQe6YIZn/VCnge/pe7GSSIAkzCJ9BraQAE0VEwjn s7TKdAtLtrDIgiiONxLE+X6HrScWJ9U= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-423-2v3A_r-pPHmPp9FwI1Qbcw-1; Thu, 16 Nov 2023 12:19:52 -0500 X-MC-Unique: 2v3A_r-pPHmPp9FwI1Qbcw-1 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-4084d08235fso6209365e9.3 for ; Thu, 16 Nov 2023 09:19:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700155190; x=1700759990; 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=OVzTh32i97YKGvnI0Ne3GrdM/tfWN66SomkAzN2jaS8=; b=NiwbMhjo0uP0fusABumxPLdoFSRBHSgi6PHqykrL23eq9l4qkUylQ3c9nz1BgSk1YO Z6WLfD2F/ndJpae0so0tltilTZnc7QHTNFlCp8WPe+IOeHWNlUE7HnSt4H64e9RJhtoa f8u8leMNbB7d1k3OTqGueKD4ctxWCHFdwzKRyKD5LbcZtz/GFyyxkqE6OlVQtzo4g6qq CkMQe61qIGTO4CemBuFjlj8oaXG1yN+jyl3gSXQZSjwVF4gSl9hxosf+6Ji8QQ6RLUUK v96tpGpxhkUaAFdwvAcP5nk6GfygM/j3y9XHz0wJQ0UL213zmonGrCDCETq6xG+qNByk VKfw== X-Gm-Message-State: AOJu0YxbBLAtcqtt+LMZgMv2CNvJVtH8SZj9s6GGLUJ1NCHle2cWNCnm pIlkObWAaJe/F/Wn7cnG/RuCMC3LOZMfd8U8A8hrsS9lD1ceU8Q7GoO0UXRLjFzQVVxtpEKkdoQ UgUw34g9CptpPGcJ9WXwWj82FNXqwYA== X-Received: by 2002:a05:600c:ad3:b0:3f6:9634:c8d6 with SMTP id c19-20020a05600c0ad300b003f69634c8d6mr13028214wmr.18.1700155190510; Thu, 16 Nov 2023 09:19:50 -0800 (PST) X-Google-Smtp-Source: AGHT+IE7A5I+HcuszL56WQ4v/zA+mU8f4v348Ehpqn4Rv8DUYEsVLsb58H3g9omlAbEAZogvPxNAZg== X-Received: by 2002:a05:600c:ad3:b0:3f6:9634:c8d6 with SMTP id c19-20020a05600c0ad300b003f69634c8d6mr13028196wmr.18.1700155190143; Thu, 16 Nov 2023 09:19:50 -0800 (PST) Received: from localhost (105.226.159.143.dyn.plus.net. [143.159.226.105]) by smtp.gmail.com with ESMTPSA id m7-20020a05600c4f4700b0040772138bb7sm4428630wmq.2.2023.11.16.09.19.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Nov 2023 09:19:49 -0800 (PST) From: Andrew Burgess To: Simon Marchi , gdb-patches@sourceware.org Cc: Siddhesh Poyarekar , felix.willgerodt@intel.com Subject: Re: [RFC] Adding a SECURITY policy for GDB In-Reply-To: References: <877cmvui64.fsf@redhat.com> Date: Thu, 16 Nov 2023 17:19:48 +0000 Message-ID: <874jhlr4y3.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.8 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 Simon Marchi writes: > 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 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? Given the complexity of the DWARF parser, I'm not sure we can't say for certain that such a bug couldn't exist. 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. > 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. Indeed. Most of the CVEs we're seeing are simply invalid DWARF bugs. We've never even seen anyone make an attempt to convert the inevitable GDB crash into an attack. My concern is that, I don't think I can credibly say: "Invalid DWARF crashes are not security bugs unless you can show an actual attack." So instead I fall back to a default position of just, "GDB might have bugs. Don't touch an untrusted binary unless you're in a sandbox." Maybe one day we could harden the DWARF parser enough that we can take the position that reading any binary will be harmless ... but I'm not sure that's a priority for anyone right now. This reply has taken me so long to write because I'm aware that the above sounds like a bit of a cop-out. I'd be interested to hear people's thoughts. Thanks, Andrew