Search

The OS kernel, which has full system privileges, is an attractive attack surface. A kernel fuzzer that targets system calls in fuzzing is a popular tool for discovering kernel bugs that can induce kernel privilege escalation attacks. To the best of our knowledge, the relevance of code coverage, which is obtained by fuzzing, to the system call has not been studied yet. For instance, modern coverage-guided kernel fuzzers, such as Syzkaller, estimate code coverage by comparing the entire set of executed basic blocks (or edges) regardless of the system call relevancy. Our insight is that the system call relevancy could be an essential performance indicator for realizing kernel fuzzing. In this regard, this study aims to assess the system call-related code coverage of kernel fuzzers. For this purpose, we have developed a practical assessment system that leverages the Intel PT and KCOV and assessed the Linux kernel fuzzers, such as Syzkaller, Trinity, and ext4 fuzzer. The experiments on different kernel versions demonstrated that approximately 32,000–47,000 functions are implemented in the Linux kernel, and approximately 9.7–15.2% are related to the system call. Our finding is that fuzzers that achieve higher code coverage in conventional metrics do not execute more basic blocks related to system calls. Thus, we recommend that kernel fuzzers use both system call-related functions and regular basic blocks in coverage metrics to assess fuzzing performance or to improve coverage feedback.

Firmware vulnerabilities raise serious security concerns with the rapid growth in connected embedded devices. Fuzzing is an effective dynamic testing technique to find those vulnerabilities; however, firmware fuzzing is very limited by hardware dependence, such as on-chip and off-chip peripherals. The latest elegant approaches are making substantial progress in hardware-independent firmware fuzzing, but there is room for further improvement. We observe that hardware-independent peripheral modeling is scalable but slow at the register level; in contrast, at the abstract function level, it is fast but has limited scalability. Firmware fuzzing is still challenging in terms of achieving both scalability and efficiency. To address this problem, we present a dual-level approach that leverages register level modeling and selective function level modeling in a hybrid manner. Our method starts firmware fuzzing at the register level and connects peripheral handlers while executing hardware abstraction layer functions. We evaluate our method in terms of efficiency, scalability, and effectiveness with four real-world firmware and demonstrate the possibility of relatively fast and scalable firmware fuzzing that combines the benefits of the two levels.

To estimate the impact of implementing in-hospital enterovirus (EV) polymerase chain reaction (PCR) testing of cerebrospinal fluid (CSF) with same-day turn-around-time (TAT) on length-of-stay (LOS), antibiotic use and on cost per patient with suspected EV meningitis, compared with testing at an outside reference laboratory. A model-based analysis using a retrospective cohort of all hospitalized children with CSF EV PCR testing done between November 2013 and 2017. The primary outcome measured was the potential date of discharge if the EV PCR result had been available on the same day. Patients with positive EV PCR were considered for potential earlier discharge once clinically stable with no reason for hospitalization other than intravenous antibiotics. Descriptive statistics and cost-sensitivity analyses were performed. CSF EV PCR testing was done on 153 patients, of which 44 (29%) had a positive result. Median test TAT was 5.3 days (IQR 3.9-7.6). Median hospital LOS was 5 days (IQR 3-12). Most (86%) patients received intravenous antibiotics with mean duration of 5.72 ± 6.51 days. No patients with positive EV PCR had a serious bacterial infection. We found that same-day test TAT would reduce LOS and duration of intravenous antibiotics by 0.50 days (95%CI 0.33-0.68) and 0.67 days (95%CI 0.42-0.91), respectively. Same-day test TAT was associated with a cost reduction of 342.83CAD (95%CI 178.14-517.00) per patient with suspected EV meningitis. Compared with sending specimens to a reference laboratory, performing CSF EV PCR in-hospital with same-day TAT was associated with decreased LOS, antibiotic therapy, and cost per patient.

The OS kernel, which has entire system privileges, is an attractive target of attackers. To reduce this threat, we need to find security bugs in the kernel prior to the attackers, and system call fuzzing is a widely used technique for this purpose. However, many system call fuzzers have not been evaluated for coverage performance which is an important indicator in fuzzing. In this poster, we propose a methodology to evaluate the code coverage performance of system call fuzzers with a strategy that combines virtualization and Intel Processor Trace (PT). First, we extract all the functions in the kernel that can be executed by system calls. Then we perform fuzzing with the target system call fuzzer on the guest OS, and record coverage information by leveraging the Intel PT. Finally, we evaluate system call fuzzers by comparing the list of functions related to system calls with the executed functions logged by Intel PT while fuzzing.

FPGAs are field-programmable and reconfigurable integrated circuits; consequently, they entail numerous security concerns. For example, malicious functions such as hardware Trojans (HTs), can be inserted into the circuits in both development and deployment stages, as malicious fabrication and modification are possible even after deployment. Therefore, to detect HTs in FPGAs effectively, it is necessary to exploit both netlists available at the development stage and bitstreams available at deployment stage; this is in contrast with existing approaches, which require source code or gate-level netlists. In achieving this, we encounter two major challenges: effectively exploiting FPGA netlists closer to bitstreams for HTs detection and reverse-engineering bitstreams to netlists at an acceptable level. To address these problems, we develop a bidirectional mechanism for detecting HTs in FPGAs at any stage. To the best of our knowledge, this is the first study on bidirectional HT detection in FPGAs. To address the first challenge, we focus on LUT-level netlists; regarding the second challenge, we directly reverse-engineer bitstreams to LUT-level netlists. For HTs detection, we employ features extracted from LUT-level netlists, which can also be derived from reversed bitstreams and used to identify HTs. We design and implement our system for experimental studies. The experiments achieve a TPR of more than 99.3% and an FPR of less than 0.15% for 15 TrustHub benchmarks in forward and backward (reverse) directions for FPGA Virtex-5 devices.

Since FPGAs are field-programmable and reconfigurable integrated circuits, there are many security concerns that malicious functions like hardware Trojans can be infiltrated into circuits not only in development stages but also in deployment stages -- malicious fabrication and modification are possible even after deployment. To detect hardware Trojans effectively, we must be able to deal with the netlists available at development stages and the bitstreams available at deployment stages -- it is highly desired to reverse-engineer the bitstreams to the netlists, but unfortunately greatly challenging. In this poster, we introduce our project aiming at hardware Trojans detection at both stages in FPGAs, and present our bitstream reverse engineering tool called BRET, recently developed for Xilinx Virtex-5 bitstreams. We also discuss the prospective results and directions.