21. Data Tracking

What this lecture covers

This lecture asks how a system can stop an app from secretly sending your sensitive data (location, contacts, IMEI) over the network, even when the app already has legitimate permission to access both that data and the network. It walks through TaintDroid, a system that tracks ("taints") sensitive data as it flows through the Dalvik VM and blocks tainted data from leaving through the network. It sits in the course's run of lectures on information flow and builds on earlier discussion of side channels and data lifetimes.

After watching, you should be able to explain why Android's permission model can't express this kind of policy, describe how taint labels propagate through VM instructions, arrays, IPC messages and files, and recognize the limits of taint tracking, including implicit flows and taint explosion. The lecture also briefly covers TightLip, an alternative approach that works on unmodified legacy programs.

Key ideas

• Taint tracking: tags sensitive data with a label as it is read, then follows that label through computation so the system can block or flag it before it leaves over a sensitive "sink" such as the network.
• Sources and sinks: TaintDroid defines sources (GPS, contacts, IMEI, and similar sensitive inputs) and treats the network as the sink it cares about.
• 32-bit taint vector: each value carries a 32-bit integer, one bit per taint source, so combining taint is just a bitwise OR; efficient but limited to 32 distinct sources.
• Conservative tainting: arrays, IPC messages and files each get a single taint tag equal to the union of their parts, which may overestimate taint but never lets tainted data slip through unflagged.
• Native code gap: taint tracking stops at native (C/C++) method boundaries, so TaintDroid's authors manually specify tainting rules for the VM's own native calls.
• Implicit flows: information can leak through a value's control flow (e.g. a branch taken based on sensitive data) without any direct assignment, and TaintDroid's data-flow tracking cannot catch this on its own.
• Taint explosion: overly aggressive tainting, especially of core registers like the stack or frame pointer, can spread taint to nearly everything in the system and make it unusable.
• TightLip and doppelganger processes: an alternative that runs a second copy of a process on scrubbed data and compares its system calls to the original to detect when sensitive data influenced program behavior, without modifying the application.

Walkthrough

Why permissions and app isolation aren't enough (0:00)

The lecture opens by noting that phones hold contacts, location and other sensitive data, and a malicious app with network access could exfiltrate it. Android's permission model can only say whether an app may access a device such as the network, not whether specific sensitive data may flow to it. A proposed fix, banning apps that both read sensitive data and use the network, would break legitimate apps like email clients, miss side channels already covered earlier in the course, and fail to stop colluding apps or tricked apps from exfiltrating data anyway. Real malware already tracks location and IMEI for ads, steals contacts and credentials, and turns phones into spam bots.

TaintDroid's model: sources, sinks and the 32-bit taint vector (10:05)

TaintDroid marks sensors and sensitive databases as sources and treats the network as the sink. Each sensitive value gets a 32-bit vector, one bit per source, which the lecture argues is roughly the right order of magnitude for a phone's sensor and data set, and conveniently matches a machine integer for cheap bitwise operations.

How taint propagates through instructions, arrays, and native calls (13:07)

Taint flows from the right-hand side of an operation to the left: a move instruction copies the source's taint, and a binary operation takes the union of both operands' taint. Arrays get one taint tag for the whole array, which is conservative but keeps storage cheap. Native methods, which the Dalvik interpreter cannot see inside, are handled by manually written rules that assign taint to their outputs based on their known semantics; the lecture notes this is workable because relatively few native methods are exposed.

Tainting Java state, IPC, and files (27:21)

IPC messages and files each receive a single conservative taint tag covering all their contents. Local variables, method arguments, object fields, static fields and arrays all need taint storage, and TaintDroid places each variable's taint tag physically next to the variable (on the stack or in the object layout) so both can be fetched together for good cache behavior.

Detecting leaks and TaintDroid's real-world findings (36:26)

TaintDroid watches the network interface and blocks or flags data carrying any taint bit. In practice, apps were found sending location and phone numbers to remote servers without disclosing it, technically within their granted permissions but not in the terms users actually agreed to. Overhead was modest: about 3 to 5% extra memory and 3 to 29% extra CPU.

Counterintuitive cases and implicit flows (40:28)

A linked list example shows that computing a list's length touches only "next" pointers, not the tainted data field, so the result carries no taint even though it was derived from a tainted structure. The lecture then turns to implicit flows: a branch taken based on a tainted value can leak information into a variable with no direct data dependency. One mitigation taints the program counter itself during a branch so the taint propagates to values assigned inside it, though this can overtaint simple cases.

Lower-level tracking, taint explosion, and language-level labels (48:39)

Tracking taint at the x86 or ARM instruction level would remove the need for manual native-method rules but is expensive and error-prone, and can cause taint explosion if core registers like the stack or frame pointer get tainted. The lecture contrasts TaintDroid's fixed, system-defined labels with languages that let programmers define their own labels and static, compile-time information-flow checks, which are preferable to runtime checks because a runtime check's pass/fail outcome can itself become a covert channel.

TightLip: taint tracking without modifying the application (1:10:59)

TightLip scrubs sensitive files into dummy versions, then runs a "doppelganger" process alongside the real one reading the scrubbed data. If the doppelganger's system calls match the original's, the sensitive data likely had no effect; if the doppelganger diverges and tries to make a network call, that signals the data influenced program behavior. It works on unmodified legacy applications but depends on correct, per-file-type scrubbers.

Before you watch

• Familiarity with the Dalvik VM's register-based execution model and Java's stack, heap, and object field layout is helpful.
• Recall earlier lectures on side channels (such as browser cache leaks), since this lecture references them directly.
• Basic understanding of Android's permission system is assumed.

Check your understanding

1. Why can't Android's standard permission model express a policy like "don't send GPS data over the network"?
2. Why does TaintDroid assign a single taint tag to an entire array instead of tracking taint per element?
3. What is an implicit flow, and why can't TaintDroid's normal data-flow propagation catch it?
4. How does TightLip detect that sensitive data influenced a process's behavior, without ever letting the process see the real data?
5. Why is it preferable to catch information-flow violations with static checking rather than at runtime?