[gst-devel] Security audit strategy

[David I. Lehn]

* Christian Schaller <Uraeus at linuxrising.org> [20010520 17:51]:
> We make a shortlist of what kind of security risks we should focus on,
> for instance buffer overflows and outline a strategy to have a good
> security profile in those areas. For instance say that we don't ship a
> stable release of GStreamer as long as we know of any media files able
> to crash it.
> 

What are you trying to audit?  The core or the plugins?  The core will
be much easier to audit.  But it's probably next to impossible to audit
all the plugins.  Many are linking to external libraries.  It's not
really fair to call GStreamer insecure because of a plugin that links to
libfoobar which has a buffer overflow.

Maybe we need more info on all the plugins.  Another field saying how
vulnerable it could be to attacks.  Have something in the core such that
you can disable usage of plugins not known to be secure.

At some point we can do basic testing of plugins.  Have a randomsrc that
dumps garbage to a plugin to make sure it handles it gracefully.  I'm
sure most plugins will fail this sort of test miserably.  But this would
point out obvious potential security holes.  It's really an audit but a
start.  I'm sure many of the libraries we use could be attacked with
specific formatting of the input data.  Probably need to cooperate with
the other authors to get them to do audits.

-dave
-- 
David I. Lehn <dlehn at vt.edu>  | http://www.lehn.org/~dlehn/
Computer Engineering Graduate @ Virginia Tech in sunny Blacksburg, VA