Re: (in)SECURITY: mozilla-bonobo

[Christian Glodt <chris mind lu>]

Hi,

>	While browsing the GNOME 2.5 Getting Started page, I noticed, in the
> "proposed module" list, that a module named mozilla-bonobo is to be
> included in the 2.6 release.

I am the original author of that module.
 
> 	Did any discussion take place about the security issues implied by
> this? This is a HUGE security issue, since bridging Bonobo into Mozilla
> assumes that every bonobo component registered in the system is secure
> against untrusted data. This is an insane assumption.

Indeed, until now, there's not been much discussion of these issues.
 
> 	In practice, mozilla + bonobo = MS Internet Explorer. Most security
> issues exposed by Internet Explorer are related to ActiveX components,
> since IE has an embedded bridge. Almost every week, a new hole is found
> in some popular ActiveX component that can be exploited through Internet
> Explorer.

IE and its integration into the OS has been the inspiration for this module.
This does not necessarily mean that *all* the same issues apply to it.
I think most of the ActiveX-related security problems exist because of the
following fact:

IE can instantiate *any* kind of ActiveX control. All that's necessary for
this is an <object classid="..."> tag with the right GUID (Globally Unique
Identifier). Because of this, exploits are possible that target ActiveX
controls of any kind, even those which:
  - are internal to third-party applications,
  - are internal to Windows,
  - don't have a user interface,
  - are not mime-type handlers.

Contrast this with the workings of mozilla-bonobo: It instantiates the default
mime-type handler for a given mime-type that implements Bonobo/Embeddable or
Bonobo/Control. Consider the following facts:
  - only components that advertise that they can display a file of a mime-type
    can be instantiated, not arbitrary Bonobo objects,
  - the web server can not influence which component gets used to display a file,
    and the component that gets used depends fully on the user's local configuration.

(These are just general points that I make - I'm not saying that there are no
issues worth discussing!)

> 	The problem is that most ActiveX that people write are not intended to
> be used as web plugins (ie. not to handle untrusted data). And the same
> will happen to GNOME. With sure! People will write broken bonobo
> components that will expose web browser users to critical
> vulnerabilities. 
>
> 	If such a feature was enabled by default, the reputation of GNOME and
> Mozilla would be destroyed by broken third-party bonobo components.
> 
> 	So we have two problems: 
> 
> 	1. The current bonobo components will be exposed to the Internet, even
> those that were never intended to be
> 	2. The cost of writing bonobo components will increase, since they now
> must handle untrusted data.

When is data trusted? When it got downloaded from some obscure website? When it
comes attached to an e-mail?  When it is signed/encrypted? Or only when you created
it yourself? Can you even trust the tools you use to create data by yourself?

I postulate that in day-to-day work, most of the data processed by any computer
will be untrusted. Therefore all software that touches this data needs to be wary
of its untrustworthiness. If we limit ourselves to trusted data, we might as well
close shop and go home (or use palladium). </cynicism>

Back to the problem at hand: I understand that there's a big difference between
a component that gets activated because a user double-clicked a file, and a
component that gets activated invisibly and maliciously from a hidden frame on
some website for nefarious purposes.

Read on for solution proposals.

> 	And some solutions:
> 
> 	1. Forget about mozilla-bonobo
> 	2. Create a "safe for web" flag that bonobo components must set if they
> are intended to be used as web components

2a. Instead of adding a flag, use the "bonobo:supported_uri_schemes" oaf attribute.
    This way, one can limit the used components to those that advertise that they
    handle the protocols (http(s)/ftp) that are used to transfer files on the net.
    Supposedly components that are aware of those protocols would also handle
    untrusted data.

3a. Add a warning dialog before a component is used to display a document from the
    web. This would ofcourse not provide any real security, but it would inform
    the user of the risk he is taking and give an opportunity to cancel the operation.

3b. Add an UI panel with a button that needs to be clicked before a document is
    viewed.

None of these proposals would provide absolute security (there's no such thing
as we all know). But at least 3a and 3b would make sure that nothing happens
behind the back of the user.

> 	Please, let's not make the same mistakes that Micros~1 did. Let's learn
> from other's mistakes.
> 
> 	Time to flame me.

No flamage intended with this mail :)

> 	Also, time to think again about the creation of a gnome-security
> mailing list.

Indeed.

> 	Thanks for your attention.

Regards,

Christian Glodt