[ On Thursday, August 19, 2004 at 13:52:05 (+0200), Christian Biere wrote: ]
> Subject: Re: Image browser
>
> Safety, sanity and security have their prizes e.g., well-known, maintained
> libraries instead of doing everything on its own.

Which is perhaps one of the reasons why XV does use well-known,
maintained, libraries instead of doing everything on its own.  ;-)

Of course the tragedy of the commons is that everyone standing in the
same place at the same time gets blown up by just one bomb while those
that are off doing it on their own often require specific and unique
attention in order for threats against them to be realized.

I.e. If your threat profile is such that you don't risk targeted attack
as much as you risk being caught unexpected by a "mass-market"
vulnerability then it's best not to run the same code as everyone else.
I don't expect anyone to attack me directly for just what I have, or if
they do then I don't expect them to target my particular ways of using
something like XV since there are many much less difficult ways for them
to get at me.  However if some exploit is found for something like
libjpeg then I've got to install the fix since I do on occasion use XV
(and other libjpeg callers) to view untrustable JPEG data.

Of course if all the Windoze users wake up and learn about this then
maybe I'll have to start using Windoze!  ;-)  I.e. we can't expect
everyone to code up their own software from scratch all the time.


> Especially since xv is so old,

"old"!?!?!?  That must be one of those "eye of the beholder" problems.

XV _is_ mature, but in the software world that's a _VERY_ goood thing.


> I'd guess that
> its bugs are widely known

Perhaps.  If find as a user that it's very bug-free actually.

> and exploits are at least passively used.

Exploits?  What exploits?  As has been said already, crashing something
by feeding it a junky command-line doesn't mean it's exploitable and
indeed anyone using wrapper code that would pass a filename through to
the "vulnerable" thing unsanitized is only getting what they deserve and
it's almost none of, in this case, XV's fault.  I.e. the filename given
by the "sender", e.g. in a MIME attachment, is also untrustable data
from the network and the real fault would lie in whatever code trusted
that filename, not in any tool like XV which expects to be invoked with
a sane and proper command line by other trusted code or directly by a
human who should know what he or she is doing to him or herself.  As you
say XV's command-line is not available to the network and it's not used
like a web browser either (i.e. it's not a network client, and it
especially does not knowingly accept command-line parameters from
untrusted sources).

(That said I just "discovered" the other day that Emacs VM fails even to
properly quote filenames it passes to external viewers like XV, let
alone sanitize them and I have to remember to fix that before I forget it!)

> Think again. xv uses sprintf() instead of snprintf() and it uses *a lot*
> of local (stack-based) buffers with arbitrary sizes, often as low as
> 64 byte to hold a filename... If none of this isn't exploitable, I'd be
> utmost suprised.

I think you may be judging the book by its cover.  Just because you
think some function or coding practice might be unsafe doesn't mean that
the final implementation has been left unsafe.  It is after all possible
to write very secure code even when using the most insecure coding
practices -- it's just often more difficult to do, and often more
difficult to maintain afterwards.  However with mature software which
needs little maintenance that's not such a big worry -- you're more
likely to bugger it up by trying to "fix" the problems that it doesn't
really have.

If you've found other real bugs then I'm sure all of those of us who use
XV daily will appreciate it if you'd file another PR about them.

After all software only goes on being unmaintained if those that see
problems in it are not willing or able to report those problems so that
someone might be able to fix them.

As you noticed we do have a very tried and true way of maintaining
patches for add-on software in pkgsrc even if the "official" maintainer
of a package is slow at doing his or her job.  Coincidentally since
NetBSD pkgsrc is also a "open source" the patches it contains can also
be considered to be "published" and thus even non-NetBSD users can
benefit from them -- they need only have the desire to look for more
fixes for the software they use.

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>