Search

Deep neural networks (DNNs) gained in popularity as an effective machine learning algorithm, but their high complexity leads to the lack of model interpretability and difficulty in the verification of deep learning. Fuzzing, which is an automated software testing technique, is recently applied to DNNs as an effort to address these problems by following the trend of coverage-based fuzzing. However, new coverage metrics on DNNs may bring out the question of which layer to measure the coverage in DNNs. In this poster, we empirically evaluate the performance of existing coverage metrics. By the comparative analysis of experimental results, we compile the most effective layer for each of coverage metrics and discuss a future direction of DNN fuzzing.

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.