#47614 [security] Chunked store references in .zo files in Racket 8

Message #5 received at submit@debbugs.gnu.org (full text, mbox, reply):

Received: (at submit) by debbugs.gnu.org; 6 Apr 2021 11:08:44 +0000
From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 06 07:08:44 2021
Received: from localhost ([127.0.0.1]:39362 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces@debbugs.gnu.org>)
	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 <mhw@netris.org>) 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 <mhw@netris.org>) 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 <mhw@netris.org>) 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 <mhw@netris.org>)
 id 1lTjZS-0005gW-Te; Tue, 06 Apr 2021 07:08:35 -0400
From: Mark H Weaver <mhw@netris.org>
To: bug-guix@gnu.org
Subject: [security] Chunked store references in .zo files in Racket 8
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-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit@debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit@debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request@debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces@debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

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/…-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/…-racket-8.0/share/racket/pkgs/gui-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/stor|
00000d20  65 2f 6e 32 63 6e 70 32  66 69 76 78 71 31 30 6b  |e/n2cnp2fivxq10k|
00000d30  78 71 61 6c 63 76 32 71  34 31 77 7a 73 79 6a 39  |xqalcv2q41wzsyj9|
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

Send a report that this bug log contains spam.