A survey of the double‐fetch vulnerabilities

Race conditions widely exist in concurrent programs, and concurrency errors caused by harmful races could lead to severe system failures. A double fetch is a typical situation when the system kernel inevitably accesses user space data multiple times, and it turns into a vulnerability when the data consistency is violated under a special race condition between kernel and user space. In this survey, we present the first (to the best of our knowledge) comprehensive study on double‐fetch vulnerabilities in the real world. Our study is based on the investigation of 91 real‐world double‐fetch vulnerabilities collected from the CVE database and other relevant reports, which covers a period of recent 12 years. Our work reveals some interesting findings on the double‐fetch vulnerabilities, ranging from the various occurrences across different kernels and system levels to the involvement of specific patterns. We also divide the consequences that are usually caused by the double‐fetch vulnerabilities into four categories and discuss each, summarize viable exploitation techniques from existing works, provide useful guidances to detect and practical strategies to prevent double‐fetch vulnerabilities.

[1]  Jong-Deok Choi,et al.  An efficient cache-based access anomaly detection scheme , 1991, ASPLOS IV.

[2]  Michael Hicks,et al.  LOCKSMITH: Practical static race detection for C , 2011, TOPL.

[3]  Julia L. Lawall,et al.  Finding Error Handling Bugs in OpenSSL Using Coccinelle , 2010, 2010 European Dependable Computing Conference.

[4]  Shan Lu,et al.  ConMem: detecting severe concurrency bugs through an effect-oriented approach , 2010, ASPLOS XV.

[5]  George Candea,et al.  Data races vs. data race bugs: telling the difference with portend , 2012, ASPLOS XVII.

[6]  Thomas R. Gross,et al.  Protecting applications against TOCTTOU races by user-space caching of file metadata , 2012, VEE '12.

[7]  Victor Pankratius,et al.  Does Transactional Memory Keep Its Promises? Results from an Empirical Study. , 2009 .

[8]  M SwiftMichael,et al.  Applying transactional memory to concurrency bugs , 2012 .

[9]  Robert N. M. Watson,et al.  Exploiting Concurrency Vulnerabilities in System Call Wrappers , 2007, WOOT.

[10]  Steve J. Chapin,et al.  Detection of file-based race conditions , 2005, International Journal of Information Security.

[11]  Nancy G. Leveson,et al.  An investigation of the Therac-25 accidents , 1993, Computer.

[12]  Jeff Huang,et al.  Persuasive prediction of concurrency access anomalies , 2011, ISSTA '11.

[13]  SenKoushik.  Race directed random testing of concurrent programs , 2008 .

[14]  Gynvael Coldwind,et al.  Identifying and Exploiting Windows Kernel Race Conditions via Memory Access Patterns , 2013 .

[15]  Pin Zhou,et al.  HARD: Hardware-Assisted Lockset-based Race Detection , 2007, 2007 IEEE 13th International Symposium on High Performance Computer Architecture.

[16]  Crispin Cowan,et al.  RaceGuard: Kernel Protection From Temporary File Race Vulnerabilities , 2001, USENIX Security Symposium.

[17]  L MinSang,et al.  An efficient cache-based access anomaly detection scheme , 1991 .

[18]  Koushik Sen,et al.  Race directed random testing of concurrent programs , 2008, PLDI '08.

[19]  S HofmannOwen,et al.  Is transactional programming actually easier , 2010 .

[20]  KasikciBaris,et al.  Data races vs. data race bugs , 2012 .

[21]  Xu Zhou,et al.  Detecting harmful data races through parallel verification , 2015, The Journal of Supercomputing.

[22]  George Candea,et al.  RaceMob: crowdsourced data race detection , 2013, SOSP.

[23]  Emmett Witchel,et al.  Is transactional programming actually easier? , 2010, PPoPP '10.

[24]  Xu Zhou,et al.  RaceChecker: Efficient Identification of Harmful Data Races , 2015, 2015 23rd Euromicro International Conference on Parallel, Distributed, and Network-Based Processing.

[25]  Salvatore J. Stolfo,et al.  Concurrency attacks , 2012, HotPar'12.

[26]  Dawson R. Engler,et al.  RacerX: effective, static detection of race conditions and deadlocks , 2003, SOSP '03.

[27]  Xiang Cai,et al.  Exploiting Unix File-System Races via Algorithmic Complexity Attacks , 2009, 2009 30th IEEE Symposium on Security and Privacy.

[28]  David A. Wagner,et al.  MOPS: an infrastructure for examining security properties of software , 2002, CCS '02.

[29]  Xu Zhou,et al.  Collaborative Technique for Concurrency Bug Detection , 2014, International Journal of Parallel Programming.

[30]  Sebastian Burckhardt,et al.  Effective Data-Race Detection for the Kernel , 2010, OSDI.

[31]  Milos Prvulovic,et al.  CORD: cost-effective (and nearly overhead-free) order-recording and data race detection , 2006, The Twelfth International Symposium on High-Performance Computer Architecture, 2006..

[32]  Pengfei Wang,et al.  How Double-Fetch Situations turn into Double-Fetch Vulnerabilities: A Study of Double Fetches in the Linux Kernel , 2017, USENIX Security Symposium.

[33]  Felix Wilhelm.  Tracing Privileged Memory Accesses to Discover Software Vulnerabilities , 2015 .

[34]  Jun Chen,et al.  Towards a better collaboration of static and dynamic analyses for testing concurrent programs , 2008, PADTAD '08.

[35]  Frank Close.  1. Much ado about nothing , 2009 .

[36]  Matt Bishop,et al.  Checking for Race Conditions in File Accesses , 1996, Comput. Syst..

[37]  Sorin Lerner,et al.  RELAY: static race detection on millions of lines of code , 2007, ESEC-FSE '07.

[38]  Shan Lu,et al.  Applying transactional memory to concurrency bugs , 2012, ASPLOS XVII.

[39]  Josep Torrellas,et al.  ReEnact: using thread-level speculation mechanisms to debug data races in multithreaded codes , 2003, ISCA '03.

[40]  Josep Torrellas,et al.  SigRace: signature-based data race detection , 2009, ISCA '09.