to enable more powerful analysis of
the core Facebook codebase. Zoncolan is the static analysis tool we built
to find code and data paths that may
cause a security or a privacy violation
in our Hack codebase.
The code in Figure 3 is an example
of a vulnerability prevented by Zoncol-
an. If the member_id variable on line
21 contains the value ../../users/
delete_user/, it is possible to redi-
rect this form into any other form on
Facebook. On submission of the form,
it will invoke a request to https://face-
users/delete_user/ that will delete
the user’s account. The root cause of
the vulnerability in Figure 3 is that
the attacker controls the value of the
member_id variable which is used in
the action field of the <form> element.
Zoncolan follows the interprocedural
flow of untrusted data (for example, user
input) to sensitive parts of the codebase.
Virtual calls do make interprocedural
analysis difficult since the tool gener-
ally does not know the precise type of an
object. To avoid missing paths (and thus
bugs), Zoncolan must consider all the
possible functions a call may resolve to.
SEV-oriented static analysis development. We designed and developed Zoncolan in collaboration with the Facebook
App Security team. Alarms reported by
Zoncolan are inspired by security bugs
uncovered by the App Security team.
The initial design of Zoncolan began
with a list of SEVs that were provided to
us by security engineers. For each bug
we asked ourselves: “How could we have
caught it with static analysis?” Most of
those historical bugs were no longer
relevant because the programming language or a secure framework prevented
them from recurring—for instance, the
widespread adoption of XHP made it
possible to build XSS-free Web pages by
construction. We realized the remaining bugs involved interprocedural flows
of untrusted data, either directly or indirectly, into some privileged APIs. Detecting such bugs can be automated with
static taint flow analysis, 18 which tracks
how the data originating from some untrusted sources reaches or influences
the data reaching some sensitive parts
of the codebase (sinks).
When a security engineer discovers a
new vulnerability, we evaluate whether
that class of vulnerability is amenable to
static analysis. If it is, we prototype the
new rule, iterating with the feedback of
the engineer in order to refine results
to strike the right balance of false posi-tives/false negatives. When we believe
the rule is good enough, it is enabled
on all runs of Zoncolan in production.
We adopt the standard Facebook App
Security severity framework, which associates to each vulnerability an impact
level, in a scale from 1 (best-practice) to
5 (SEV-worthy). A security impact level
of 3 or more is considered severe.
Scaling the analysis. A main chal-
Staying Secure with Zoncolan
lenge was to scale Zoncolan to a code-
base of more than 100 millions of LOC
C++ code; it gained this facility by bor-
rowing ideas from Zoncolan.
One of the original reasons for the development and adoption of Hack was
Figure 4. Funneled deployment of Zoncolan
on call security
Figure 3. Example of a bug that Zoncolan prevents. It may cause the attacker to delete a
user account. The attacker can provide an input on line 5 that causes a redirection to any
other form on Facebook at line 20.