IccTA vs. DidFail: Inter-Component, Inter-Application Data Flow Analysis in Android Applications

Eric | April 30, 2014

We are happy to announce IccTA, a new tool for tracking data flows between Android components and even between Android applications. IccTA is a joined work together with Li Li, Alexandre Bartel, Jacques Klein, Yves Le Traon from the University of Luxembourg, Damien Octeau and Patrick McDaniel from the Pennsylvania State University, Steven Arzt, Siegfried Rasthofer and Eric Bodden from EC SPRIDE. IccTA is a tool performing static taint analysis for one or multiple Android applications. It leverages Epicc to connect Android components and FlowDroid to model the life-cycles of components and perform the taint analysis.

The taint analysis is performed intra- and inter-components, which improves the precision of the analysis. IccTA outperforms all other available tools (FlowDroid and AppScan) by reaching a precision of 95.0% and a recall of 82.6% on DroidBench.
When analyzing multiple applications, IccTA first merges them into one then performs the analysis.

Almost exactly the same moment, there came up an additional tool call DidFail from the Carnegie Mellon University, which is a similar approach to IccTA.
IccTA and DidFail both rely on Epicc and FlowDroid to find data leaks between components of Android applications. They can both detect intra- and inter-component leaks within a single application or between multiple applications. Even though they leverage the same tools to compute links between components and perform data-flow analysis, implementation differences result in differences in term of precision.

In the following we would like to do a rough comparison of both tools:

IccTA vs. DidFail:

Currently, FlowDroid does not support callbacks for bound services. DidFail does not support these either since it relies on FlowDroid. On the other hand, IccTA does add its own implementation for bound services callbacks. This can quickly be fixed in FlowDroid, but at the moment lowers the precision of DidFail.

DidFail uses a “path matching” approach. This means that leaks between components cannot be computed in a single step but in two steps. In the first step, partial paths are computed in components (that is from “source” to an “inter-component-method” such as “startActivity” in the first component and from “getIntent()” to “sink” in the second component).
In the second step, partial paths are combined using the path matching approach.
The combinations yield full data flow paths from sources to sinks. The problem is that in some situations the path matching approach over-approximates the number of possible paths. Take the following example:

intercomponent

First, let’s start with the intra-component flows:

ButtonOnClickListener: FlowDroid detects a flow from “getDeviceId()” to “startActivityForResult()” which is an “inter-component-method” (red arrows)

Activity 3: FlowDroid detects a flow from “getIntent()” to “setResult()” which is also an “inter-component-method” (green arrow)

Activity 2: FlowDroid detects a flow from “getStringExtra()” to “Log.i()” (blue arrow)

– Activity 1: FlowDroid detects a flow from “getStringExtra()” to “Log.i()” (blue arrow)

Well, this are no news. The news are the ability to track inter-component flows in a really precise way. There are two privacy leaks through inter-component flows:

– (a1) -> (c1)

– (a2) -> (c2)

This is the result of IccTA. Instead, DidFail may produce four privacy leaks (two false positives) since they have a “path matching” approach:

– (a1) -> (c1)

– (a2) -> (c2)

– (a1) -> (c2), false positive

– (a2) -> (c1), false positive

For future work, we will intensive compare both tools to get a better understanding about precision and recall.

 

(This article was written by Li LiAlexandre Bartel and Siegfried Rasthofer)

Cross-posted from SEEBlog

Comments
Comments Off on IccTA vs. DidFail: Inter-Component, Inter-Application Data Flow Analysis in Android Applications
Categories
Research

Sieben Punkte für mehr Softwaresicherheit

Eric | April 19, 2014

Die aktuelle Heartbleed-Schwachstelle zeigt, wie wichtig es ist, die Sicherheit von Software zu verbessern. Konkrete Handlungsempfehlungen dazu diskutierten IT-Experten im Eberbacher Gespräch zu Software Security. Neben der Entwicklung besserer Testwerkzeuge fordern die Teilnehmer, die Sicherheit von Software bei öffentlichen Ausschreibungen stärker zu berücksichtigen sowie eine Diskussion der Haftungsfragen. Das Fraunhofer-Institut für Sichere Informationstechnologie SIT hat die Ergebnisse jetzt in einem Bericht veröffentlicht, der die wichtigsten Herausforderungen und passende Lösungsansätze beschreibt. Hier lässt sich das Positionspapier kostenlos herunterladen.

Software ist heute so komplex, dass Menschen selbst schwerwiegende Fehler trotz intensiver Prüfung nicht erkennen können. So bemerkte auch der Prüfer im Heartbleed-Fall den Fehler nicht. Dabei handelte es sich um Open-Source-Software, deren Programmcode sogar öffentlich einsehbar und nachprüfbar ist. Wie bei vielen Open-Source-Projekten nutzten Unternehmen den kostenlosen Code und sorgten so unabsichtlich für eine Verbreitung des Fehlers. „Das Beispiel zeigt, wie wichtig es ist, die Sicherheitsqualität von Programmcode vor dem Einsatz besser zu prüfen, und wie gefährlich die Nutzung von fremdem Code ist“, sagt Prof. Michael Waidner, Leiter des Fraunhofer SIT und Direktor des European Center for Security and Privacy by Design (EC SPRIDE). „Auch wenn noch nicht klar ist, welche Schäden durch die Schwachstelle entstanden sind, zeigt das Beispiel doch erneut, dass es wesentlich teurer ist, Softwarefehler nachträglich zu beheben, als sie in der Entwicklungsphase zu beseitigen.“

Um die Entwicklung sicherer Software zu fördern, erarbeiteten die Teilnehmer des Eberbacher Gesprächs sieben konkrete Empfehlungen: Dazu zählt neben der Beantwortung der Haftungsfrage die Entwicklung von flexiblen Sicherheitsprozessen, die sich auch für kleine und mittlere Softwarehersteller eignen. Neben einer verbesserten Ausbildung von Programmierern sollten auch die Vergaberichtlinien für Behörden so geändert werden, dass Mindestanforderungen hinsichtlich der IT-Sicherheit erfüllt werden. Um Unternehmen Anreize zu geben, die Sicherheit eingesetzter Software zu erhöhen, müssen Manager die Kostenvorteile von sicherer Software berechnen können, etwa mit Hilfe von neuen quantitativen Modellen. Darüber hinaus braucht es nach Meinung der Teilnehmer auch neue Zertifizierungsmethoden, die dem rasanten Tempo der Softwareentwicklung entsprechen, sowie neue Tools zur Schwachstellen-Aanalyse. „Gerade im Bereich der automatisierten Testwerkzeuge ist die deutsche Forschung besonders stark“, sagt Michael Waidner. „Neue Methoden erlauben es zum Beispiel, Fehler im Programmcode schneller und besser zu finden. Diese Ansätze gilt es jetzt, in Produkte zu verwandeln.“ Auf lange Sicht könnte sich auch eine Haftungsklärung positiv auf IT-Sicherheit und Datenschutz auswirken. (Oliver Küch, Fraunhofer SIT)

Cross-posted from SEEBlog

Comments
Comments Off on Sieben Punkte für mehr Softwaresicherheit
Categories
Research