lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Lynx 2.8.3 with nmh problems


From: Klaus Weide
Subject: Re: lynx-dev Lynx 2.8.3 with nmh problems
Date: Mon, 8 May 2000 11:55:34 -0500 (CDT)

On Mon, 8 May 100, T.E.Dickey wrote:

> > Okay, here's a partial explanation.  When invoked through nmh, the 
> > temporary directory's permissions appear to be not 700 but 600, even 
> > though the strace clearly calls mkdir with mode 700.  Obviously this 
> > prevents creation of the temporary file. 
> 
> If someone along the way has set your umask to 0222 or similar (such
> as 0200), that would produce this result.

Apparently either mhnshow or metamail does a umask() that the lynx
process inherits.  But it is the 'x' bit, not the 'w' bit, that
is missing.

Simulating this, I get (src/lynx is "nearly 2.8.3", using temp subdirs):
 $ umask
 002            # normal umask for this user
 $ src/lynx .   # works fine
 $ umask 113    # mask 'x' bits
 $ src/lynx .   # fails
 $ umask 222    # mask 'w' bits
 $ src/lynx .   # fails
 $ umask 446    # mask 'r' bits
 $ src/lynx .   # fails

In contrast: (/usr/local/bin/lynx is some 2.8.3dev.X, before introducing
temp subdirs)
 $ umask
 002            # normal umask for this user
 $ /usr/local/bin/lynx .   # works fine
 $ umask 113               # mask 'x' bits
 $ /usr/local/bin/lynx .   # works fine
 $ umask 222               # mask 'w' bits
 $ /usr/local/bin/lynx .   # works fine
 $ umask 446               # mask 'r' bits
 $ /usr/local/bin/lynx .   # fails

("works fine" / "fails" = History Page can / cannot be accessed)

So lynx stopped working in some situations, where earlier versions
did work.  There is no dunctional reason for it.  It makes sense for
some program (mhnshow, metamail) that can invoke arbitrary helpers
and (directly or indirectly) save arbitrary files to disk to disable
the 'x' bit; or at least, I can see the logic.  This shouldn't make
lynx fail.

Solutions:
 1- Fix temp subdir creation so that it doesn't depend on assumptions
    about current umask.
 2- Don't use a temp subdir at all.  Revert to previous logic.  If I
    say LYNX_TEM_SPACE=something, then "something" is what I should
    get.

CHANGES says:
2000-03-26 (2.8.3dev.23)
* on initialization, check if the LYNX_TEMP_SPACE denotes a directory which
  we cannot easily determine if someone could alter our temp-files.  If so,
  make a subdirectory of that, with appropriate permissions -TD

What does "we cannot easily determine..." exactly mean?
It seems (observed behavior, I didn't examine code) that a subdir is now
always created, within a completely "normal" TMPDIR:
   $ ls -ld /tmp
   drwxrwxrwt   36 root     root        18432 May  8 10:08 /tmp

So TD seems to claim that someone could alter temp-files if they were
created directly under this /tmp.  Ar at least, that it's not easily
possible to exclude the possibility.  I disagree.  If this were the
case, all previous versions of lynx would be seriously broken (much
more than we know to be the case).

I find these undocumented changes disturbing.
It has never been explained why they are necessary, and I question
whether they actually increase security.  

Looking at LYMain.c now, there is still a window between
'mktemp(lynx_temp_space)' and 'mkdir(lynx_temp_space, 0700)' where an
attacker could create a file or directory or link with the same name.
Or attacker could modify the underlying directory (the original
'lynx_temp_space').  That either will make the mkdir() fail - opening
a new denial-of-service atack against the lynx user, since lynx will
then exit -; or (if the original 'lynx_temp_space' was not safe and
has been replaced by a link etc.) mkdir() may succeed, creating the
subdir in a bad place, so all the checks done each time a temp file
is created will still be needed (just as before, when no subdir was
involved).


   Klaus


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]