Security/Reviews/GCLI-2

Please use "Edit with form" above to edit this page.

Item Reviewed

GCLI

Target

Previous Review: https://wiki.mozilla.org/Security/Reviews/Firefox6/ReviewNotes/GCLI 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: http://mozilla.github.com/gcli/ Security review bug: https://bugzilla.mozilla.org/show_bug.cgi?id=651081

Introduce the Feature

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

• a very simple UI for developer commands that is CLI like
• Implement a ls equivalent.
• Hypothetical at this point.

What solutions/approaches were considered other than the proposed solution?

• see previous review

Why was this solution chosen?

• see previous review

Any security threats already considered in the design and why?

`

Threat Brainstorming

• School administrative account and student account. student windows r command disabled, but now the student can do this via browser's GCLI. We could disallow a set of commands if windows r is not allowed. Maybe this isn't an issue, if we are using the right policies maybe they won't be able to run these commands. Solution: Administrative accounts can lock the pref on firefox to ensure that students don't have this access.
  • Example: `ls` is not dangerous, but the admin doesn't want the student to even do this.
  • Could also do file://... anyway.
• Preference to turn on/off - need to discuss. People will have to enable the pref in order to use this.
  • there is a pref for this, and the pref can be locked if needed as other prefs can
  • What if an addon turns on the pref without the user realizing it?
• What if we take the command and pipe it raw to the OS? What are the threats here?
  • Could be an attack on the machine. situations where kiosks where the device may be locked to the browser ? And opening up something that people don't expect browsers to do.
  • Dangerous things that browsers can do to the machien if the admin doesn't trust the user. As long as there is away for admins to turn this off. But you could end up with admins turning the whole thing off, including the safe parts (javascript commands in the console).
  • There is nothing that a user can do on a command like pass through that they couldn't otherwise do by opening up a shell. Just adds more power to an attacker via social engineering (next item):
• web console is running with chrome privileges.
• Social Engineering ( Self-xss, self-scripting )
  • 2 prefs in about:config, you have to click on the "yes i'm sure" warning for about:config
    • Turn off self-xss protection pref (separate bug) to protect the javascript command line.
    • Additional pref for turn on dangerous commands. We could mark commands as dangerous in some way. Where dangerous = self-scripting.
  • ie a web page convinces a user to execute a dangerous gcli command
  • most users would have it disabled? what if an add on turns it on?
    • can amo blacklist addons that turn this on?
    • web developer add on that turns on all developer tools prefs
    • can we require the user to type something in webconsole (not copy/paste) in order to enable it. ex: turn the pref on in about:config and then type "sudo turn on dangerous commands" in the webconsole (or something like that). is this too much to ask from developers? is this overkill?
      • as long as we are better than "press window r and paste this...", we should be okay. Hence, this requirement is probably overkill. The pref should be enough.
  • web page could ask the user to turn on the feature
• Web console - splash screen. Some text that says this is a developer tool for advanced users. Planning to have a splash screen for GCLI. Tell people this is a command line, not a javascript console. We could add something there that says be careful. Separate from where you enter javascript - separate from the javascript console.
• Taint mechanism
  • Determine whether something has been copied from a webpage, and then pasted in a dangerous context (javascript console, gcli) warn user when they try to paste something they copied.
  • What if they copied it from an email on their email client?
  • How do we distinguish between things we watched the user copy vs other applications (flash puts things on the clipboard), etc.
  • Idea: on the first paste ever (no matter where its from), alert the user. Every paste after that, don't. Developers will be pasting a lot and get this only once. Users will never be pasting into GCLI, so the first time they try (because of social engineering), they'll get this.
  • But we already have a warning when we turn on the pref (the about:config warning). What if they get it via an add-on? Less concerned about this, if they are install a developer tool addon, probably a developer, etc. Plus we could look for this in amo. Plus we have the splash screen.
  • Would need to talk to flash. And could have a discussion with them about cut/paste in flash. (flash is already used as a bypass for browser clipboard controls in existing self-xss attacks)
• Marionette - UI action framework - considering turning it on by default landing on Gecko. simulated UI actions. if turned on by default this will easily have access to GCLI.
  • bug 712643
  • What are the limits that Marionette can do? Can do most of what a user can do.
  • Can marionette automate the installation of the addon? Gets an addon on the users behalf? Possibly.
  • We'll have to consider the combination of GCLI + marionette

Some of the proposed commands:

• ls
• github/cvs code checkin

• Property "SecReview feature goal" (as page type) with input value "* a very simple UI for developer commands that is CLI like
  • Implement a ls equivalent.
  • Hypothetical at this point." contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
  • Property "SecReview threat brainstorming" (as page type) with input value "* School administrative account and student account. student windows r command disabled, but now the student can do this via browser's GCLI. We could disallow a set of commands if windows r is not allowed. Maybe this isn't an issue, if we are using the right policies maybe they won't be able to run these commands. Solution: Administrative accounts can lock the pref on firefox to ensure that students don't have this access.
    • Example: `ls` is not dangerous, but the admin doesn't want the student to even do this.
    • Could also do file://... anyway.
  • Preference to turn on/off - need to discuss. People will have to enable the pref in order to use this.
    • there is a pref for this, and the pref can be locked if needed as other prefs can
    • What if an addon turns on the pref without the user realizing it?
  • What if we take the command and pipe it raw to the OS? What are the threats here?
    • Could be an attack on the machine. situations where kiosks where the device may be locked to the browser ? And opening up something that people don't expect browsers to do.
    • Dangerous things that browsers can do to the machien if the admin doesn't trust the user. As long as there is away for admins to turn this off. But you could end up with admins turning the whole thing off, including the safe parts (javascript commands in the console).
    • There is nothing that a user can do on a command like pass through that they couldn't otherwise do by opening up a shell. Just adds more power to an attacker via social engineering (next item):
  • web console is running with chrome privileges.
  • Social Engineering ( Self-xss, self-scripting )
    • 2 prefs in about:config, you have to click on the "yes i'm sure" warning for about:config
      • Turn off self-xss protection pref (separate bug) to protect the javascript command line.
      • Additional pref for turn on dangerous commands. We could mark commands as dangerous in some way. Where dangerous = self-scripting.
    • ie a web page convinces a user to execute a dangerous gcli command
    • most users would have it disabled? what if an add on turns it on?
      • can amo blacklist addons that turn this on?
      • web developer add on that turns on all developer tools prefs
      • can we require the user to type something in webconsole (not copy/paste) in order to enable it. ex: turn the pref on in about:config and then type "sudo turn on dangerous commands" in the webconsole (or something like that). is this too much to ask from developers? is this overkill?
        • as long as we are better than "press window r and paste this...", we should be okay. Hence, this requirement is probably overkill. The pref should be enough.
    • web page could ask the user to turn on the feature
  • Web console - splash screen. Some text that says this is a developer tool for advanced users. Planning to have a splash screen for GCLI. Tell people this is a command line, not a javascript console. We could add something there that says be careful. Separate from where you enter javascript - separate from the javascript console.
  • Taint mechanism
    • Determine whether something has been copied from a webpage, and then pasted in a dangerous context (javascript console, gcli) warn user when they try to paste something they copied.
    • What if they copied it from an email on their email client?
    • How do we distinguish between things we watched the user copy vs other applications (flash puts things on the clipboard), etc.
    • Idea: on the first paste ever (no matter where its from), alert the user. Every paste after that, don't. Developers will be pasting a lot and get this only once. Users will never be pasting into GCLI, so the first time they try (because of social engineering), they'll get this.
    • But we already have a warning when we turn on the pref (the about:config warning). What if they get it via an add-on? Less concerned about this, if they are install a developer tool addon, probably a developer, etc. Plus we could look for this in amo. Plus we have the splash screen.
    • Would need to talk to flash. And could have a discussion with them about cut/paste in flash. (flash is already used as a bypass for browser clipboard controls in existing self-xss attacks)
  • Marionette - UI action framework - considering turning it on by default landing on Gecko. simulated UI actions. if turned on by default this will easily have access to GCLI.
    • bug 712643
    • What are the limits that Marionette can do? Can do most of what a user can do.
    • Can marionette automate the installation of the addon? Gets an addon on the users behalf? Possibly.
    • We'll have to consider the combination of GCLI + marionette

  Some of the proposed commands:

  • ls
  • github/cvs code checkin" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.

Action Items

Action Item Status	In Progress
Release Target	`
Action Items
Who Action By When Completed date [NEW] new [DONE] Done [MISSED] Miss dveditz bug 740429 communicate turn-on prefs to AMO team so they can be flagged for review in add-ons that mess with it by beta [NEW] new dveditz bug 740429 communicate command-adding API to AMO team for add-on scanning by beta [NEW] new Full Query ID Summary Priority Status 740429 [Security Review][Action Item]GCLI - AMO prefs -- RESOLVED 1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);

The given value "

WhoActionBy WhenCompleted date [NEW] new [DONE] Done [MISSED] Miss

dveditz bug 740429communicate turn-on prefs to AMO team so they can be flagged for review in add-ons that mess with itby beta[NEW] new

dveditz bug 740429communicate command-adding API to AMO team for add-on scanningby beta[NEW] new

Full Query

ID	Summary	Priority	Status
740429	[Security Review][Action Item]GCLI - AMO prefs	--	RESOLVED

1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);

" contains strip markers and therefore it cannot be parsed sufficiently.

Additional Information-- (provided by mgoodwin) Hi, We have a secreview session scheduled for tomorrow to look at GCLI. I made a few notes at the meeting Tanvi and I had with Joe on Feb 23rd; I thought sharing would be useful to ensure everyone has context. Joe would like us to think about a hypothetical feature to allow system commands to be executed directly by developers from GCLI. - This has been proposed as a means of testing the limits of what could / should be possible via GCLI commands - It's hypothetical at this stage Why would we want to think about this sort of thing? Suppose a web dev has been busy playing with styles in the style editor and would like to commit their changes. It would be greatly convenient for the user to be able to do this directly from GCLI without having to switch away from their browser to external tools (this is just one example of the type of thing which could be useful). Discussed attacks: Some have been discussed before:https://bugzilla.mozilla.org/show_bug.cgi?id=651081 We talked a bit about similar problems that currently exist; self-XSS is the obvious issue here. - ability to exec external commands could turn self-XSS into self-destruct-via-system-command-shell

   - e.g. currently windows users have to windows-r, OS X

command-space, type terminal, etc.

   - commands via GCLI could greatly simplify this kind of attack (and

self-XSS happens; why shouldn't this?) We'd need to make this useful for developers *and* unlikely to be used for this type of attack Discussed mitigation: - Existing anti-self-xss as perhttp://incompleteness.me/mozblog/2011/12/14/combating-self-xss/ - Yvan's clipboard taint idea (https://bugzilla.mozilla.org/show_bug.cgi?id=734188) Anyway, I hope this helps. Feel free to ping me if you have questions. Cheers, mgoodwin