Platform/GFX/WebGL-Security-2011-06-29: Difference between revisions

From MozillaWiki
< Platform‎ | GFX
Jump to navigation Jump to search
No edit summary
No edit summary
Line 10: Line 10:
**** Fuzzing (20+ issues found)
**** Fuzzing (20+ issues found)
* Patterns of WebGL exploits so far (Benoit)
* Patterns of WebGL exploits so far (Benoit)
** Pattern A (Relying on a particular GL state)
** Pattern A (Relying on a particular GL state, forgetting that scripts can change it)
*** Bug 659349
*** Bug 659349
** Pattern B (Mistake when keeping track of GL state)
** Pattern B (Mistake when keeping track of GL state)

Revision as of 20:15, 2 July 2011

  • Outline last year's security review (security team)
    • Design review with some follow up fuzz testing
    • WebGL Security Notes
      • Low level API (like image decoders)
        • expect to see similar things
      • Mitigations
        • ANGLE protects certain problems
        • Reassured that drivers don't execute
        • Blocklist/global kill switch
        • Fuzzing (20+ issues found)
  • Patterns of WebGL exploits so far (Benoit)
    • Pattern A (Relying on a particular GL state, forgetting that scripts can change it)
      • Bug 659349
    • Pattern B (Mistake when keeping track of GL state)
      • Bug 656752
      • Bug 665070
    • Pattern C (Timing attacks)
      • Bug 656277
    • Pattern D (Driver bugs)
      • Type 1: Can be worked around. Examples: bug 631420, bug 657201.
      • Type 2: Can be blacklisted. Tons of examples.
      • Type 3: Ones we ignore for now because extensive DOS mitigations not available
    • Pattern E (Implementation Bugs that are not at all GL-specific)
      • Many examples, like bug 648705 in our WebGL implementation, and bug 665934 in ANGLE.
  • Updated thoughts on security review (security team)
    • More resources on security team now
      • Assuming there is a good focus
    • Threat model is what Benoit create
      • Good, but maybe needs development before hand
    • Fuzzing helps
    • Was not clear that ANGLE would change as frequently
  • What are the security goal? [Potential strawman to provide basis for mitigation discussion]
    • Prevent DOS attacks lasting longer than 1 second
    • Mitigate above threat model patterns
  • Discussion of short term mitigations
    • Fuzzing
      • Tracking https://bugzilla.mozilla.org/show_bug.cgi?id=658170
      • When ANGLE changes, it needs to be re-fuzzed
        • We have less visibility when significant changes happen and need re-fuzzing
      • Limited to hardware that the fuzzer runs on
        • Could get better test coverage by picking oldest driver for a line of cards
      • Converting crashes to test cases doesn't really help the future, but prevents regressions
      • General problem scaling fuzzing
    • Compliance suite conformance
      • Review and prioritize fixes
    • Code reviews
      • Very expensive
      • Do it for targeted for certain parts of the feature
      • Shouldn't be often
      • File bugs for high impact reviews
    • Not running WebGL automatically on a page
      • Needs UI discussion around the user experience
      • Crashing the system rather than the app
      • Should be consistent with what plugins are doing
  • Discussion of long term mitigations
    • ARB_Robustness
      • Robustness with isolation is the real solution
        • May not work on top of D3D
          • Use openGL driver instead of ANGLE
      • Code experimentation with the existing extension would be good
    • Automated fuzzer test infrastructure
  • Hardware coverage
    • utest, other paid outsource coveraging
    • companies do confidential testing
    • Run through a set of test pages
  • Publicize bounties related to graphics drivers exposed by FF a bit more

Meeting Ended Here

    • Shader validation
    • Vendor outreach
    • Relates to work happening on mozilla-central.
      • Development updates on UI work, platform features, and other projects.