Re: (in)SECURITY: mozilla-bonobo

[Sean Middleditch <elanthis awesomeplay com>]

On Fri, 2003-12-05 at 18:59, Fabio Gomes wrote:
> > There's also the issue that "support for HTTP" has nothing to do with
> > safety.  A company can have an intranet with HTTP served documents
> > (perhaps use DAV) which are completely trustworthy, while documents
> > served from http://hacks.l337.foo are not safe.
> > 
> > Which brings up a slightly different situation - not only do we need the
> > component to advertise whether it's allowed to be used for untrusted
> > documents, but also, how do we know which are untrusted, and how do we
> > tell the component that?  Documents from servers on my local network I
> > trust (and I can get to any of them using SMB or NFS as is anyhow), but
> > not the outside world.
> > 
> 
> It is A LOT easier to assume that every on the web accessed through the
> web browser is untrusted. If one has trusted documents on the local net,
> browse them with Nautilus. Period.

But Nautilus can access untrusted documents too... nothing stops me from
opening Nautilus to http://www.hackme.foo running DAV.

Just the browser is a near non-issue.  We'd have more to worry from
buffer overflows and other mistakes in the browser itself than we would
with components, given current trends.  Untrusted documents come in thru
email, web browsing, DAV, ftp, p2p clients, removable media, etc.

> 
> Micros~1 has such a mechanism to create "zones" of security to determine
> the safety of content, but this is useless because there are
> Cross-Site-Scripting bugs in trusted websites that allow hackers to
> circumvent the zone policies.

There's always bugs.  There will be bugs in "safe" browser components
that let attackers use malicious data to circumvent security.  There'll
be bugs in the browser itself.  There's probably still lurking bugs in
the kernel's networking stack.

If your defense is, "there might be a bug, so let's give up," then I
suggest we not waste any time at all worrying about security in
mozilla-bonobo, because I can guarantee you there will be bugs...

> 
> So, assuming that everything that comes through the web browser is
> untrusted is A LOT safer too.

That may work.  But what about file systems that are very commonly used
locally *and* used remotely?  And, given corporate markets for GNOME.. I
*know* for a fact many corporations server documents over plan HTTP with
a browser, using one a plethora of Web Apps - corporations *are* going
to want to at least "trust" the local network.  Then they're going to
want some other specific networks, perhaps things running over VPNs to
other trusted networks.  A simple access list works well for this -
untrust everything by default unless it's in the list.

> 
> > 
> > To be honest, it's probably best the app/component be completely in
> > charge of determining trust-worthiness/safetiness.  We need to handle
> > the situation for when the user selects "File->Open" and enters a URL
> > just as much as we do when the user clicks on a link in a web browser,
> > opens an attachment in an email (just as dangerous if not more so in
> > today's state of affairs), or opens a document from a remote file system
> > browsed in Nautilus.
> 
> I didn't know that Nautilus has such an automated process of
> download-and-open files off the net. This process should give fancy
> warnings about security before opening stuff.

Any and all GNOME-VFS apps have this feature - a VFS backend is fully
capable of accessing any host, local or not, if it so wishes.

Simply using "localhost" doesn't work well, either.  Nautilus even now
suffers from the problem that on an NFS system, it just sees NFS as
"remote" as it does a DAV connection to a completely different network;
so wheN I turn off "show file counts in folders" for remote hosts, there
goes my whole home directory, including the slow hosts over the
Internet.

That kind of lack of fine-grained control could potentially be a serious
pain for anyone using any kind of a complicated network setup.

> 
> Regards,
-- 
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.