CDF Project- Off-device Fuzzing for Device Drivers

CDF Project- Off-device Fuzzing for Device Drivers CDF Project: Samsung Year 3 - SOW I Linux OS is extensively used in contemporary embedded devices of diverse profiles: mobile phones, TVs, robot vacuums, home IoT devices, and even in safety critical systems such as smart machines and automobiles. Along with their increased internet connectivity, such devices are more exposed to security, privacy and safety threats. Especially, among the components in S/W stack, the OS kernel has the full control of a system and thus often attackers are mainly targeting it. Although there have been lots of efforts to make OS kernel secure and reliable with various defense mechanisms, vulnerabilities in OS kernel have been discovered continuously. The kernel itself can be split into two parts: kernel core and device drivers. Owing to the vast number of Linux users and Linux community efforts, the kernel core gets verified in short time and is well maintained. Meanwhile, according to Google, 85% of the bugs reported against the Android kernel (which is a close fork of Linux) are in driver code due to the fact that the drivers are short lived written by third-party device vendors and less verified. Mobile devices that are constantly being developed and upgraded introduce the growth of numerous device drivers susceptible to security vulnerabilities. To mitigate the threats caused by device drivers, static analysis methods and fuzzing techniques have been proposed. However, static analyses couldnt overcome their innate limitations; unsoundness, path-explosion, and false-positive errors. On the other hand, fuzzing methods are limited in their usage that requires physical H/W, which impedes scalable analyses. Also, the complex code and input data structures of device drivers make analysis tools less effective and infeasible for many cases. Considering the weakness of the driver security, it is crucial to have an automated approach that can tackle the aforementioned limitations in scalable manner. Analyzing device driver on emulated environment is very tempting but there are several strong challenges to overcome. First, automatic analysis is totally blind in the hardware behavior. Moreover, device driver runs in several contexts; user process context on receipt of system calls, interrupt context during handling interrupts and kernel thread context to handle heavy duty driver tasks. Second, H/W resources accessed by a device driver are complex in the most of cases. It is necessary to figure out assigned physical devices register addresses and IRQs, and additional devices accompanied by such as IOMMUs, GPIOs, pin controllers, and voltage regulators. Third, it is hard to guarantee that the emulated results are identical to the results on real devices. The input that can trigger a crash on an emulator may never lead to the crash on a real device.