Re: lynx-dev Lynx 2.8.3 with nmh problems

[T.E.Dickey]

> 
> 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. 
yes (I should have said 0111 or similar).
>  
> 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. 

we can make it more fool-proof by repairing umask (otherwise any
directories that lynx creates in dired mode would be unusable as well)
  
> 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. 
the temp subdir is the piece that I needed to work around the code that
appends to and reuses temp-files (those are not secure in the sense that
the recent complaints about temp-file manipulation don't need any other
examples).
  
> 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? 

cannot reliably determine that no one's using a symbolic link to make lynx
write files that it shouldn't.

> 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 

yes (unless for example you put the TMPDIR in your home directory).
I could relax the check a little if I didn't know that some machine's
t-bit doesn't prevent renaming of files (not iirc directories though).
  
> 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. 

then the mkdir will fail and/or the permissions and ownership check will
fail - but lynx won't create other files.

> Or attacker could modify the underlying directory (the original 
> 'lynx_temp_space').  That either will make the mkdir() fail - opening 

no - mktemp only makes a name - doesn't touch the filesystem

The mkdir is the only operation that has to succeed or fail (if it already
exists, it will fail; the permissions check is to ensure that we don't lose
a race against someone renaming things).

> 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 


-- 
Thomas E. Dickey  <address@hidden>
http://dickey.his.com
ftp://dickey.his.com

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