The Sound of Silence: Mining Security Vulnerabilities from Secret Integration Channels in Open-Source Projects

TL;DR

This paper introduces a data-mining approach to detect security vulnerability fixes in open-source projects that bypass standard private development channels, revealing potential early exploit opportunities before public disclosure.

Contribution

The paper presents a novel method for identifying non-public vulnerability fixes in open-source projects by analyzing public development artifacts, highlighting vulnerabilities in responsible disclosure practices.

Findings

Detected 29 commits addressing 12 vulnerabilities in Linux kernel

Provided a temporal advantage of 2 to 179 days for exploit development

Showed that private vulnerability fixes can be inferred from public data

Abstract

Public development processes are a key characteristic of open source projects. However, fixes for vulnerabilities are usually discussed privately among a small group of trusted maintainers, and integrated without prior public involvement. This is supposed to prevent early disclosure, and cope with embargo and non-disclosure agreement (NDA) rules. While regular development activities leave publicly available traces, fixes for vulnerabilities that bypass the standard process do not. We present a data-mining based approach to detect code fragments that arise from such infringements of the standard process. By systematically mapping public development artefacts to source code repositories, we can exclude regular process activities, and infer irregularities that stem from non-public integration channels. For the Linux kernel, the most crucial component of many systems, we apply our method to a period of seven months before the release of Linux 5.4. We find 29 commits that address 12 vulnerabilities. For these vulnerabilities, our approach provides a temporal advantage of 2 to 179 days to design exploits before public disclosure takes place, and fixes are rolled out. Established responsible disclosure approaches in open development processes are supposed to limit premature visibility of security vulnerabilities. However, our approach shows that, instead, they open additional possibilities to uncover such changes that thwart the very premise. We conclude by discussing implications and partial countermeasures.