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

[Klaus Weide]

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

> > Relying on rand() for security is really a bad design choice, IMO. 
> 
> otoh, it improved on what was there (addressed the immediate cause for
> concern).  

Yes - slightly, IMO.

> I don't believe that any of us can come up with a completely
> secure scheme (nor could the critics ;-).  

Why not?  (I assume we are talking about temp files; for the Options Menu
"secret", there really isn't any need for secure secrets to protect against
"spoofing" from outside.)

Not for all situations of course.  For example, if O_CREAT|O_EXCL is
broken in the underlying filesystem, there isn't much we can do about
it.  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.

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

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

Btw, I think

    counter = ( 10000.0 * rand() ) / RAND_MAX;

should be

    counter = ( 10000.0 * rand() ) / (RAND_MAX+1.0);

if you always want to have 4 digits or less.

Using random numbers for temp filenames opens up a small chance, about
one-in-10000, for name collisions.  Therefore a chance for very
obscure, and hard to reproduce, bugs.  (Say a user visits the LYNXCFG:
page, but that page, normally supposed to be long-lived unless a
LYNXCFG://reload is activated, has been quietly replaced by some other
temp file - so the user will see the content of the latest
'd'ownloaded HTML file, or a source cache file, if that happend to get
the same filename.)  Given enough Lynx users, and enough somewhat
long-lived Lynx sessions, this is bound to happen somewhere, to
someone.  For someone with a devious mind, this may even open up a
new avenue for spoofing - the chance to replace the Option Menu's temp
file with arbitrary content.  (I don't know how likely it is that this
can be exploited, or what skills and extra knowledge it would take.
Just the theretical chance is enough to avoid creating filenames like
this, IMO.)

Of course, something like this could also happen with sequential
numbering, but *only* in a session that is long enough that the counter
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

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

  Klaus