Introduction to Dirty COW and Android Vulnerabilities

The Dirty COW (Copy-on-Write) vulnerability, identified as CVE-2016-5195, was a significant privilege escalation flaw in the Linux kernel that sent ripples through the cybersecurity world in 2016. Its impact was far-reaching, affecting virtually all Linux-based systems, including Android devices. This vulnerability allowed a local attacker to gain root privileges by modifying read-only, root-owned files, making it a critical threat for system integrity and security.

For Android, Dirty COW represented a straightforward path to privilege escalation, enabling attackers to bypass security mechanisms and potentially gain full control over a device. While patched in modern kernel versions, understanding its mechanics remains crucial for security researchers, penetration testers, and anyone interested in low-level operating system exploits. This tutorial will guide you through building and executing a Dirty COW Proof-of-Concept (PoC) for Android, providing a practical understanding of how this notorious exploit works.

Understanding the Dirty COW Mechanism

At its core, Dirty COW exploits a race condition in the Linux kernel’s implementation of copy-on-write memory. To grasp the exploit, we must first understand the fundamental concepts it abuses:

• Copy-on-Write (COW) Memory

  COW is an optimization technique used by operating systems. When multiple processes access the same memory page (e.g., when a process forks and creates a child), they initially share the same physical memory. This shared memory is marked as read-only. If one of the processes attempts to write to that page, the kernel transparently creates a private copy of the page for that process, allowing it to modify its copy without affecting others. This saves memory and speeds up process creation.

• The Race Condition

  The Dirty COW vulnerability arises from a race condition between two specific system calls: madvise(MADV_DONTNEED) and write() via /proc/self/mem.

  1. An attacker first opens a read-only, root-owned file (e.g., /system/etc/hosts) and maps a page of it into memory using mmap with PROT_READ | MAP_PRIVATE. This creates a private, read-only mapping of the file’s content.
  2. Simultaneously, two threads are launched:
     • The first thread repeatedly calls madvise(MADV_DONTNEED) on the mapped page. This call hints to the kernel that the memory content is no longer needed and can be discarded, potentially invalidating the COW protection for that page.
     • The second thread continuously attempts to write to the same mapped memory address using /proc/self/mem. /proc/self/mem allows a process to modify its own memory directly.
  3. The race condition occurs because, between the time madvise flags the page as
     
     Android Mobile Specs & Compare Directory

     Are you researching mobile hardware properties, processor SoCs, GPU chipsets, or RAM configurations? Access our complete specs catalog to compare up to 5 devices side-by-side!

     Compare Devices Specs →