NetBSD Problem Report #54947

From root@pip.kardel.name  Sat Feb  8 08:46:42 2020
Return-Path: <root@pip.kardel.name>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id A6D971A921A
	for <gnats-bugs@gnats.NetBSD.org>; Sat,  8 Feb 2020 08:46:42 +0000 (UTC)
Message-Id: <20200208084637.ED58CDA0D9C@pip.kardel.name>
Date: Sat,  8 Feb 2020 09:46:37 +0100 (CET)
From: kardel@netbsd.org
Reply-To: kardel@netbsd.org
To: gnats-bugs@NetBSD.org
Subject: chroot mount file systems leak the actual path in superblock
X-Send-Pr-Version: 3.95

>Number:         54947
>Category:       kern
>Synopsis:       mount within a chroot environment leak te actual path in the superblock
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Feb 08 08:50:00 +0000 2020
>Closed-Date:    Mon Aug 03 08:50:14 +0000 2020
>Last-Modified:  Mon Aug 03 08:50:14 +0000 2020
>Originator:     Frank Kardel
>Release:        NetBSD 9.99.45
>Organization:

>Environment:


System: NetBSD pip 9.99.45 NetBSD 9.99.45 (PIPGEN) #7: Wed Feb 5 19:24:51 CET 2020 kardel@pip:/src/NetBSD/act/src/obj.amd64/sys/arch/amd64/compile/PIPGEN amd64
Architecture: x86_64
Machine: amd64
>Description:
Mount a file system from within a chroot environment will leak the
 actual path.

 #pip: 9:27 / [30]# mount /dev/dk1 /targetroot
 #pip: 9:28 / [31]# umount /targetroot/
 #pip: 9:29 / [32]# fsdb -nf /dev/rdk1
 ** /dev/rdk1 (NO WRITE)
 ** File system is already clean
 Editing file system `/dev/rdk1'
 Last Mounted on /targetroot
 current inode: directory
 I=2 MODE=40755 SIZE=2048
          MTIME=Feb  2 10:15:11 2020 [0 nsec]
          CTIME=Feb  5 21:37:33 2020 [233878482 nsec]
          ATIME=Feb  5 21:43:52 2020 [313125735 nsec]
 OWNER=root GRP=wheel LINKCNT=33 FLAGS=0x0 BLKCNT=0x8 GEN=0x58ed0e25
 fsdb (inum: 2)> q
 Exit 255
 #pip: 9:29 / [33]# chroot /src/NetBSD/act/BUILD.amd64
 pip# fsdb -nf /dev/rdk1
 ** /dev/rdk1 (NO WRITE)
 ** File system is already clean
 Editing file system `/dev/rdk1'
 Last Mounted on /targetroot
 current inode: directory
 I=2 MODE=40755 SIZE=2048
          MTIME=Feb  2 09:15:11 2020 [0 nsec]
          CTIME=Feb  5 20:37:33 2020 [233878482 nsec]
          ATIME=Feb  5 20:43:52 2020 [313125735 nsec]
 OWNER=root GRP=wheel LINKCNT=33 FLAGS=0x0 BLKCNT=0x8 GEN=0x58ed0e25
 fsdb (inum: 2)> q
 pip# mount /dev/dk1 /targetroot
 pip# umount /targetroot
 pip# fsdb -nf /dev/rdk1
 ** /dev/rdk1 (NO WRITE)
 Editing file system `/dev/rdk1'
 Last Mounted on /src/NetBSD/act/BUILD.amd64/targetroot
 current inode: directory
 I=2 MODE=40755 SIZE=2048
          MTIME=Feb  2 09:15:11 2020 [0 nsec]
          CTIME=Feb  5 20:37:33 2020 [233878482 nsec]
          ATIME=Feb  5 20:43:52 2020 [313125735 nsec]
 OWNER=root GRP=wheel LINKCNT=33 FLAGS=0x0 BLKCNT=0x8 GEN=0x58ed0e25
 fsdb (inum: 2)> q
 pip#
>How-To-Repeat:
	see above
>Fix:
	check mount system call

>Release-Note:

>Audit-Trail:
From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org,
 gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org
Subject: Re: kern/54947: chroot mount file systems leak the actual path in
 superblock
Date: Sat, 8 Feb 2020 11:27:40 -0500

 --Apple-Mail=_525BB5EF-7C6C-420B-9FF3-5BD1D18DFA4A
 Content-Transfer-Encoding: quoted-printable
 Content-Type: text/plain;
 	charset=us-ascii

 1. There is nothing to be done about it; the part is recorded inside the =
 superblock.
 2. One should not be making device nodes with access to physical devices =
 in the chroot.
     Getting the path from the superblock is the least of the concerns if =
 you give root access
     inside a chroot...
 3. This is purely an information leak. The same can happen if you plug =
 in a usb fob that
     has a filesystem on it, and the information you get on it is not =
 very useful.

 christos

 --Apple-Mail=_525BB5EF-7C6C-420B-9FF3-5BD1D18DFA4A
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
 	filename=signature.asc
 Content-Type: application/pgp-signature;
 	name=signature.asc
 Content-Description: Message signed with OpenPGP

 -----BEGIN PGP SIGNATURE-----
 Comment: GPGTools - http://gpgtools.org

 iF0EARECAB0WIQS+BJlbqPkO0MDBdsRxESqxbLM7OgUCXj7hfAAKCRBxESqxbLM7
 OnS4AJ41vtXheH31Cf8Yk0A1dMy3fhgzhgCgwbYEwZFLnsBIC9S2NsxN8k8Dsz4=
 =jMJM
 -----END PGP SIGNATURE-----

 --Apple-Mail=_525BB5EF-7C6C-420B-9FF3-5BD1D18DFA4A--

From: Frank Kardel <kardel@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/54947: chroot mount file systems leak the actual path in
 superblock
Date: Sat, 8 Feb 2020 18:19:04 +0100

 Yes, it is "just" an information leak.We found it while quick testing 
 sysinst from a chroot environment.

 sysinst gets confused in this case - see PR/54944.

 We might put that on the long list of information leaks we are plugging.

 Frank


 On 02/08/20 17:30, Christos Zoulas wrote:
 > The following reply was made to PR kern/54947; it has been noted by GNATS.
 >
 > From: Christos Zoulas <christos@zoulas.com>
 > To: gnats-bugs@netbsd.org
 > Cc: kern-bug-people@netbsd.org,
 >   gnats-admin@netbsd.org,
 >   netbsd-bugs@netbsd.org
 > Subject: Re: kern/54947: chroot mount file systems leak the actual path in
 >   superblock
 > Date: Sat, 8 Feb 2020 11:27:40 -0500
 >
 >   --Apple-Mail=_525BB5EF-7C6C-420B-9FF3-5BD1D18DFA4A
 >   Content-Transfer-Encoding: quoted-printable
 >   Content-Type: text/plain;
 >   	charset=us-ascii
 >   
 >   1. There is nothing to be done about it; the part is recorded inside the =
 >   superblock.
 >   2. One should not be making device nodes with access to physical devices =
 >   in the chroot.
 >       Getting the path from the superblock is the least of the concerns if =
 >   you give root access
 >       inside a chroot...
 >   3. This is purely an information leak. The same can happen if you plug =
 >   in a usb fob that
 >       has a filesystem on it, and the information you get on it is not =
 >   very useful.
 >   
 >   christos
 >   
 >   --Apple-Mail=_525BB5EF-7C6C-420B-9FF3-5BD1D18DFA4A
 >   Content-Transfer-Encoding: 7bit
 >   Content-Disposition: attachment;
 >   	filename=signature.asc
 >   Content-Type: application/pgp-signature;
 >   	name=signature.asc
 >   Content-Description: Message signed with OpenPGP
 >   
 >   -----BEGIN PGP SIGNATURE-----
 >   Comment: GPGTools - http://gpgtools.org
 >   
 >   iF0EARECAB0WIQS+BJlbqPkO0MDBdsRxESqxbLM7OgUCXj7hfAAKCRBxESqxbLM7
 >   OnS4AJ41vtXheH31Cf8Yk0A1dMy3fhgzhgCgwbYEwZFLnsBIC9S2NsxN8k8Dsz4=
 >   =jMJM
 >   -----END PGP SIGNATURE-----
 >   
 >   --Apple-Mail=_525BB5EF-7C6C-420B-9FF3-5BD1D18DFA4A--
 >   

From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/54947: chroot mount file systems leak the actual path in superblock
Date: Sun, 09 Feb 2020 03:31:47 +0700

     Date:        Sat,  8 Feb 2020 17:20:02 +0000 (UTC)
     From:        Frank Kardel <kardel@netbsd.org>
     Message-ID:  <20200208172002.2378E1A921A@mollari.NetBSD.org>

   |  Yes, it is "just" an information leak.We found it while quick testing 
   |  sysinst from a chroot environment.

 I think you're reading more into chroot than you should - it is a means
 to map pathnames in a way that protects the rest of the system from
 stray accesses, and allows the process inside the chroot to test
 operations (like manipulation of files in /etc or installation into
 standard bin or lib paths) without risking the live system.

 That's it.

 It isn't intended to hide just about anything, or provide any special
 security features, other than the pathname remapping it does.

 If you want a virtual machine, use one, chroot is not that.

 kre

From: coypu@sdf.org
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/54947: chroot mount file systems leak the actual path in
 superblock
Date: Sun, 9 Feb 2020 16:24:44 +0000

 It's worth noting that if you can mount a filesystem, you can likely
 perform raw writes to the underlying block.

 e.g. write malicious.kmod somewhere in /stand, and open a matching
 device in /dev, causing your malicious module to be loaded.

From: Paul Goyette <paul@whooppee.com>
To: coypu@sdf.org
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/54947: chroot mount file systems leak the actual path in
 superblock
Date: Sun, 9 Feb 2020 08:53:22 -0800 (PST)

 On Sun, 9 Feb 2020, coypu@sdf.org wrote:

 > It's worth noting that if you can mount a filesystem, you can likely
 > perform raw writes to the underlying block.
 >
 > e.g. write malicious.kmod somewhere in /stand, and open a matching
 > device in /dev, causing your malicious module to be loaded.

 Unless you are already root, you won't be able to install the module
 in /stand/$ARCH/$VERSION/modules/malicious/malicious.kmod (the default
 permissions for ..../modules is 0755)

 If you are already root, all bets are off anyway.


 +--------------------+--------------------------+-----------------------+
 | Paul Goyette       | PGP Key fingerprint:     | E-mail addresses:     |
 | (Retired)          | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com     |
 | Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org   |
 +--------------------+--------------------------+-----------------------+

State-Changed-From-To: open->closed
State-Changed-By: kardel@NetBSD.org
State-Changed-When: Mon, 03 Aug 2020 08:50:14 +0000
State-Changed-Why:
the informational leak cannot be easily resolved as correctness 
depends on the viewpoint (chroot/base system).


>Unformatted:

Home	PR Database Search