Security/Reviews/Firefox6/ReviewNotes/GCLI

Ensure GCLI Commands are Executed Securely 2011.06.15

Introduction

• Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
  • imagine a firebug that is command line driven to some degree
• What solutions/approaches were considered other than the proposed solution?
  • Alt: run commands in content but then how to do you break out and have some command privileged
  • this has the problem of having items that have to go back and forth for privileged states
• Why was this solution chosen?
• Any security threats already considered in the design and why?
  • ^^ (see Team Supplied info below)

Threat Brainstorming

• Web page convinces you to paste [like the JS-URL attacks that have been spreading on Facebook]
  • An "Enable developer tools" option, off by default, might help
  • Save over an important file (unlike file>save as, there's no filepicker to show context and warn about dotfiles and system directories)
  • Evil scripts within {}
    • The stuff within {} will have content privileges. And {} is not implemented yet.
• how is GCLI preventing use from scripts on page / in content?
• Security holes in implementations of commands
  • chrome-content interaction is hard to get right, especially when you're trying to do web-developer debugging stuff like call content functions
  • Some commands, like "pick a node from the DOM for inspection" or "show me the properties of this object", might be safer to implement with content privileges
• A sensitive script typed by a developer, who intends to execute it in domain X, ends up executing in domain Y because of an evil navigation from elsewhere. (Scratchpad has the same problem.)
• Will autocomplete include data from the page?
  • yes, speculatively
  • if done like debuging interface then there is something akin to a "firewall" that makes this better

Conclusions / Action Items

• [jwalker] need a list of commands to review --> bug 664693
• [bsterne] bug: re-enable required pref change to enable Developer Tools (and developer menu) (not blocking) --> Filed bug 664589
• [jesse] bug: navigating from a domain should close the console or reset the command line field? (not blocking)
• [jwalker] have mrbkap review implementations, especially ones that explicitly wrap or unwrap --> bug 664696

Team Supplied Info

About GCLI

GCLI is a new command line for the web console. The idea is that JavaScript is good for testing, but not for getting things done - too much () and "", and developers like command lines. Initially we'll have a toggle to switch between JS mode and command mode.

GCLI was born out of Bespin/Skywriter/Ace so it's a separate project that in addition to running inside the Firefox console, also runs in a web page. Links for more information:

   Repo: https://github.com/joewalker/gcli/
   Feature Page: https://wiki.mozilla.org/DevTools/Features/GCLI
   HG patch repo for changes to moz-central: https://hg.mozilla.org/users/jwalker_mozilla.com/gcli-patches/
   Documentation: https://github.com/joewalker/gcli/blob/master/docs/index.md
   Browser Demo: https://people.mozilla.com/~jwalker/gcli/build/
   Security review bug: https://bugzilla.mozilla.org/show_bug.cgi?id=651081

• Why the particular need for a review?
  • I'm suggesting that, unlike the JS command line, GCLI commands should execute with chrome priviledges.

Specifically:

> rm -rf /
# oops there goes lots of files

• I don't suppose we will implement commands as destructive as this, however more usefully:

// Step 1: edit the CSS using the new CSS editor
// Step 2:
> save ~/myproj/styles.css

FAQ (or more properly: QIAPA - Questions I Anticipate People Asking)

Q: Isn't this dangerous to our users?

A: It would be if we were to implement destructive commands and make them easy to use. File->Save As... can be dangerous if used improperly, this is similar.

Q: Won't this enable web pages to wreak havock?

A: I hope not. Unlike the console object, GCLI commands should not be accessible to the web

Q: How does GCLI interact with web pages?

A: It doesn't. GCLI commands do.

Q: Really?

A: We have an idea that might be dangerous, or maybe not:

> echo "hello" # This is a GCLI command
> echo {window.title} # Anything in {} is Javascript

I'm thinking that we might be  able to come up with some rules that could make this safe (like the
only return types allowed from {} are strings numbers and booleans or  something). This isn't 
currently in development, but could be useful if we could do it safely.

Q: So we need to audit GCLI commands carefully?

A: Yes

Q: Isn't this a bigger attack surface area?

A: Possibly, however I expect that most of our commands won't interact with content in a dangerous way

Q: How many commands do you envisage existing?

A: Very hard to guess, and it also depends on how you count (is 'hg add' different from 'hg push', and what about 'tar -x' and 'tar -c') I would think the number of commands might be roughly equal to the number of menu options and toolbar buttons in Firebug - i.e. eventually we could get to 50.

Q: That's a lot

A: Yes, but if our UI executes GCLI commands under the hood, then we could think of this as work that we'd need to do already.

Q: Who can write commands?

A: Browser authors and extension developers.

It  would be nice to allow web pages to contribute commands, however this  will require a different 
security model, and isn't something that we're  current planning or considering.

Q: What other dangers can you see?

A: The current UI has a toggle to switch from JS mode to GCLI mode. There are very different permission models for these, this could be confusing, or perhaps the percentage of developers that grok chrome vs content could also be expected to grok how this works