Robin-David Hammond <[EMAIL PROTECTED]> wrote:
> in any case MC hasnt been rigorously analysed for buffer-overrun
> attacks afaik. Not only should you be cautious about using it for
> sensitive data, but also on any virtual file system with sensative
> or mission critical data, unless you are very sure that the
> permissions DONT allow it to write to disk, or read sensative
> data. still the active copy *in ram* may be rewritten, and you dont
> want to run MC out of inetd!
Certainly paranoia is warranted here, but you should keep in mind that
the average cobbled-together MetaCard server is going to be safer, at
least WRT to buffer-overrun security problems (the easiest to exploit
and most dangerous kind), than virtually any current open-source
server program. This is obviously the case when compared with the
FTP, HTTP, and BIND servers that are running on the majority of
Internet hosts out there, all of which have multiple security holes
like this, one of the buffer-overrun bugs in BIND (the DNS server)
being the single most commonly exploited security hole in any server
software.
> any door can be broken, with a lever long, and strong enough, but
> dont leave the door open.
With MetaCard your primary (and probably exclusive) risk would be in
executing commands or evaluating expressions that come from untrusted
sources. Any use of the "do" and "send" commands or the "value"
function should be very diligently evaluated to make sure that there
is no possibility of this occuring. Of course, you also have to be
careful about where you write files, but it's a relatively simple
matter to check a path for validity (e.g., don't allow a leading
"/", or the "..", ":", or "~" characters anywhere in a path).
> MC was built (in the image of HC) to make GUIs and be an OO database
> with advanced scripting capabilities, it now includes inet_socket
> functionality. do not assume that just because you can, you
> should. There are tried and true methods of sharing files
> SCP2,FTP,HTTP don't reinvent the wheel unnessesarily. write
> software to co-ordinate these underlying transactions to provide a
> nice GUI to people who need to access data without learning how
> technology works. keeps development time down, and reduces the
> complexity of your product, while reasuring the customers (end
> users) of compatability.
I certainly wouldn't rule out building or using MetaCard server
software, even for protocols for which well-known (if buggy) open
source software is widely available. While I don't see any big
advantage to writing an FTP server in MetaCard, an HTTP server that
executes CGI scripts is a different matter entirely and an area where
a MetaCard server could be safer and feature-competitive with any of
the alternatives.
> yes i am the first to admit i am rather opinionated on some of the
> issues here, that dosnt make me right/wrong.
I've got a soap box here too, and in *my* opinion, the ubiquity of
buffer-overrun bugs in open source software rises to the level of
criminal negligence. There is just no excuse for this kind of sloppy
programming, yet not a week goes by that yet another example of this
kind of thing isn't found in one of the commonly used open-source
packages. I wouldn't blindly trust Microsoft software either, but at
least the majority of the security holes in their products were put
there deliberately to improve the usability of the products rather
than as the result of poor security hygiene on the part of the
developer.
My advice is to not be afraid of this stuff. Sure, you have to be
careful, but you can hardly do any worse a job than those hacks who
are writing the software that runs the Internet ;-)
Regards,
Scott
PS: if you're interested in this kind of stuff (and probably just
about everyone using the Internet, client or server, should be), I
recommend getting on the SANS mailings lists (http://www.sans.org/).
Some of the stuff I've read about on those lists is positively scary!
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
Archives: http://www.mail-archive.com/metacard@lists.runrev.com/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.
