Nigel McFarlane wrote:

[long post]

Indeed. My sense of the problem is below. Please correct where I got it wrong.



There are two worlds, the web and the disk.  The
assumption is that the web is "untrusted" and the
disk is "trusted" **.

Anything that is stored on the disk is thought to
be secure, safe and trusted.  It therefore gets
some special privileges, chief example of which
seems to be the ability to read other files on
the disk using programs like javascript and do
things with them.

Anything on the web can't do that.  So even if
the web page were to present the right code for
reading ones local key file, that action would
presumably be blocked or ignored in some way by
the browser's security model.

To complicate matters there are people who live in
both groups who want that situation to remain;
in group I, developers want their disk files to
act with full disk privileges.  In group II, the
users want to browse the web without worrying about
the pages reading their disk.

Where it breaks is if a user saves a web page to
the disk, this causes a privilege escalation from
untrusted to trusted in one click.  Of course users
want this feature preserved too...



In such a circumstance, I can't see that "credentials"
do anything for us.  It isn't the source of the file
that is the danger, it's the fact that it crossed
the border without notice.  Once inside the border
it has the "rights of the citizen" to use a bad
analogy, and sticking an armband on it won't really
help there unless we have a system that supports
such (which to my mind has never successfully been
deployed, data doesn't work so well when marked
with negative opinions, only positive opinions) &&.

So the essence of the security problem remains at
the border.  It seems that the analogy best suited
is one of viruses.  If Alice sends Bob an email
with an attached program that could be bad, there
is a point in time whereby Bob moves from safe to
endangered;  that point is when his software runs
the Exe, and/or loses sight of the fact that it
shouldn't be run.

The same seems to be happening here.  Merely saving
the file is not the issue, it is that it can run as
code and can do things with a new privileged status.
I.e., the web page concerned is a program (by dint
of javascript).

So maybe the answer is that if the user chooses to
save the file, the save process checks to see if any
javascript is in there, and then warns the user as
if it were an email with exe attachment.  I.e., it
says the same thing as if an exe was received in
email:

   this page contains programs and may do damage
   like any virus, are you sure you want to save it?

   After saving it, any viewing of the saved page
   will cause it to run with full privileges!

Or. possibly one could strip the code out of it.
Whether that is plausible depends on the page I
suppose;  I wouldn't suggest a parsing phase, as
they are too easy to defeat, in theory, and the
attacker does have access to your parser.



At least, that's my sense of what the issue is.  It
is a long set of threads and bugs and posts, and I
only read through once!


iang

** when I use the words trusted and untrusted I am
being quite loose, there is no good definition of
them, but they suit the high level nature of this
discussion.

&& to see how credentials are difficult; imagine two
viruses.  One is useful and another is evil.  The
useful one spreads like wildfire and saves users
lots of trouble by cataloguing their files.  The
evil one is clearly evil and is marked with a
credential that says "evil, do not run".  Yet the
useful one also includes a special malign feature
to strip the credential off of the evil one, which
is only activated when it comes across the special
signature...

--
News and views on what matters in finance+crypto:
        http://financialcryptography.com/
_______________________________________________
Mozilla-security mailing list
Mozilla-security@mozilla.org
http://mail.mozilla.org/listinfo/mozilla-security

Reply via email to