From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id GMGrIF9BbGCdrAAAgWs5BA (envelope-from ) for ; Tue, 06 Apr 2021 13:09:19 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id YKCUGl9BbGC0UwAAB5/wlQ (envelope-from ) for ; Tue, 06 Apr 2021 11:09: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 8C8101A1BF for ; Tue, 6 Apr 2021 13:09:18 +0200 (CEST) Received: from localhost ([::1]:42964 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lTja9-0008G7-6d for larch@yhetil.org; Tue, 06 Apr 2021 07:09:17 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46944) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lTjZv-0008Fx-RH for bug-guix@gnu.org; Tue, 06 Apr 2021 07:09:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:56049) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lTjZt-0002Qi-Vc for bug-guix@gnu.org; Tue, 06 Apr 2021 07:09:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lTjZt-0007zi-Q7 for bug-guix@gnu.org; Tue, 06 Apr 2021 07:09:01 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#47614: [security] Chunked store references in .zo files in Racket 8 Resent-From: Mark H Weaver Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Tue, 06 Apr 2021 11:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 47614 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: 47614@debbugs.gnu.org X-Debbugs-Original-To: bug-guix@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.161770732430702 (code B ref -1); Tue, 06 Apr 2021 11:09:01 +0000 Received: (at submit) by debbugs.gnu.org; 6 Apr 2021 11:08:44 +0000 Received: from localhost ([127.0.0.1]:39362 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lTjZb-0007z8-Nm for submit@debbugs.gnu.org; Tue, 06 Apr 2021 07:08:43 -0400 Received: from lists.gnu.org ([209.51.188.17]:44558) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lTjZX-0007yx-NC for submit@debbugs.gnu.org; Tue, 06 Apr 2021 07:08:42 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46854) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lTjZX-0008Da-J1 for bug-guix@gnu.org; Tue, 06 Apr 2021 07:08:39 -0400 Received: from world.peace.net ([64.112.178.59]:55740) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lTjZV-0002Af-FU for bug-guix@gnu.org; Tue, 06 Apr 2021 07:08:39 -0400 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lTjZS-0005gW-Te; Tue, 06 Apr 2021 07:08:35 -0400 From: Mark H Weaver Date: Tue, 06 Apr 2021 07:06:54 -0400 Message-ID: <87k0pf7jti.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=64.112.178.59; envelope-from=mhw@netris.org; helo=world.peace.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1617707359; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=Uy9kL9PgVsICD/PTkMCINlTwUyJHydbSN0BxhOuv840=; b=SQHOqDnBtmay6SJ/iKrPCJD1EDx2xiK8uGBZ381BgbzUDsdhXn170tml6vqKqCLrXl0nWL VUw4iGojDaJX6C8fAw7zADk509jveDWzjK1l+FYF9FElszUEa41RuANjOaaNi5d2tAgB3T zXIsUr6tPQ6Q8N2J4+w2CNpFDdrPgVK9fnk6yUORXgRBaDHMOrisQb7D2y+ZL1R9C4huyA krAN+Pmp2i7xiAJhNVqqxf7vjfvr9n+qWog3ss4/S3Wa9AFjleKY1SsR/LEU5RLn2Rc5+4 iN6pU+PuPMMvwXGIbhxTHzPxir69UoLqA3zswvTJ9+Un2bZ06oGwMvbv9WFc7A== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1617707359; a=rsa-sha256; cv=none; b=mqb0+6RGSDz+ObrRXUfVOlHIaDf73emv6+3krBz4G/Oozdniksxaqo/SVDNwifoRbVx92E uCd3gp/VJ5SvnahGcIn9ToMBEnHPEHz1gPZH2xEiKXH2HvEsswhHQy3BciijtZbbDkWbMJ 14l7/szUvk6Tj1DHgSNw+Ty6wV/9qL8sCPkWt9Gc5cXLOhBdNHhdvYBSQU2eHGGeBK4xbT jkYbqt0HUrdDlhRNg/EgDFHZLoY/aOZi/6/0f+g1wxvqfAI2iuUzGlT0oQk83Wi+8tXqfJ 7g7aDOTTJhbQA+vM8sMvpV+OskrQAtN0ZStn9bIqS7qKe4x/yequOOVdcyKVnw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Spam-Score: -0.94 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Queue-Id: 8C8101A1BF X-Spam-Score: -0.94 X-Migadu-Scanner: scn0.migadu.com X-TUID: gyV9jwv1v6hB On my system, Racket 8.0 contains a *.zo file that contains a *chunked* store reference. As a result, it retains a reference to the ungrafted Gtk+, and therefore to the ungrafted glib, cairo, and libx11. The file is: /gnu/store/=E2=80=A6-racket-8.0/share/racket/pkgs/gui-lib/mred/private/wx= /gtk/compiled/gtk3_rkt.zo, and here's the relevant excerpt: --8<---------------cut here---------------start------------->8--- mhw@jojen ~$ hexdump -C /gnu/store/=E2=80=A6-racket-8.0/share/racket/pkgs/g= ui-lib/mred/private/wx/gtk/compiled/gtk3_rkt.zo | grep -B2 -A6 /gnu/ 00000cf0 c0 06 23 00 06 36 02 31 c7 c6 46 25 02 61 7f 0b |..#..6.1..F%.a= ..| 00000d00 48 c7 c5 06 a3 01 28 67 03 32 01 08 0c 00 f0 23 |H.....(g.2....= .#| 00000d10 05 00 58 11 1e 26 48 2f 67 6e 75 2f 73 74 6f 72 |..X..&H/gnu/st= or| 00000d20 65 2f 6e 32 63 6e 70 32 66 69 76 78 71 31 30 6b |e/n2cnp2fivxq1= 0k| 00000d30 78 71 61 6c 63 76 32 71 34 31 77 7a 73 79 6a 39 |xqalcv2q41wzsy= j9| 00000d40 79 64 62 01 d0 2b 2d 33 2e 32 34 2e 32 34 2f 6c |ydb..+-3.24.24= /l| 00000d50 69 62 04 00 f0 1f 67 74 6b 2d 33 2e 73 6f 00 0e |ib....gtk-3.so= ..| 00000d60 11 1f 07 02 12 23 12 24 0c 26 00 15 06 41 0b 40 |.....#.$.&...A= .@| 00000d70 00 1d 11 20 26 1e 5b 2e 2e 2e 61 74 65 2f 77 78 |... &.[...ate/= wx| --8<---------------cut here---------------end--------------->8--- The referenced store item is this: /gnu/store/n2cnp2fivxq10kxqalcv2q41wzsyj9yd-gtk+-3.24.24 Notice that in the .zo file, there are three additional bytes inserted before the dash ("-"). This store reference is seen by the Guix scanner, because the nix hash is stored contiguously. However, it is *not* seen by the grafter. Note that the grafter assumes that the entire store item name will be stored contiguously. The current implementation only finds hashes that are immediately followed by a dash ("-"), and moreover assumes that nix hashes will never occur except within the corresponding store item name. In this case, the reference was simply ignored, because the dash was separated from the hash. If the extra junk had been inserted *after* the dash, the grafter would have made a mess of things. It would have (incorrectly) assumed that the rest of the expected store item name followed the dash, and inappropriately written the replacement string over the unexpected bytes. With this case in mind, I think we can no longer safely assume that the bytes following a nix hash will be as we expect. As a general principle, I think that *every* byte that the grafter modifies should first be checked against its expected value. That should allow us to catch problems like this early, and avoid non-obvious breakage cropping up. What do you think? Mark