To provide evidences that support the hypothesis, the qualitative analysis focuses on showing how ScoriaX meets the extraction requirements.
H1a: Express design intent
The architect can refine the annotations to express design intent, as needed. In AFS, the architects can check that an anonymous user cannot execute administrator commands, where each command has a corresponding class that implements the interface Command. This
may lead a vulnerability because executing a command, such as RMDIR, would enable an attacker to remove folders on the server. After adding the initial annotations and examining the extracted OGraph, the architect decides to refine the annotations by making all the administrator commands from the domain LOGIC into a separate domain COMMANDS. The AFS OGraph has 4 different dataflow edges that refer to an object representing an anonymous user. The architect can then impose the constraint that no dataflow edges that refer to the anonymous user has as a destination an object in the domain COMMANDS.
H1c: Sound object graph
The architect assumes that the object graph shows all possible objects and edges that may occur in any possible program run. Fewer than 20% of the objects are flow objects, but resolving lent and unique is crucial for meeting the soundness requirement (H1c). Otherwise, in the presence of flow objects, some runtime objects and edges would have no representative in the extracted object graph. To resolve lent and unique, the analysis also meets the aliasing requirement (H1d) using a separate, flow-insensitive but domain-sensitive analysis. The value flow analysis is crucial for extracting dataflow edges because about 20–40% of variables are declared lent and unique [134].
H1e: Precise object graph
ScoriaX meets the precision requirement: the extracted graph does not suffer from ex- cessive merging and is not a fully connected graph. In fact, the extracted object graphs are sparse and have a comparable number of objects and non-self dataflow edges. For AFS, the number of non-self dataflow edges is 328, which is one order of magnitude lower than the number of edges in a fully connected graph. Still imprecision occurs if the architects overuse the annotations shared, lent, and unique (Section 3.3.4, page 81).
The AFS OGraph has a maximum of 42 dataflow edges from the protocol interpreter to the client session. These dataflow edges refer to objects that represent user information, files, and
an object of type ServerSocket. Since some of these objects represent confidential data, the architect need to ensure that the object of type ServerSocket provides encryption to avoid eavesdropping. Tracing to code from the dataflow edge that refers to a ss:ServerSocket leads to the method invocation ioSession.getAttribute(name), but a closer inspection reveals that the edge is a false positive. Since the return type of the method getAttribute of the class FtpIoSession is Object and is annotated shared, the analysis finds all the objects in shared including the object of type ServerSocket. To avoid the false positives that may further lead to false positives when executing constraints, the architects can fine- tune the annotations to improve precision. That is, one can change the annotation such that the object of type ServerSocket is in OWNED instead of shared. In general, using shared is discouraged since little reasoning can be done about such objects.
H1f: Summarization
By referring to a pair (type, domain) corresponding to an abstract object, the architects can reason about objects that have the same conceptual purpose or the same security prop- erty, even if they are created in different locations in the code. In each system, the maximum of dataflow edges that refer to the same object occurs for dataflow edges that refer to the object of type String in the domain shared, but there are examples that are more interest- ing. Architects can fine tune annotations and use hierarchy to distinguish between objects of type String that have different conceptual purposes. The UPMA OGraph has different objects of type String to distinguish between the password and the account name where only the password represents confidential information. There are 4 dataflow edges that refer to the password, and 10 that refer to the account name. The architects can reason about the destination of the dataflow edges that refer to a password, check if it is an untrusted sink, or if another edge with an untrusted sink as a destination refers to the destination.
H1g: High-level view
ScoriaX meets the high-level view requirement (H1g) where the object-domain hierarchy helps improving precision of the analysis. The depth of the object-domain hierarchy seems constant compared to the size of the graph. Empirical data [134] shows that object-domain hierarchy achieves 1x-10x reduction in the number of objects in the domains declared by the root class. These objects are architecturally relevant and the object graph fits on one page by showing only these objects with their substructure collapsed and dataflow edges lifted to their first visible ancestor of the source and destination. The architects can still recover the details by expanding the substructure. Reasoning about security requires more than tracking objects visually, and architects need support to query the object graph, which Scoria also provides (Section 5.3, page 110).
H1h: Scalability
The extraction analysis needs to scale to real-world applications of at least a few thousands lines of code. Tradeoffs needs to be considered: the more precise the extraction analysis is, the less scalable it is. ScoriaX achieves scalability (H1h) for systems the size of a typical Android app (2–30KLOC) [88], but their size is too small to claim that ScoriaX meets the scalability requirement. Computing transitive value flow is probably a culprit in limiting the scalability of the extraction analysis. Another bottleneck that limits the scalability of the analysis is the effort of adding annotations. For UPMA, I estimate the effort of adding annotations and extracting the object graph to be 2 hours/KLOC, where part of the effort was required to summarize the Android framework (Table 4.4). Conceivably, less effort would be needed to annotate another Android application since some of the summaries can be reused.
Table 4.4: UPMA: Estimated effort to annotate and reason about security.
Phase Effort Percent
Adding annotations 8.5 hours 68% Extracting object graph 2 minutes <1% Writing constraints 1 hour 8% Refining annotations 3 hours 24%
Total 12.5 hours 100%
4.5
Summary
This chapter shows an evaluation by running ScoriaX on three applications with more than 20KLOC of Java code. The chapter discusses examples of false positive edges due to excessive use of annotations shared, but also shows how the architects can increase precision by placing objects of the same type in different domains. Architects can find cases where more precision is needed, and fine-tune the annotations to help the analysis achieve more precision as needed. This chapter shows that ScoriaX can be used for positive assurance and does not report any vulnerability. A more systematic evaluation, where ScoriaX is incorpo- rated in Architectural Risk Analysis, and architects write machine-checkable constraints is in Chapter 6(page 117).
Chapter 5
The Scoria Approach
This chapter1 introduces a semi-automated approach named Scoria that finds security
vulnerability using constraints on the abstract object graph. The chapter discusses how Scoria meets the security analysis requirements (Section1.4, page9) and presents the security model that allows architects to query the object graph and write constraints. By separating constraints from extraction, the model is extensible (SC3) such that architect can write application-specific constraints. Since the model extends an object graph that is hierarchical and has dataflow edges that refer to objects, Scoria allows architects to write constraint in terms of object provenance (H2a) and indirect communication (H2f).
In the following, Section 5.1 gives an overview of Scoria. Section 5.2 defines the con- cepts used by the approach. Section 5.3 describes a security model, and Section 5.4 con- cludes.