[gst-devel] Security audit strategy

[Christian Schaller]

On 21 May 2001 15:21:53 -0400, David I. Lehn wrote:
> 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.

Since the plan is to splitt most of the plugins of from the core and
ship them separatly we can say that we personally work at keeping the
core bundled plugins safe, and that the other plugins degree of security
is up to the individual plugin-developer and that people very concerned
by security should only install each of those plugins after verifying
that they have been audited.
 
> 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.
If GStreamer becomes as big and popular as we hope and believe keeping tabs 
of all plugins would be hard, my general suggestion outlined above would probably 
be much more easy to handle. 

> 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.
A tool like that would be great and is within of the degree of security
auditing that I think we should be aiming for. Making GStreamer the
OpenBSD of multimedia frameworks would probably be the best way to kill
of most developer interest :)

Christian