From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id OAzZI4syE2CEMgAA0tVLHw (envelope-from ) for ; Thu, 28 Jan 2021 21:54:19 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id 4Fi2H4syE2AhDwAAbx9fmQ (envelope-from ) for ; Thu, 28 Jan 2021 21:54:19 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 451209404CF for ; Thu, 28 Jan 2021 21:54:19 +0000 (UTC) Received: from localhost ([::1]:43486 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l5FF4-00081T-3L for larch@yhetil.org; Thu, 28 Jan 2021 16:54:18 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50294) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l5FEi-00081B-IA for guix-devel@gnu.org; Thu, 28 Jan 2021 16:53:56 -0500 Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:47553) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l5FEf-0001IX-WE for guix-devel@gnu.org; Thu, 28 Jan 2021 16:53:56 -0500 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 3114A1100; Thu, 28 Jan 2021 16:53:52 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 28 Jan 2021 16:53:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=famulari.name; h=date:from:to:cc:subject:message-id:mime-version:content-type; s=mesmtp; bh=SduxhBDPstqr2EP0n2qTZLpLpDxbrqyBMUoekAQXZos=; b=ZY JahvRcJM9ojcSjJ21NxJi9G2ZLP6mnvMQrfWyMTmJRmMqsOulmVHpJVoia8mP5BY CBuCzGGbJFZ2XvyT8tqouRVHjwqlrlLtwqp1dFS0lO2T8AVsKvh4kri/VxddDn2n YJYy8Bp8KOYnHbD8QEV+jT9iB2kF92Ebx5WtIU8gc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=SduxhBDPstqr2EP0n2qTZLpLpDxbr qyBMUoekAQXZos=; b=ZOVPWhlW1uie46ICuez9eydP3SiVg+aUHLSSIhrSQ+iix PKnL2NcUIaXHsA8JxdFso+rj+lWpGIQA/fc+5DUk1l3Kc7smXWdyYlyy4nei61/1 ocWQmo032flKe/DoCMsuLpJLkaSnpkvimgJNBqKCOwxJzuRtPDBtZ3K/7NvSTtb3 Zw5c5NSKxbVIXGtlH9PlApgOi/N3DTchF4XoZh1XnLue8yyNA0KxMpAM01b1VP+E uJOzLB8ENWNiBVy2ooVe0kD2Yd+HMV5vX1IlkjyMqCztAnuuZEjvslr8bNKyVkzp yV5VikpbJ7m47rpihvn8QVbUUrYVTIOwxNoAOZWug== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedtgdduhedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggusehgtderredttdejnecuhfhrohhmpefnvghoucfhrghm uhhlrghrihcuoehlvghosehfrghmuhhlrghrihdrnhgrmhgvqeenucggtffrrghtthgvrh hnpedvteegudevvdfggeefudfftdffhfelgfetkeekfeekheettdegvedtgfdttdetueen ucfkphepuddttddruddurdduieelrdduudeknecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomheplhgvohesfhgrmhhulhgrrhhirdhnrghmvg X-ME-Proxy: Received: from localhost (pool-100-11-169-118.phlapa.fios.verizon.net [100.11.169.118]) by mail.messagingengine.com (Postfix) with ESMTPA id 1125C1080057; Thu, 28 Jan 2021 16:53:51 -0500 (EST) Date: Thu, 28 Jan 2021 16:53:49 -0500 From: Leo Famulari To: guix-devel@gnu.org Subject: Potential security weakness in Guix services Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VkaVowxjgGd3Z3Gd" Content-Disposition: inline Received-SPF: pass client-ip=64.147.123.20; envelope-from=leo@famulari.name; helo=wout4-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -3.45 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=famulari.name header.s=mesmtp header.b="ZY JahvR"; dkim=fail ("headers rsa verify failed") header.d=messagingengine.com header.s=fm1 header.b=ZOVPWhlW; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: 451209404CF X-Spam-Score: -3.45 X-Migadu-Scanner: scn0.migadu.com X-TUID: iuFsWHM0erpW --VkaVowxjgGd3Z3Gd Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On January 19 2021, we received a message from Maxime Devos describing a potential attack vector on Guix System. If an attacker can exploit a remote code execution vulnerability (RCE) in a program used by a Guix service, they could use it to take over the system in some cases. We have not deployed any mitigations for this. Below is a summary of their messages, including a mitigation proposal. Your feedback is requested! ----- Forwarded message from Maxime Devos ----- For clarification: the scenario I currently have in mind, is that noone has intentionally introduced a security hole in a service, but rather there's an accidental security bug somewhere in service package, that allows an attacker (I'm assuming the service is accessible from the network) arbitrary code execution *within* the service's process. As it is now, the attacker could overtake the service process, then chown and chmod arbitrary directories from there. As a particular example, I'm considering e.g. a hypothetical ipfs-service-type. A compromised IPFS proce= ss shouldn't be able to change /etc/passwd entries. The security of the IPFS service itself shouldn't be critical to the security of the system as a whole. ----- A more specific exapmle: ----- Forwarded message from Maxime Devos ----- I seem to have stumbled upon a potential security issue, it has to do with how some services use mkdir-p/perms. For example, in knot-activatio= n: (define (knot-activation config) #~(begin (use-modules (guix build utils)) (mkdir-p/perms #$(knot-configuration-run-directory config) (getpwnam "knot") #o755) (mkdir-p/perms "/var/lib/knot" (getpwnam "knot") #o755) (mkdir-p/perms "/var/lib/knot/keys" (getpwnam "knot") #o755) (mkdir-p/perms "/var/lib/knot/keys/keys" (getpwnam "knot") #o755))) /var/lib/knot/keys/keys is chmodded and chowned, which seems innocent enoug= h. However, what if knot whas compromised at some point, and the compromised k= not process has replaced /var/lib/knot/keys with, say, a symlink to /gnu/store? Then the next time the system the system is reconfigured, the knot-activati= on gexp is ran agan, and the last =E2=80=98mkdir-p/perms=E2=80=99 will chown /= gnu/store to "knot", and now the (compromised) knot service can manipulate the store! Ok, this would be a security issue in knot but ideally the security hole wouldn't =E2=80=98propagate=E2=80=99 to the whole Guix system. ----- And in a followup: ----- Forwarded message from Maxime Devos ----- It's also possible to create a symlink to /etc/passwd, in which case a compromised (non-containerised) service can change /etc/passwd after system reconfiguration -- mkdir-p/perms doesn't verify whether its target is a directory before chowning and chmodding. ----- And finally, a proposal: ----- Forwarded message from Maxime Devos ----- Also, I propose a procedure to guix-security: (define (mkdir-p/own root sub/.../dir owner bits) "Create ROOT/SUB/.../DIR, and its parent directories. This procedure bails out if ROOT/SUB/.../DIR isn't owned by OWNER. No restrictions are placed on the ownership of ROOT. If ROOT doesn't exist, it is created with the current uid, gid and umask. If SUB/... don't exist, they are created with uid and gid OWNER and the current umask. If ROOT/SUB/.../DIR doesn't exist, it is created with uid, gid and permission bits BITS. Symbolic links under ROOT/ are not followed." ... implementation) idk if symlinks components in /ROOT should be followed. Probably no service definition requires this, so *never* following symlinks may also be possible? Not strictly required for security I think, but it eases reasoning about security properties. (Less variables to consider) ----- --VkaVowxjgGd3Z3Gd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAmATMm0ACgkQJkb6MLrK fwiPDBAA1Rel1HmqUL41duhwoN56JsDe7gDJUSHCyA+nKLRwyoJTdREOWs9X0PHB M5p7QgLlcwQqmcHrnCmbpOtqrgiQP1CG48EadIcnYEQsjVtNFpb+WvnKjhnPzcqD 7M655rD20aI2RBCoenc7a1hh/GAIgLx2Fm5UtYXaojvdrocKnD7ifbwmAVWcStkc R0OqYCGzvHo/8GDVMnPhui6/kZL0ZProqUSrNYnjbg5xsXsjW65Hpu+Wv56OCyKo 2ZUxPKsgiFKwxJTkSpVMctoIiDHV7M8wlDIL5FNIuFaEa6MwUNxGNXtg8zP9DVUn KK5S7YXcChvXT+/OKSvy4/lcxf6P0sl0Nt3FV/dvvMS3CyUuAyzLntwh+evsbn/A szRtnVaaPMPxw7nMtjlk2kjP10O7UJJGO/XiHO+nINQ0QUcERCOp1cI4qIwfyjai XrlCCYY7JgZ0+YdN7WpVrbFkPWHZWxHEBpdlZctYEEa8fkmHJnaIT/jN3pwHxcDF a1yV6ktxfbWlDeQ1tGZlyH1evEj8L6fGb6W37tJNsk65EyaewCEdH4A02cDVzHMC e1ooqg5vDjq2IZxeIVhoT5GYZdtCc2yJD4+Peb8Z7v1vbRmQwMqLXFazqt0G22tQ CZa3BEdsD4M7rAKVAbb7VDnDdM/ZWHGPq9OkrWOtJ28B6DZpKhE= =bALF -----END PGP SIGNATURE----- --VkaVowxjgGd3Z3Gd--