From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: ** X-Spam-Status: No, score=2.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_SBL_CSS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id 6CC6B2D397 for ; Sun, 25 Aug 2024 02:58:22 +0200 (CEST) Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Sat Aug 24 20:55:05 -0400 2024 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org; s=20200506; t=1724547300; h=from:from:reply-to: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: in-reply-to:in-reply-to:references:references; bh=VmwN/JdUvo9sfNvQc8p8UISMmkD7A0pNJejO8QNazJs=; b=QHnSJ8ctvGcZDFmsED2ttsGUn6YT1jgdiC8MmgkVf4ejCnoWWIK4gVhSLwtrLIIa129+wS 0PcgdXI3nbVDaolptiT77rqHp0rWrhR47DmPEgVx77I20U+qdTpy01QUNfpBTnY74io8U2 SBrjJe296pRiCu06Xa9pmbYyAEfxLS8= Received: from [192.168.168.200] ( [207.45.82.38]) by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id 654a0c28 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for <9front@9front.org>; Sat, 24 Aug 2024 19:55:00 -0500 (CDT) Message-ID: Date: Sat, 24 Aug 2024 19:55:02 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Jacob Moody To: 9front@9front.org References: Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: responsive browser Subject: Re: [9front] patch your shit Reply-To: 9front@9front.org Precedence: bulk As of the time of this writing (Sun Aug 25 00:52:02 GMT 2024) the aforementioned issue with the first patch has now been fixed thanks to cinap. I can now suggest (and recommend) that individuals who are running hjfs systems update. The update process is a bit more involved because the hjfs binary used for the root file system on file servers is started from the paqfs. This makes the full update process to be: 1. Update lib9p 2. Update hjfs 3. Update and install a new kernel for your system. For an amd64 system this will look something like: ; cd /sys/src/lib9p && mk install ; cd /sys/src/cmd/hjfs && mk install ; cd /sys/src/9/pc64 && mk install ; ; # stash the known working kernel in case something goes awry... ; 9fs 9fat && cp /n/9/pc64 /n/9/pc64.bak ; cp /amd64/9pc64 /n/9/ && unmount /n/9 && unmount /n/9fat ; fshalt -r # reboot in to the new kernel Now with the patches and update instructions out of the way, I would like to talk more about the bug. DESCRIPTION: As the original commit message details, this is an issue where lib9p did not verify that the user who was issuing the Tauth and Rauth requests matched the one doing the authentication. This effectively allows any user within the configured auth domain to impersonate another user with some well placed 9p messages. This could be abused in the following scenario: * Alice is running a 9front hjfs file server and auth server combination, which allows 9p mounts over tcp/tls. * Alice's hostowner for her server is 'alice'. * Alice has previously created a user for Eve, who has limited access within the server. * Eve creates a local install with a local user named 'alice'. * While logged in to her local alice user, Eve fills her factotum with her valid 'eve' user for Alice's auth server. * Eve, as her local 'alice', user mounts Alice's hjfs server. * Due to this bug, Eve has now mounted Alice's hjfs as Alice's hostowner. IMPACT: This code was solely employed by hjfs and thus affects only hjfs. - moody On 8/24/24 17:18, Jacob Moody wrote: > !WARNING! > > As of the time of this writing (Sat Aug 24 22:17:26 GMT 2024) there is an issue > with this patch which causes hjfs to not permit none attaches. This is currently > being worked on and I suspect we'll have a solution within the next couple hours > but those running a hjfs CPU server may want to avoid updating immediately. > I will respond promptly to this thread once this bug has been patched, and I feel > it is safe to update these systems. I will provide a further write up once there is > a fix for the fix added. > > - moody > > On 8/24/24 14:08, hiro wrote: >> some people did something that increases security apparently. so patch >> your shit. >> >> ref: 07aa9bfeef55ca987d411115adcfbbd4390ecf34 >> parent: b05c74e7cb160f152e2f2cc2f6e0677763f8d57e >> author: Jacob Moody >> date: Sat Aug 24 12:58:31 EDT 2024 >> >> lib9p: verify uname against returned AuthInfo from factotum (thanks humm) >> >> Before this it was possible to Tauth and Tattach with one >> user name and then authenticate with factotum using a different >> user name. To fix this we now ensure that the uname matches the returned >> cuid from AuthInfo. >> >> This security bug is still pending a cute mascot and theme song. >> >> >> mein name ist hase. bye. >