Subject: so, just how many library environment variables can specify filnames?????
To: None <tech-kern@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-kern
Date: 11/20/2000 18:20:42
[ On Monday, November 20, 2000 at 16:52:10 (-0600), John Darrow wrote: ]
> Subject: Re: Addition to force open to open only regular files
>
> Greg, you completely missed it.  He *did* show you ACCESS, the /etc/passwd
> file was _READ_, and _that_ is what updated its 'last update' timestamp.

Oops.  I see it now!

I didn't think the zoneinfo library was that broken.

I would have thought that someone would have caught that by now -- it's
almost serious enough to be a CERT report, and I'll bet there are
several people actively working on discovering exploits at this moment.

> >Note also that CVS in particular explicitly does not support being
> >executed as a set-ID program *and* it even rejects being run as root.
> 
> That's funny... I run CVS as root all the time...

You must have hacked it to turn off the default setting of CVS_BADROOT then.

> Um... see above...  TZ is treated as a filename, just like HOSTALIASES...
> now try deprecating TZ and see how many people scream...

Well in TZ's case all that needs deprecating is the ability to specify a
tzfile in TZ.  I suspect the only people using that feature on a regular
basis are developers doing testing.


It's rather disturbing to find so many imporant library routines have
had these dangerous features creep into them relatively unnoticed.  I'm
still not terribly concerned about affecting things like rewind-on-close
tape devices, but in this particular case the "file" is apparently read
unconditionally in its entirety and that's just not acceptable!

User-supplied data should never ever be accepted without very careful
examination and inherent distrust in a privileged program of any kind.

I guess it is long past the time to sweep /usr/src/lib for calls to
getenv()!  It probably also makes a lot of sense for all set-ID programs
to always completely sanitize their environments where possible.

(and this particular branch of this thread should migrate to
tech-security if it's to continue, just as I've implied with the
reply-to in this message!)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>