---------- Forwarded message ---------- From: Samuel Henrique <samuel...@debian.org> Date: On Wed, Apr 3, 2024 at 3:21 AM Subject: Fw: security-tracker: A proposal to significantly reduce reported false-positives (no affected-code shipped) To: <debian-security@lists.debian.org> Cc: Hello everyone, I would like to propose something which will lower the amount of reported false-positive CVEs to our users.
# tl;dr We don't have a unique way of stating a CVE does not affect us when we don't build the affected package's feature or hardening blocks exploits, this leads to our users being required to manually distinguish which CVEs affect them and which don't. I propose we mark those cases as not-affected, there's an option to create a new state to indicate that the resulting package is not affected due to the build options. # Problem statement The possible outcomes of a CVE assessment in our security-tracker are[0]: > <no-dsa> | <unfixed> | <undetermined> | <not-affected> | <itp> We also have the following severity levels [0]: > SEVERITY_LEVEL : (unimportant) | (low) | (medium) | (high) "unimportant" being defined as: > unimportant: This problem does not affect the Debian binary package, e.g., a > vulnerable source file, which is not built, a vulnerable file in > doc/foo/examples/, PHP Safe mode bugs, path disclosure (doesn't matter on > Debian). All "non-issues in practice" fall also into this category, like > issues only "exploitable" if the code in question is setuid root, exploits > which only work if someone already has administrative privileges or similar. > This severity is also used for vulnerabilities in packages which are not > covered by security support. We have a problem in the way we assess CVEs when the generated package is not affected (but the source code contains the vulnerability). Our current process is to set "no-dsa" and lower the severity to "unimportant". The result is that "unimportant/no-dsa" CVEs can mean two things: 1) We are affected but we the severity is too low, eg.: packages not covered by security support, the CVE is considered a non-issue by our security-team but we are still affected... 2) We are definitely not affected since we don't build that feature of the software or we have hardening in place which prevents this from being exploited. This leads to our users, who are interested in knowing which CVEs affect their systems, having to check the notes of every CVE on security-tracker to filter-out the false-positives. # Proposed solution: I propose that we start setting CVEs to not-affected also when: * We don't ship the affected source package * We don't build the affected feature * We have hardening which makes the exploit impossible (only in the cases when there's no doubt about it). If we still want to flag the cases where a build with different flags might change that, we can use the "(free text comment)" section of the NOTES[0] to mention it. # Some stats: As a way of sampling the impact of this issue, I've done a high-level check on how many sets of affected package-CVE we have in our debian:stable docker image[1]. Out of the 82 affected package/CVE pairs, 15 were clear cases of our packages not being affected. Out of the rest of those, the majority are other cases where we are reporting non-issues, but those require a deeper investigation so I don't want to assume they also fall under this case. So 18% of the reported affected packages are false-positives. Based on what I've seen, I believe this is a fair estimate to extrapolate. I've listed some examples to this issue[2]. # Alternative solutions: If we really want to distinguish the case when we don't produce any affected packages but the source contains the vulnerability (a build with different flags might result in an affected package), we can create a new tag to show this: not-affected-build-artifacts. [0] https://security-team.debian.org/security_tracker.html#summary-of-tracker-syntax [1] $ grype debian:stable [2] https://security-tracker.debian.org/tracker/CVE-2011-3374 [2] https://security-tracker.debian.org/tracker/CVE-2022-0563 [2] https://security-tracker.debian.org/tracker/CVE-2017-18018 [2] https://security-tracker.debian.org/tracker/CVE-2019-19882 [2] https://security-tracker.debian.org/tracker/CVE-2023-28320 Cheers, -- Samuel Henrique <samueloph>
signature.asc
Description: OpenPGP digital signature
