From root@asarian-host.net  Tue Jan  7 12:10:03 2003
Return-Path: <root@asarian-host.net>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 5BB2137B401
	for <freebsd-gnats-submit@freebsd.org>; Tue,  7 Jan 2003 12:10:03 -0800 (PST)
Received: from asarian-host.net (a194-109-160-70.adsl.xs4all.nl [194.109.160.70])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 0007A43EB2
	for <freebsd-gnats-submit@freebsd.org>; Tue,  7 Jan 2003 12:10:01 -0800 (PST)
	(envelope-from root@asarian-host.net)
Received: (from root@localhost)
	by asarian-host.net (8.12.6/8.12.6) id h07K9xuT000679
	for freebsd-gnats-submit@freebsd.org; Tue, 7 Jan 2003 21:09:59 +0100 (CET)
	(envelope-from root@asarian-host.net)
Message-Id: <200301072009.H07K9VMJ000670@asarian-host.net>
Date: Tue, 7 Jan 2003 21:09:57 +0100 (CET)
From: System Administrator <root@asarian-host.net>
Reply-To: Superuser <root@asarian-host.net>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: security vulnerability in dump
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         46838
>Category:       bin
>Synopsis:       security vulnerability in dump
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jan 07 12:20:01 PST 2003
>Closed-Date:    Mon Jan 13 19:28:32 PST 2003
>Last-Modified:  Mon Jan 13 19:28:32 PST 2003
>Originator:     Superuser
>Release:        FreeBSD 4.7-RELEASE i386
>Organization:
Asarian-host
>Environment:
System: FreeBSD asarian-host.net 4.7-RELEASE FreeBSD 4.7-RELEASE #0: Sat Nov 30 17:01:16 CET 2002 root@asarian-host.net:/usr/obj/usr/src/sys/ASARIAN-HOST i386


	
>Description:

I believe I have found a security vulnerability in dump, which, under the right conditions, allows any user with shell-access 
to gain root-privileges.

When dumping to a file, dump writes this file chmod 644. When the root-partition is being backed-up, this leaves the dump-file 
vulnerable to scanning by unprivileged users for the duration of the dump.

I tested this, and, as a non-privileged user, was able to extract the root-password from the dump-file using a simple
regex: "(/root:(.*?):0:0::0:0:Superuser:/)". This, of course, based on the fact that /etc/master.passwd also becomes part of
the dump-file.

My greater point would be that the "run-length" storage of dump, since the file is chmod 644, effectively renders all files it 
backups world-readable as it passes them along for processing. At least for the duration dump is running (assuming a 
backup-script would be sensible enough to change permissions directly thereafter).

As to how high to rank this exploitability, I am not entirely sure; but I lean to deeming it high, because once the eploit is 
known, exploiting it is rather easy. Certain conditions need to be met. The dump must be made to file, and the unprivileged
user must, naturally, know the name of the dump-file; and the dump, of course, must be made in
multi-usermode.

>How-To-Repeat:
	make a dump to file. :)
>Fix:

The fix, fortunately, is very easy: if the FreeBSD development team made a small adjustment to dump, writing its dump-file
chmod 600, then this would immediately solve any and all exploitability.

>Release-Note:
>Audit-Trail:

From: David Malone <dwmalone@maths.tcd.ie>
To: System Administrator <root@asarian-host.net>
Cc: FreeBSD-gnats-submit@FreeBSD.org
Subject: Re: bin/46838: security vulnerability in dump
Date: Tue, 7 Jan 2003 20:32:11 +0000

 On Tue, Jan 07, 2003 at 09:09:57PM +0100, System Administrator wrote:
 > When dumping to a file, dump writes this file chmod 644. When the
 > root-partition is being backed-up, this leaves the dump-file 
 > vulnerable to scanning by unprivileged users for the duration of the dump.
 
 I've tested dump in -current, and it creates the file with the mode
 dictated by my umask. I believe this is the correct behaviour - if
 you want your dumps created with a more restrictive mode I'd suggest
 running "umask 077" before running dump.
 
 I'll close the PR if this explains the problem you are seeing.
 
 	David.

From: Mark <admin@asarian-host.net>
To: "David Malone" <dwmalone@maths.tcd.ie>
Cc: <FreeBSD-gnats-submit@freebsd.org>
Subject: Re: bin/46838: security vulnerability in dump
Date: Tue, 7 Jan 2003 21:45:10 +0100

 ----- Original Message -----
 From: "David Malone" <dwmalone@maths.tcd.ie>
 To: "System Administrator" <root@asarian-host.net>
 Cc: <FreeBSD-gnats-submit@FreeBSD.org>
 Sent: Tuesday, January 07, 2003 9:32 PM
 Subject: Re: bin/46838: security vulnerability in dump
 
 > On Tue, Jan 07, 2003 at 09:09:57PM +0100, System Administrator wrote:
 >
 > > When dumping to a file, dump writes this file chmod 644. When the
 > > root-partition is being backed-up, this leaves the dump-file vulnerable
 > > to scanning by unprivileged users for the duration of the dump.
 >
 > I've tested dump in -current, and it creates the file with the mode
 > dictated by my umask. I believe this is the correct behaviour - if
 > you want your dumps created with a more restrictive mode I'd suggest
 > running "umask 077" before running dump.
 >
 > I'll close the PR if this explains the problem you are seeing.
 >
 > David.
 
 I realize running "umask 077" will prevent this problem. But I also believe
 dump is a special case, as most individual programs do not create
 world-readable files containing root's view of the filesystem data.
 
 Just as the correct permissions on /etc/master.passwd are also not dependent
 upon root's umask, so dump-files should, imho, not rely on this, hopefully,
 correctly set external factor. Instead, dump should be safe on its own.
 
 - Mark
 
         System Administrator Asarian-host.org
 
 ---
 "If you were supposed to understand it,
 we wouldn't call it code." - FedEx
 

From: Peter Pentchev <roam@ringlet.net>
To: David Malone <dwmalone@maths.tcd.ie>
Cc: Mark <admin@asarian-host.net>, bug-followup@FreeBSD.org
Subject: Re: bin/46838: security vulnerability in dump
Date: Wed, 8 Jan 2003 14:27:23 +0200

 On Tue, Jan 07, 2003 at 09:15:47PM +0000, David Malone wrote:
 > On Tue, Jan 07, 2003 at 12:50:04PM -0800, Mark wrote:
 > >  I realize running "umask 077" will prevent this problem. But I also believe
 > >  dump is a special case, as most individual programs do not create
 > >  world-readable files containing root's view of the filesystem data.
 > 
 > Just about any command can create world readable files containing
 > root's view of a filesystem: cp, tar, cat, dd.  I'd also expect
 > that people may use dump to create (say) group readable files which
 > can be restored by those in group operator, or somesuch.
 
 This may be mollified even further by a sensible directory hierarchy of
 the location that filesystem dumps are kept: I personally *always*
 create dumps and backup archives in a directory that is in itself
 protected by permissions-based access control.  The default FreeBSD
 setup sets a good example by providing a /var/backups directory by
 default, which is only writeable by root and readable by the 'wheel'
 group.
 
 > If there's a general consensus for change, I'll go along with it -
 > otherwise I'll close the PR as one of the many ways unix offers you
 > to shoot yourself in the foot.
 
 FWIW, I concur - most of the Unix utilities provide you with the ability
 to shoot yourself in the foot if you so desire, indeed :)
 
 G'luck,
 Peter
 
 -- 
 Peter Pentchev	roam@ringlet.net	roam@FreeBSD.org
 PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
 Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
 I am jealous of the first word in this sentence.

From: Mike Makonnen <mtm@identd.net>
To: Mark <admin@asarian-host.net>
Cc: dwmalone@maths.tcd.ie, bug-followup@FreeBSD.ORG
Subject: Re: bin/46838: security vulnerability in dump
Date: Mon, 13 Jan 2003 22:16:11 -0500

 --=.WJ?3FuoBs)a_US
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: 7bit
 
 > > I have to agree with David here. Dump should not hard code any file
 > > creation modes. We have no way of anticipating (or the right to dictate)
 > > how an administrator should run his system. However, it probably
 > > deserves a mention in the man page. Does the following patch address
 > > your concerns?
 > > 
 > > Cheers.
 
 I have had it reviewed by Sheldon and he is against this.
 The basic argument is that this should be SysAdmin 101 (i.e. - it's the
 administrator's responsibility to realize this). It's impractical to add this
 change to all programs that could be abused in this way. I think he actually has
 a point here, if this gets through then we wouldn't have much ground for
 refusing similar changes to other programs.
 
 In short, even if I committed this against his wishes I think there would be too
 much resistance from other developers to bother.
 
 Thanks for the submission, though.
 
 Cheers.
 -- 
 Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
 mtm@identd.net | Fingerprint: D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9
 
 --=.WJ?3FuoBs)a_US
 Content-Type: application/pgp-signature
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.1 (FreeBSD)
 
 iD8DBQE+I4D82uHir9vMaLkRAux8AKCnSwc8CtyfoOBAlKoGp+FxN1ObswCfbTtY
 tXJGV+KTfiYCD7EpWWgTe9s=
 =Lq8m
 -----END PGP SIGNATURE-----
 
 --=.WJ?3FuoBs)a_US--
State-Changed-From-To: open->closed 
State-Changed-By: mtm 
State-Changed-When: Mon Jan 13 19:24:58 PST 2003 
State-Changed-Why:  
"... one of the many ways unix offers you the ability to 
shoot yourself in the foot" 
-- dwmalone 

http://www.freebsd.org/cgi/query-pr.cgi?pr=46838 
>Unformatted:
