Re: TCP/IP security considerations

2001-04-13 Thread Scott Raney

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.




TCP/IP security considerations

2001-04-12 Thread Richard Gaskin

What are the security considerations in the following scenario?:

Suppose I have two MC apps running on different machines, and they
communicate with each other showing a listing of files each machine has
designated specifically for sharing (much like Napster, GNUtella clients,
etc.).

In this scenaro, what special risks would someone be taking in having a
MetaCard client sharing a designated folder to other MetaCard clients using
the same custom protocol?

Given that ultimately everything is hackable, what specific standards
constitute various levels of security?  Or at least, a level of security
business people (not hospitals and other critical-systems) find acceptable?
Most importantly, can we satisfy those requirements with MetaCard?

-- 
 Richard Gaskin 
 Fourth World Media Corporation
 Multimedia Design and Development for Mac, Windows, UNIX, and the Web
 _
 [EMAIL PROTECTED] http://www.FourthWorld.com
 Tel: 323-225-3717   ICQ#60248349Fax: 323-225-0716



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.




Re: TCP/IP security considerations

2001-04-12 Thread David Bovill

1) Don't transmit IP numbers - use a server?

2) Use an non-ICQ type name space so people can't guess id's

3) Restrict client communication to other clients that are known to be OK

4) Check for "code" transmission? MC, exe's?

5) As building a virus checker seems too complex (ie above) use PGP (or
equivalent) signed packets of data, and a public key encryption scheme.

 From: Richard Gaskin [EMAIL PROTECTED]
 Reply-To: [EMAIL PROTECTED]
 Date: Thu, 12 Apr 2001 00:31:54 -0700
 To: [EMAIL PROTECTED]
 Subject: TCP/IP security considerations
 
 What are the security considerations in the following scenario?:
 
 Suppose I have two MC apps running on different machines, and they
 communicate with each other showing a listing of files each machine has
 designated specifically for sharing (much like Napster, GNUtella clients,
 etc.).
 
 In this scenaro, what special risks would someone be taking in having a
 MetaCard client sharing a designated folder to other MetaCard clients using
 the same custom protocol?
 
 Given that ultimately everything is hackable, what specific standards
 constitute various levels of security?  Or at least, a level of security
 business people (not hospitals and other critical-systems) find acceptable?
 Most importantly, can we satisfy those requirements with MetaCard?


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.




Re: TCP/IP security considerations

2001-04-12 Thread michael kann


--- Richard Gaskin [EMAIL PROTECTED]
inquired about peer-to-peer security a la Metacard:

Any business peer-to-peer program will be compared to
Ray Ozzie's Groove, found at www.groove.net, because
he has a PR machine that just won't quit. Security is
fundamental to their efforts, so it might be
worthwhile to check out the competition.  

__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

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.