security of the runtime

Scott Raney raney at metacard.com
Thu Mar 27 17:58:01 EST 2003


On Wed, 26 Mar 2003 Alex Rice <alrice at ARCplanning.com> wrote:
> 
> I was just reading this article 
> http://www.theregister.co.uk/content/55/29958.html and thinking about 
> Runrev.
> 
> Focusing specifically on  1) buffer overflows, 2) format string 
> vulnerabilities and 3) input validation errors.
> 
> #3 is squarely in the responsibility of the me the programmer. But how 
> does the MC/Rev engine measure up regarding #1 and #2?

Certainly much better than the vast majority of software out there,
including such open source stalwarts as sendmail and bind (the DNS
server).  It has to be, or you'd be crashing it regularly with simple
script errors.

Even #3 is a small fraction the risk with an MC/RR based app compared
with one written in a third generation language like BASIC/C/C++/Java
because the malicious data not only has to fall through the script
checks, but also through a crack in the engine error checking, and the
odds of the two lining up exactly like that are close enough to 0 that
it's reasonable to ignore the possibility.

The primary vulnerabilities are in the third-party libraries we use.
For example, I wouldn't be surprised if you could force the engine to
crash or execute arbitrary machine code by passing it a carefully
crafted bogus GIF/JPEG/PNG image, QT movie, or compress() stream.  But
as long as you can maintain some control over the source of the data
you're using with those routines I wouldn't lose any sleep over the
possibility of a user being able to craft some other type of data that
would allow them to break into a machine using your program.
  Regards,
    Scott

> Alex Rice, Software Developer
> Architectural Research Consultants, Inc.
> alrice at ARCplanning.com
> alrice at swcp.com

********************************************************
Scott Raney  raney at metacard.com  http://www.metacard.com
MetaCard: You know, there's an easier way to do that...




More information about the use-livecode mailing list