Security/Meetings/2011-06-01

Meeting notes.

curtisk: security reviews

• moved radar to public wiki
• already done 2x as many reviews for 6 as for 5
• thunder wants to talk about identity with secteam/infrasec again soon (Identity/Verified_Email_Protocol)
• ping curtis if things are missing from Security/Radar
• early meetings being conducted before things land on m-c serve as a guide for future interactions with security team

Riccardo (XSS filter)

• Scope is to provide firefox with filter for reflected xss attacks
• Find things in parameters (via taint tracking/string matching) to see if untrusted content is being used to make a javascript
• IE 8 (proxy request inspection before parsing with regex, then tweaks document) and chrome (embedded checks in the calls to JS API -- no deleting needed, just abort the calls) do this
• IE 8's approach causes more attack surface
• There are false positives (where attacker can disable scripts by tweaking URL parameters) For example, framebusting scripts could be disabled. You could DoS a page.
• So far, it is implemented on top of CSP (built a JS interface), but was hard since the JS engine is decoupled from content in a way that it's hard to find the origin of the calls into JS.
• If you can predicate also on the content of the script, you can decide which inline scripts to run.
• Implementation is done except performance and accuracy evaluation.
• working on a paper for a deadline one week or two from now
• More tests in development
• Thinking about test pilot study to see if it works in the wild.
• This implementation is not limited to detecting entire script elements injected… it's possible for code to add to an existing script element. This implementation looks for a whole parameter somewhere inside a script tag *AND* for the entire script anywhere in the URL.
• Lucas suggested we do a design review with the security team about this feature.

Lucas (Roadmap spreadsheet):

• Last round of voting is up in the spreadsheet
• Lots of votes for UI experiments, sandboxing content, CSP, plugin work, CA issues
• Lucas will morph this into roadmap and then bring to the product team
• This roadmap is just major efforts (small things can be quickly be knocked off regardless of priority)
• Email feedback to Lucas

Brian (Mozilla ID, DNS SEC)

• ID: crypto stuff they're doing … want to get Mozilla Verified Email working in all browsers (means JS library for crypto, NSS in Firefox)
  • Problem is generating random numbers in JS
  • Investigating solution for this
  • All of mozilla ID is about security (authentication) so we should get involved.
• W2SP
  • Cookie stealing attacks... discussion with Ben Adida coming up
  • TLS optimizations from Collin Jackson; Brian wants to figure out how to apply them.
  • Brian talked to Peleus (adobe) who mentioned Adobe will be implementing their own flash sandbox.
  • Lucas suggests adding features so plugins can do their own sandboxing.
• Spoke with Limi about toolbarless app tabs (pending security review next week)
  • No advancements in discussion yet
  • Limi's point is that most people don't understand security indicators in that part of the UI anyway.
  • Brian's recommendation is that we improve them instead of removing them.
  • Lucas says that if we can guarantee it's all on one domain, it's probably okay to remove the URL bar and stuff.
  • Brian: If the site you pin decides to fake the url bar, they could defraud you.
  • Prepare for security meeting next wednesday
• Spoke with Limi about cert manager UI
  • Chaining in the UI is not clear. Limi recommends removing the UI.
  • Limi suggests we move corporate-related certificate management into site-specific
  • Limi: only experts can understand the CA model anyway
  • Brian suggests that it's hard enough for us to understand the UI (as security people), that it's tough to make it useful for the general public.
• Starting to threat modeling websockets today. Lots of people, come help (today).
• Brian wants to recruit people to work on an effort to propose a DNSSEC-type project to be initiated and done. Contact him if you want to work on DNSSEC.
  • Was working on hooks to let folks like Dan Kaminsky write add-ons to do this, but it became really hard to figure out how to deal with multiple add-ons, and many people don't want PSM overridden.
  • shaver/sayrer are having Discussions with google folks on this topic.
  • Makes sense to do this since there are more CA requests coming into the pipeline. Need to start thinking about alternatives for trust.
  • Brandon suggests we're just transferring trust to registrars (a smaller set of authorities).
  • Brian suggests that orgs want '.cn' sites, so there should be a way to indicate authenticity that don't rely on the government running the cc TLDs.
  • If we're going to accept CAs that are government run to bless certs for entities not under their control, we have to think about a better route. Ideally, we need objective criteria.
  • Dvedtiz: technological fix for this to some extent would be nice. Can we domain constrain some of the CAs?
  • bsmith: some korean websites are .com, so we can't restrict the government-mandated CA to .kr.
  • Fundamentally, restricting CAs is a fairness issue. How do we delegate limited trust in a way that's fair? This becomes policy/geopolitics.
  • Bsmith: I think DV can be replaced with DNSSEC; it tells you that if there is a problem the problem is at the web site you're connecting to or the registrar. Problem moves from the client side to the server side.

• Silisec meetup Thur 7:00pm at Faultline in Sunnyvale.