Re: lynx-dev Options, V.Links, random (was: patch 6 - UI Pages)

[Klaus Weide]

On Wed, 15 Dec 1999, T.E.Dickey wrote:

> temp-files is what we're talking about.
>   
> >      But I am still wondering whether the OpenHiddenFile()/IsOurFile() 
> > *is* spoof-proof on a sane system (and I admit I have never tried to 
> > completely understand that code - what with the directory traversal and 
> > uid check stuff...).  If it isn't secure on a sane system (non-broken 
> > filesystem etc.), using rand() may just detract from that fact. 
> 
> I don't see how rand() makes it less secure - it doesn't change the checks,
> but makes the selection of names less obvious (obviousness was the point of
> the criticism).

I should have said "distract" instead of "detract".  I.e., divert attention.

> > > However, using a sequential name 
> > > opens us up to criticism from people who don't concern themselves over 
> > > whether the underlying filesystems itself is secure.   
> >  
> > If they are wrong and we are right, we shouldn't listen to them. 
> 
> easy in principal, hard in practice.

Hard not to listen to people who are wrong?  I don't find that, and you
seem to do a good job of it yourself. :)

> > > Using rand() merely 
> > > guarantees that the average fool (i.e., "hacker") would not break in. 
> >  
> > While the skillful fool still may, I assume.  If he knows at which second 
> > srand() was called, the sequence of numbers should be completely 
> > reproduceable. 
> 
> if

It's not a big "if".  And it's just the sort of argument that comes up
in those bugtraq messages ("if" you choose to take them seriously...).
To quote from
        URL:
          
http://www.securityfocus.com/templates/archive.pike?list=1&msg=Pine.LNX.4.20.991116
          address@hidden

"[...] All you have to do is create evil webpage (in our example,
A.html). In it, ask websurfer [...] All you have to do is to
utime(...) on this file to determine 'secure' value.  If you can't see
what I'm talking about, stop now and read manpages for time(...) and
utime(...)."

[I don't know why he talks about utime() - stat() should be all that's
needed.  That text talks about the "secure" value, which doesn't
matter any more, but the same applies for getting the seed value used
now.]

If the first temp file is still around, you can get the second of its
creation, therefore the value used for srand(), therefore reconstruct
the whole sequence of random numbers.  Basically a no-brainer for
anyone serious, and the "advantage" of random numbers has evaporated.
Or am I completely missing something?

Now, we could try to improve this by using a more sophisticated seed
value.  Hmm, so what sources of randomness are there that can be
used portably?  Do we really want to get into this kind of race, and/or
leave some systems more vulnerable than others?

> > Using random numbers for temp filenames opens up a small chance, about 
> > one-in-10000, for name collisions.  Therefore a chance for very 
> 
> no - we already deal with name collisions (I did check that - it simply
> tries the next one on a failure).

I tested it, and find that you are wrong.  OpenHiddenFile removes the
previous incarnation if IsOurFile returns TRUE - just as I expected.
I am surprised that you expect differently - this is the behavior I
have learned to "program to".

Tested by running under gdb, and changing the value of counter in
fmt_tempname by hand at the right point, to simulate a collision.

More details:

$ ls -ld /tmp
drwxrwxrwt   4 root     root        18432 Dec 15 09:57 /tmp/

Lynx code is still dev.16 plus my changes (there should be no
significant difference to dev.17).  Started lynx with no command line
options, so that it goes to <http://lynx.browser.org/>.  SOURCE_CACHE
is FILE, so the first temp file crated is /tmp/L9366-1TMP.html and
contains the cached contents of <http://lynx.browser.org/>.  (Some
more temp files get created, in my case by UCChangeTerminalCodepage,
and I might visit some more pages which creates more SOURCE_CACHE temp
files - irrelevant as long as I don't stray far enough from the
startfile that it gets uncached.)

Now I invoke 'O' (with form-based Menu), fmt_tempname gets called to
create the filename for the Options Menu file, at this point i step in
and reset the counter to '1'.  Lynx will try to create
/tmp/L9366-1TMP.html again.  Stepping further through the code shows
that the existing /tmp/L9366-1TMP.html is detected in OpenHiddenFile,
recognized as "ours" by IsOurFile as it should, and removed in
OpenHiddenFile, then a new file by that name is created.

After temp file creation returns successfully, we have the following
unhealthy situation:

(gdb) p *ly_temp
$48 = {next = 0x81e14b0, name = 0x81e0e78 "/tmp/L9366-1TMP.html", file = 
0x81e1440}
(gdb) p *ly_temp->next
$49 = {next = 0x81e1418, name = 0x81e14c0 "/tmp/L9366-3TMP.uni", file = 0x0}
(gdb) p *ly_temp->next->next
$50 = {next = 0x81c1eb0, name = 0x81e1428 "/tmp/L9366-2TMP.fnt", file = 0x0}
(gdb) p *ly_temp->next->next->next
$51 = {next = 0x0, name = 0x81da448 "/tmp/L9366-1TMP.html", file = 0x0}
(gdb)

IOW "/tmp/L9366-1TMP.html" is being tracked twice.

What happens next is that the HTML for the Options Menu gets written to
/tmp/L9366-1TMP.html, no problem.  At this point, I decide to return to
the first page.  (I used the history list, other means should be
equivalent).  Ok, the page appears as it should, I see the contents of
<http://lynx.browser.org/> (it was cached in memory).  Now I decide to
view the SOURCE of <http://lynx.browser.org/>, and what appears on
pressing '\' is the source of the Options Menu instead.  Switching back
('\' again) shows the Options Menu.  What's more, pressing '=' now
shows a strange mixture:

File that you are currently viewing

   Linkname: Options Menu
        URL: http://lynx.browser.org/
    Charset: iso-8859-1
     Server: Apache/1.3.9 (Unix) PHP/3.0.12
       Date: Wed, 15 Dec 1999 15:19:33 GMT
   Owner(s): mailto:address@hidden
       size: 50 lines
       mode: forms mode

Link that you currently have selected

   Linkname: Accept Changes
     Method: POST
    Enctype: application/x-www-form-urlencoded
     Action: LYNXOPTIONS:/



> > Of course, something like this could also happen with sequential 
> > numbering, but *only* in a session that is long enough that the counter 
> 
> or with a session that crashes, or happens to use the same numbers as someone
> else.

You mean someone using the same pid?  I don't see how *that* creates a
problem.  The other process would have to be dead of course.  If it
belonged to the same user, no problem - obsolete file instance will be
overwritten, nobody needs it any more.  If it belonged to a different
user, no problem - the code should detect IsOurFile()==FALSE and iterate
until a free name is reached.

> > can wrap around.  In that case it would be easily predictable and easy 
> > to diagnose. 
> >  
> > If a random number component in the filename is really desired - how 
> > about using it *in addition* to a straightforward counter.  I.e., 
> >    /tmp/L<piddigits>-<randdigits>-<counterdigits>TMP.html 
> 
> total length was what I looked at - changing the counter to random used the
> same length as before.
>   
> > (If total length is a problem - 1. "L", "TMP", and hyphens could be 
> > done away with [but I prefer to have them, for matching]; 2. Windos/DOS 
> > already use a different format anyway and aren't "safe" anyway; 3. the 
> > names used now are already above a 14-character limit, so that old 
> > limit doesn't seem to matter; 4.  we could use less than 4 digit for 
> > <randdigits>.) 

I don't think lenght is a serious abstacle, see the 4 points, at most
an aesthetical matter.  But more importantly I still think filenames should
be generated as before.

  Klaus