Security/Reviews/Firefox10/CodeEditor

Items to be reviewed: Code Editor - https://wiki.mozilla.org/DevTools/Features/CodeEditor Agenda:

Introduce Feature

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

• The current code editor is missing some desirable feature such as syntax highlighting, code folding, autocompletion, etc
  • A comparison of considered features can be found on the feature page
• The code editor will be the backend implementation for devtools
  • frontend will be the tools such as Scratchpad, style editor (not landed), webconsole

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

• built-in gecko content-editable
• ACE
• Orion

Why was this solution chosen?

• It was decided that extending Orion was easier than attempting to implement Orion features on top of ACE or content-editable
• Orion is the eclipse editor backend
  • Written in JS and CSS
• content-editable will be leveraged to provided certain i18n and a10y features
• More information on the decision can be found on the wiki page

Any security threats already considered in the design and why?

• The frontend doesn't have direct access to the Orion APIs
• A well defined interface is defined for communication
• The frontends run as content
• Orion is run as a JSM, which has chrome privileges
  • beautifed code is evaluated in a content sandbox
  • Orion parses/beautfies code but doesn't evaluate it
• Certain resources are loaded from chrome://
• There currently is no way to prepopulate values into the editor
  • Style editor may allow it in the future
  • Ideally an add-on would be used to prepopulate the editor

Threat Brainstorming

• The user editing themselves into an attack isn't likely, the main worry is probably if loading a file can attack the syntax highlighter or something along those lines. Fuzzing with lots of JS and invalid JS would be good. Also super large files (both absolute length and line length).
• future uses might allow pre-loading script or CSS from a page you're working on, currently only allows loading of an on-disk javascript file.
• Being implemented in JavaScript limits the kinds of attacks -- you can make it throw an exception, but can't really get it to jump into executing arbitrary code. At least not unless you could already do that by exploiting a JS engine bug from script in a page.
• If there is such a bug, would the fact that Orion runs with chrome privs give you a privilege advantage over exploiting that bug in a non-privileged page script? Probably not, either way it's likely to be a binary exploit that doesn't care about the script privilege, just the user permissions granted by the OS.

Conclusions / Action Items

• [dchan] - test source editor properties that are exposed
• [mozbug] - test wrappers in scratchpad