[Top][All Lists]

[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 16:38:05 -0500 (CDT)

> > 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. 
On Mon, 8 May 100, T.E.Dickey wrote:
> we can make it more fool-proof by repairing umask (otherwise any
> directories that lynx creates in dired mode would be unusable as well)

I didn't think about dired; but I think we shouldn't "repair umask".
If lynx gets invoked with a certain umask, in general the assumption
should be that that's what is desired.

If a user creates a directory with some dired function, it may end up
with weird permissions, but (given default --enable-dired-* settings
in effect, no extra restrictions) the user can still repair the permissions
manually (as in 'm'odify, 'p'ermissions).

That's different from the subdir for tempfiles.  In order to work at all,
it needs 'x' (search) permission.  So let's just set the u+x bit for this
special case.

> > 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

Which code do you mean?  LYOpenTempRewrite, or something else?

Using egrep -ni '"a[t]?[+]?"|LYAppendToTxtFile|TXT_A|ReopenTemp',
I could find only these cases where a *temporary* file is opened for

  - in LYMail.c, for appending signature to a message;
  - in LYNews.c, for appending signature to a message;
  - in LYOpenTempRewrite().  This is safe, since LYReopenTemp
    is only called if the file exists and we have verified that it

In other places, the file being appended is not a temp file in the
temp space (LYBookmark.c), or the code is dead [LYPrint.c: (TOUPPER(c) == 'A')
can't be true].

> (those are not secure in the sense that
> the recent complaints about temp-file manipulation don't need any other
> examples).

I don't understand this sentence.  Please rephrase...

> > 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).

Well, not on this machine.  Not in most sane environments, right?
So I'd like to be able to configure lynx such that this unnecessary
extra stuff is not in it.

> > 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.

Which checks do you mean - the ones preceding mktemp/mkdir, or later
on (in LYUtils.c)?

> > 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

I see the following system calls generated from

            if (mktemp(lynx_temp_space) == 0
             || mkdir(lynx_temp_space, 0700) < 0) {

(TMPDIR is "/usr/src/tmp" here):

   gettimeofday({957816451, 396599}, NULL) = 0
   getpid()                                = 25972
   stat("/usr/src/tmp/Rc8kfD", 0xbffff660) = -1 ENOENT (No such file or 
   mkdir("/usr/src/tmp/Rc8kfD", 0700)      = 0

The stat is from mktemp().  It doesn't "touch" the filesystem in the
sense of writing anything, but it has to check whether a file exists.

> The mkdir is the only operation that has to succeed or fail (if it already
> exists, it will fail; 

... thereby giving an attacker a way to prevent my lynx process from
running - if he can guess the filename (just one) for the directory
and create it at the right moment.

Can you see why I don't want this code, or want a way to suppress it?

After all, I might be running lynx with -dump or -source, from a cron
job or cgi script etc., such that no temp file will ever be generated.
This used to work fine, even if TMPDIR points to a nonexisting or
non-writable place.  This used to work.  Now it doesn't:

   $ TMPDIR=/does/not/exist src/lynx -dump http://localhost
   /does/not/exist/Tdql9w: No such file or directory

So now I'm forced to give the lynx process write access at least somwhere
in the filesystem.  Before, I didn't have to.  (assuming simple enough
mailcap files that don't involve temp files for running tests.)

I sense a definite trend towards microsoftification of lynx...

> the permissions check is to ensure that we don't lose
> a race against someone renaming things).

You seem to mean the stuff in OpenHiddenFile and IsOurFile.  Right?

So if I understand you right, stuff added in LYMain.c (subdir creation)
doesn't make the stuff in LYUtils.c any less necessary.  That's basically
what I meant.  In addition, if the stuff in LYUtils.c continues to be
necessary, I'm still not sure what is gained by adding the stuff in
LYMain.c - except for those "t-bit doesn't prevent renaming of files"
machines, maybe.  But attemps to fix things up for those sick machines
shouldn't mess up things for more sane environments.  Shouldn't even
result in unnecessary directory creation overhead for the latter, even
if there were no other adverse effects, IMO.


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

reply via email to

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