Security/Meetings/2011-12-07

Security Review Questionnaire (decoder)

Designed to be an interactive questionnaire to be filled out before a possible review
- Ask only questions that seem relevant (based on previous answers), to save time and make answering more stress free to the developers
Goal is to answer key questions that will drive the questions/main subjects in security review
Answers could also indicate that we don't need a full review
curtisk suggested we let developers review it that already had a security review, to provide feedback
Preliminary questionnaire at https://intranet.mozilla.org/User:Choller@mozilla.com/SecreviewQuestionnaire#Preliminary_Design
- Needs general feedback and/or good key questions that haven't been covered yet

Is [the stuff said in the meeting] stuff we can say in public / put in the meeting notes? sure
See Milestones section for timeline:
- http://www.w3.org/2011/08/appsecwg-charter.html

birch/native UI has merged to m-c, birch is going away, mobile dev is back in m-c again
- this means native UI will go to Aurora on 12/20
local db changes are finished and will hopefully land this week
- discussion will then happen about what DB to use by default, the android browser store or fennec's own DB
sync design/work is still ongoing

Android Sync has run into some issues packaging on Fennec
They want to ship with Fennec instead of a separate .APK
- Target is to land in beta/aurora
- This means they need to make mobile code freeze at 12/20

Incremental GC progress & fuzzing going along nicely
- But Jesse is still unhappy with the state of gczeal(4). Crashing and asserting in several ways with simple testcases.
  - Still quite early in development
- billm is still working on it
ObjShrink has landed on m-c from JM branch
- JM branch may be used for other developments, probably generational GC, etc.
- Not much fallout, thanks to extensive pre-landing fuzzing :)
  - Good job, fuzzers. :D (we're not resting on our laurels though!)
We now have a server up and running for doing ARM fuzzing (based on emulation)
- ARM board fuzzing using jsfunfuzz natively has also been set up
- Currently running with LangFuzz on jsshell
- gkw will probably eventually try out jsfunfuzz on the emulated qemu ARM server too
- How many ARM-specific issues are you finding?
  - Before we installed this server, we found two ARM specific issues that are now fixed. They are rare of course (because only a small part of the JS engine is ARM specific), but they are part of our mobile goal right now.
- Also the emulation has a speed penalty of ~ 70%
  - How does the speed of emulated ARM compare to the speed of hardware ARM?
    - LangFuzz with 8 threads (in 8 emulated ARM instances) is equivalent to having ~ 5 Tegra boards (which have two cores each).
  - Being native has no speed penalty but is limited by the hardware
- Long term goal for ARM fuzzing is using releng

Data taken from exploit crashes (mostly Blackhole/Eleonore Exploit Kits)
- (Only a draft)
- Data is not statistically representative, but the trend should be accurate: almost 50% are up-to-date with Firefox but are exploitable through plugins
We could probably get much more/better data from Socorro directly by comparing Firefox version vs. Plugin version (where plugin is Flash, Java and Adobe PDF)
Seems to show that there are plenty of users who keep Firefox up to date but not plugins. This means that plugin mitigations will improve real-world security immediately.
- Also keep in mind that "percentage of users who keep Firefox up to date" should improve with our silent-update and addon-compatibility initiatives.

LLCov is a C/C++ code instrumentation tool based on LLVM/Clang: https://github.com/choller/LLCov/
- You can instrument every basic block in the program with a call to an external function that you provide.
  - Instrumentation can be limited easily with black-/whitelists on the file, function and/or line level (e.g. you can instrument only the code affected by a patch, or leave out noise functions)
- Can be used to measure block coverage (equivalent to statement coverage), but coverage data is available 'during' the program run which allows external programs to change their behavior based on current coverage output.
- Because the external function is convertible, you can also report coverage information directly over a network link (might be interesting on embedded devices).
What's the speed overhead?
- Very low, but depends on what the callback does.
- Also, still in experimental stage, it might be possible to improve performance later on. But I would be happy to do reliable measurements on this. If you want to help, let me know.

Silent update wants to land today and they are waiting for our feedback (and would really like to have the feedback today).
need to come up with a list of issues or must have items for landing
- should be inclusive of m-c --> release
Focus on the Service as that is all they want to land right now
if we need to meet on this more we can use the Wed 1pm security review slot
Overall, we're happy with the way the privileged service authenticates the update itself.
But the way it [starts Firefox after the update] is sketchy. The privileged service trusts a "work item" file that says which user to execute as. (The file is placed into a monitored, world-writable directory.)
Some items moved to https://etherpad.mozilla.org/updater-concerns
imelven is requesting assistance with reviewing the code - dchan is going to take a look