NetBSD Problem Report #23678

Received: (qmail 7762 invoked by uid 605); 6 Dec 2003 19:52:00 -0000
Message-Id: <20031206195200.7761.qmail@mail.netbsd.org>
Date: 6 Dec 2003 19:52:00 -0000
From: Christian Biere <christianbiere@gmx.de>
Sender: gnats-bugs-owner@NetBSD.org
To: gnats-bugs@gnats.netbsd.org
Subject: send-pr could be a little more secure
X-Send-Pr-Version: 3.95

>Number:         23678
>Category:       bin
>Synopsis:       send-pr could be a little more secure
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bin-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sat Dec 06 19:53:00 +0000 2003
>Closed-Date:    
>Last-Modified:  Sun Dec 07 17:53:00 +0000 2003
>Originator:     
>Release:        NetBSD 1.6ZF
>Organization:
>Environment:
System: NetBSD cyclonus 1.6ZF NetBSD 1.6ZF (STARSCREAM) #0: Sun Nov 30 01:56:21 CET 2003 bin@cyclonus:/usr/build/obj/sys/arch/i386/compile/STARSCREAM i386
Architecture: i386
Machine: i386
>Description:
Although, it's strictly discouraged to mail confidential PRs to GNATS ATM,
send-pr could be a little more secure. E.g., I would use to create the
mail and mail it to the security-officer. Imagine, the admin finds a
security bug and uses send-pr to report. Unless the admin hasn't set
TMPDIR to a private directory and/or uses umask 077 any local user can
read the PR for a short time before it's mailed or much longer in case
sendmail fails resp. send-pr is aborted to procede with the method
mentioned above. Further, it's recommended to use mktemp for temporary
files - which also creates files with mode 600.

>How-To-Repeat:

Use send-pr and look in $TMPDIR.

>Fix:

--- send-pr	2003-11-29 23:29:54.000000000 +0100
+++ send-pr	2003-12-06 20:36:23.000000000 +0100
@@ -20,6 +20,9 @@
 # along with GNU GNATS; see the file COPYING.  If not, write to
 # the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.

+# Be paranoid per default; this might be a confidential PR.
+umask 077
+
 # The version of this send-pr.
 VERSION=3.95

@@ -82,9 +85,19 @@
   fi
 fi

-TEMP=$TMPDIR/p$$
-BAD=$TMPDIR/pbad$$
-REF=$TMPDIR/pf$$
+if [ ! -x "`command -v mktemp`" ]; then
+	echo 'mktemp not found; send-pr will use more predictable temporary files.'
+	echo 'Press <ENTER> to continue...'
+	read input
+
+	TEMP=$TMPDIR/p$$
+	BAD=$TMPDIR/pbad$$
+	REF=$TMPDIR/pf$$
+else
+	TEMP=`mktemp -t p$$` || exit
+	BAD=`mktemp -t pbad$$` || exit
+	REF=`mktemp -t pf$$` || exit
+fi

 # find a user name
 if [ "$LOGNAME" = "" ]; then
>Release-Note:
>Audit-Trail:

From: "Greg A. Woods" <woods@weird.com>
To: Christian Biere <christianbiere@gmx.de>
Cc: NetBSD GNATS submissions and followups <gnats-bugs@gnats.netbsd.org>,
  NetBSD Bugs and PR posting List <netbsd-bugs@NetBSD.ORG>
Subject: Re: bin/23678: send-pr could be a little more secure
Date: Sun, 7 Dec 2003 12:52:08 -0500 (EST)

 [ On , December 6, 2003 at 19:52:00 (-0000), Christian Biere wrote: ]
 > Subject: bin/23678: send-pr could be a little more secure
 >
 > Imagine, the admin finds a
 > security bug and uses send-pr to report. Unless the admin hasn't set
 > TMPDIR to a private directory and/or uses umask 077 any local user can
 > read the PR for a short time before it's mailed or much longer in case
 > sendmail fails resp. send-pr is aborted to procede with the method
 > mentioned above.

 While I think worrying over the privacy of something that's eventually
 going to be published to the public, even if in a semi-confidential
 manner is kinda silly, I'd also like to point out that any admin not
 setting TMPDIR to an already private directory, probably under their
 $HOME, is a far greater and more generic security issue.  System
 administrators really should treat their own personal account with as
 much, or perhaps even greater, care as they treat the superuser account,
 especially if they use "su" from their account.

 -- 
 						Greg A. Woods

 +1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
 Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>
>Unformatted:

Home	PR Database Search