Sending with fake account
OSS program
Absent
Immature
vulnerabilities
conditions
vuln. conditions
Analyze
Construct
Hypocrite
commits
Stealthy
opportunities
Identify
hypocrite
commits
Adversary
Choose
OSS community
Fig. 2: An overview of the vulnerability-introducing method.
set of studies and measurements to understand the criticality,
commonness, and practicality of hypocrite commits.
III. ISSUES WITH THE OSS PATCHING PROCESS
We have extensive interaction experience with OSS
communities—reporting bugs, submitting patches, and analyz-
ing patches. We found that vulnerability-introducing patches
are not uncommon; even experienced maintainers may (un-
intentionally) submit vulnerability-introducing patches. We
believe that when the committers are malicious, the issue
would aggravate. To understand the causes of the problem, we
first conduct a study on vulnerability-introducing patches that
evaded maintainers. Note that in these cases, the committers
did not intentionally introduce the vulnerabilities.
A dataset of vulnerability-introducing patches.
We choose
the Linux kernel as an example of the OSS program because
it is foundational and widely used—billions of Android and
Internet of things (IoT) devices are also based on the Linux
kernel. We use script code to analyze all the CVE-assigned
vulnerabilities in the Linux kernel whose introducing and fixing
commits are available. As defined in §
II-B
, we regard the
patches with less than 30 LOC as minor patches. We found that
9.8% of vulnerabilities were caused by minor patches, which
are used to fix non-functional issues of the program, such as
memory-leak fixes. In total, we collected 138 CVE-assigned
vulnerabilities of different types, which are introduced by minor
patches. We also collected their corresponding introducing and
fixing patches.
Immature vulnerabilities.
In general, the forming of vulnera-
bilities requires multiple conditions. When not all vulnerability
conditions are present, the vulnerability is not formed yet. We
call such a potential vulnerability as an immature vulnerability.
Our study (see §
VII-A
) shows that OSS tends to have a
large number of immature vulnerabilities, which poses hidden
insecurity to OSS. First, immature vulnerabilities are not real
vulnerabilities, so bug detectors (both static and dynamic ones)
may not report them at all. Second, as will be shown in
§
III-A
, OSS communities typically refuse to accept preventive
patches for immature vulnerabilities. The Linux community
explicitly state that they will not accept preventive patches [
26
].
Third, when the remaining conditions are introduced, due to
the complexity of code (see §
III-B
) and other reasons, the
newly introduced vulnerabilities often slip through the patch
review, such as the example in Figure 1. In the following, we
discuss three factors that allow a malicious committer to turn
an immature vulnerability into a real one.
A. OSS Maintenance Philosophy—No Preventive Patches
Maintenance strategies vary for different open-source
projects. These strategies are important as they decide how
patches would be accepted or rejected.
Rejecting preventive patches.
Widely used OSS projects,
especially large ones that are implemented in unsafe pro-
gramming languages, e.g., the Linux kernel and Firefox, are
receiving overwhelming bug reports and patches. For example,
on average the Linux community receive more than 400 email
bug reports [
27
] per day. However, OSS projects have limited
maintainers and resources to review the patches. On the other
hand, such projects put especial care on performance, and
thus try to make their code as concise as possible. As a
result, preventive patches that stop immature vulnerabilities
(i.e., potential future vulnerabilities) are not welcome and would
likely be rejected.
Rejecting patches for bugs without PoC.
Some OSS projects
may even refuse to accept patches without a PoC (i.e., the
exploitability is not confirmed with a test case), although the
bug is manually or statically confirmed. For example, although
the Android Open Source Project does not explicitly state
so, it generally requires a PoC. We reported multiple patches
without a PoC for real bugs, and none of them was accepted.
We believe such a case is common for OSS projects running
bug bounty programs, i.e., the rewards typically require a PoC.
The Linux patch guidance.
The Linux documentation
explicitly lists their rules for accepting patches into stable
versions. We summarize the important ones in Table I. In
particular, Linux will not accept preventive patches, large
patches with more than 100 lines, trivial patches fixing issues
like white-space, and patches for theoretical race conditions.
Rules for patches accepted into “-stable” tree
Must be obviously correct and tested
Cannot be bigger than 100 lines
Must fix only one thing
Must fix a real bug
No “theoretical race condition” issues
Cannot contain “trivial” fixes (e.g., white-space cleanup)
TABLE I:
Common rules for patches to be accepted into the stable
tree, provided by the Linux kernel documentation [26].
B. Complexity and Customization of Code
By analyzing the vulnerability-introducing patches, we
summarize general reasons for the review process failing to
catch the introduced vulnerabilities.
4