91067 - https scripts should be treated the same as signed scripts (enablePrivilege)

Status: RESOLVED WONTFIX

(Core :: Security: CAPS, defect)

Description

[Eric Murphy]

Right now I am having trouble getting any privileges enabled from a secure https
document. From what I have read, these are supposed to be treated the same as
signed scripts.

Supporting this would be a boon for Mozilla application developers because they
could do a lot more with remote XUL/JS, etc if they are using SSL to secure
their documents.

In case it matters, I am using mod_ssl with a 'temperary' certificate that is
used for testing. It is not a $400 Verisign cert, or something similar.

Comment 1

[Eric Murphy]

Today I tried it with HTML file, instead of XUL. I though maybe that might make
a difference, but it didn't.

Comment 2

[Mitchell Stoltz (not reading bugmail)]

Where did you read that? HTTPS pages have never been treated as signed in
Mozilla. I've brought up this idea on netscape.public.mozilla.security before;
the crypto (PSM) team had some objections. This feature doesn't work now, but we
may want to add it later in some form. 

Comment 3

[Eric Murphy]

Says so in the O'Reilly JavaScript Definitive Guide :-)

We need to figure some way for people to develop remote XUL apps with full
access, and do it easily. For example, I finally figured out how to create
signed script JARs, yet it still don't work :-( Using SSL is much easier.

BTW, see my latest post in netscape.public.mozilla.security...

Comment 4

[Mitchell Stoltz (not reading bugmail)]

The O'Reilly book is out of date. Signed scripts are still having problems; I'm
working on that.

Marking as Enhancement.

Comment 5

[Pete Collins (MDG)]

I'll help out on this. This is a good feature to have. 
How difficult would it be to implement this?

--pete

Comment 6

[Mitchell Stoltz (not reading bugmail)]

Thanks for the offer. The issue at this point is not difficulty, it's whether
this feature would be safe. Some people on the PSM team think this is a bad
idea. My earlier idea was not to treat all HTTPS-delivered content as signed
unless the page also included some kind of tag that indicates "treat this as
signed," maybe as an HTTP header or some other kind of metadata. I don't think
every SSL site out there should automatically be treated as signed unless that's
what the site creator intended, so they should have to signal their intent to do
so. Otherwise we may be opening ourselves up to attacks against the browser.

Even with that extra precaution, we may have a hard time getting buyoff from the
PSM team.

Comment 7

[Pete Collins (MDG)]

Way, back there was the concept of letting the user allow "trusted sites".
For a while i beleive it was implemented. 

However, where we stand now, you cannot get application privledges remotely
unless you have a $400 Verisign cert.

Is this correcrt?

What kind of implementation do you think the PSM team would feel comfortable with?

--pete

Comment 8

[Mitchell Stoltz (not reading bugmail)]

Well, you need a Verisign or similar cert to run an SSL server, as well. No way
around having to buy a cert if you want to delever verified content, unless we
go to some sort of PGP web-of-trust model for code signing.

Comment 9

[Mitchell Stoltz (not reading bugmail)]

performance, footprint, feature work, and re-architecture bugs will be addressed
in 0.9.8

Comment 10

[Bradley Baetz (:bbaetz)]

*** Bug 167714 has been marked as a duplicate of this bug. ***

Comment 11

[Myk Melez [:myk] [@mykmelez]]

Any chance this bug will be fixed soon?  I have a very useful Bugzilla script
(bug 156548) that happens to make some XPConnect calls.

http://bugzilla.mozilla.org/duplicates.xul

I could object-sign the code, but every Bugzilla installation would need to do
the same, since it relies in part on some JS that is dynamically generated for
each installation.  Having every installation sign it is painful and laborious,
much more so than having them run it via SSL.  Is there a chance this bug will
be fixed in the near future?

Comment 12

[Jesse Houwing]

This is also found in Netscape's own Javascript security manual on their devedge
website:

http://developer.netscape.com/docs/manuals/communicator/jsguide4/sec.htm

And this used to work in Netscape 4, and still does in netscape 4.79.

Comment 13

[Benjamin Smedberg]

Let's bump this bug back into some limelight, perhaps, in view of bug 248207 and
the need to have a real solution for web applications that want dynamic content
(signing JARs won't work).

Comment 14

[Paul Rubin]

There shouldn't be any need to grant privileges to dynamically generated javascript.  If necessary, have the javascript call privilege-invoking functions in a signed jar file.  Note that just because the jar file is signed doesn't mean privileges are granted automatically.  The user still has to grant permission.

In general, all this stuff makes me cringe.  Firefox should be a browser, not a general purpose shell for arbitrary downloaded code from remote web sites (i.e. virus vector).  Enabling privileges should always be a serious operation with user confirmation, comparable to a plug-in installation.  And signed executables should be signed offline, so that server compromises don't result in attackers being able to take over the computers of every Firefox instance that connects to the server.  The whole concept of granting privileges to dynamically generated code is scary.  Any privileged code needs to be in a trusted core that's been audited very carefully.

I oppose this RFE.

Comment 15

[vb4guy]

Sorry to bring this one back from the dead, but was wondering if this issue was planning on being addressed?  I just did a test and see that javascript pages from a HTTPS with a valid certificate are still being denied access to enablePrivilege.

Is there a work around that does not involve writing an extension?

Comment 16

[Benjamin Smedberg]

.enablePrivilege is being removed entirely.

Comment 17

[vb4guy]

What about this stuff on this page: http://www.mozilla.org/projects/security/components/signed-script-example.html?

The issue is that I have javascript code that is dynamically generated from server side code (such as PHP) and uses enablePrivilege to get the site to work in Firefox.  The side already uses HTTPS with a valid SSL cert that was purchased from a trusted certificate root (such as Verisign).

Why isn't this good enough?

Comment 18

[Benjamin Smedberg]

Because we are removing that support: users cannot understand the security dialog and will click the 'whatever' button and open themselves up to huge security exploits.

Comment 19

[vb4guy]

Ben,

I would agree with you for any non secure website (or secure with an invalid certificate).  But isn't one of the reasons behind having websites with valid SSL certs is that they can be trusted because the website had to be first verified by a 3rd party?

But I would like to know if you guys are dropping this enablePrivilege then how can I access the XPConnect objects from a webpage via javascript?

Comment 20

[Eric Murphy]

I am the original reporter of this bug (10 years ago). My suggestion would be to keep the enablePrivilege support, but show a screen similar to the phishing screen warning the user in a blatant manner that this is a dangerous operation.

For example, it could look similar (but not the same) to this:
http://nova.stage.mozilla.com/cdn/en-US/img/press/screenshot-firefox-phishing.png

Comment 21

[Jesse Houwing]

It used to be hard to get a valid certificare, nowadays you can just get one by leaving an emailaddress... Granted, it won't be a cert that shows up in the addressbar, but a valid ssl cert nonetheless. Such a cert is worth nothing, so it should not grant access to privileged methods.

Comment 22

[Pete Collins (MDG)]

It would seem to me that unless you have a huge user base that you need the enablePrivilege support for, you can just roll your own custom browser distro and provide whatever privileges need for your specific content. I have done this for a client who controls all of their content, the content is only accessible by the custom browser and their javascript has the access they require.

In most cases vanilla Firefox is just a browser. The extensibility we seek can be accomplished either by add-ons, plugins, or custom distributions. Implementation is harder, but it is all still doable.

Comment 23

[Intermittent Failures Robot]

1 failures in 3657 pushes (0.0 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• autoland: 1

Platform and build breakdown:

• linux1804-64-asan-qr: 1
  • opt: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=91067&startday=2023-10-23&endday=2023-10-29&tree=all