{{Header}}
{{Title|title=
Kicksecure and Whonix Security Vulnerability Reporting and Handling Process
}}

{{intro|
How to report security bugs in the Kicksecure and Whonix operating systems, and how we handle such reports.
}}

{{draft}}

= Vulnerability Reporting and Handling Process =
'''Please take the time to read this document carefully before reporting a bug in Kicksecure or Whonix that potentially impacts system security. Doing so will help you protect the safety of our users, show you what to expect during the vulnerability triage process, and help you create a useful, actionable vulnerability report.'''

The developers of Kicksecure and Whonix take security vulnerabilities very seriously. All reports we receive will be dealt with as soon as reasonably possible regardless of how they are filed. However, following some simple rules will help us fix issues faster and with less danger to end-users.

== What constitutes a security vulnerability in Kicksecure ==
Kicksecure's core goal is to provide the user a Debian environment that that makes it substantially harder to compromise the confidentiality, integrity, and (to some degree) availability of the OS and most software running on the OS than would be the case when running unmodified Debian. Secondary to that, it aims to provide a wide variety of security-related features to protect a user from many physical and non-physical attacks. A security vulnerability in Kicksecure is anything that:

* Makes it ''easier'' to compromise the confidentiality or integrity of the OS or software running on the OS than an equivalent vanilla Debian system,
* Makes it ''substantially and unexpectedly easier'' to compromise the availability of the OS or software running on the OS than an equivalent vanilla Debian system, ''when used in a server context'', or
* Prevents a Kicksecure-specific feature from mitigating an attack it was designed to mitigate.

Bugs in pre-release software are explicitly in scope for Kicksecure's vulnerability reporting policy. This is because some end-users are expected to use <code>-testers</code> and even <code>-developers</code> repos, and thus bugs in pre-release software may affect end-users.

Examples of things that are out-of-scope for Kicksecure's security policy include, but are not limited to:

* Bugs that result in misbehavior that does not pose a direct threat to the user's safety beyond that which would exist in an equivalent vanilla Debian system.
* Most DoS weaknesses. DoS is only considered a vulnerability in server contexts, and then only if the issue is significantly worse on Kicksecure than on Debian, in a way that isn't to be expected with Kicksecure's feature set.
* Bugs that result in a system hardening setting being unexpectedly disabled when that setting is not enabled in vanilla Debian by default.
* Bugs in preinstalled software that is not maintained by the Kicksecure develoeprs.

The first three kinds of bugs should be reported publicly on our forums. The last kind of bug should be reported (potentially privately) to Debian or to the upstream developers of a buggy application.

Some hypothetical vulnerability examples would include:

* "Crafted HTTP headers can trick sdwdate into overwriting an arbitrary file as root despite AppArmor restrictions"
* "apt-get-update-kill-helper privleap action can be abused to acheive local privilege escalation"
* "Logic error in permission-hardener allows a crafted filename to prevent /usr/bin/sudo from being marked non-executable even when permission-hardener config requires it"
* "Invoking org.freedesktop.FileManager1.ShowFolders with crafted input may acheive arbitrary code execution in fm-shim-backend"
* "emerg-shutdown leaves the system permanently hung rather than shutting the system down when the boot drive is abruptly removed"

Some examples of issues that would not be considered vulnerabilities in Kicksecure include:

* "When given crafted input, unicode-show crashes rather than printing information about Unicode in the input"
** Not a vulnerability because it leaves the user no worse off than they would be without unicode-show.
* "Lack of rate-limiting within privleap allows DoS by an unprivileged malicious process"
** Not a vulnerability because there are easier ways to DoS a system as an unprivileged malicious process, i.e. fork bomb.
* "Logic issue in /etc/default/grub.d/40_kernel_hardening.cfg omits ia32_emulation=0 from the kernel command line, allowing 32-bit binaries to run"
** Not a vulnerability because the hardening setting's absence leaves the user no worse off than they would be with vanilla Debian.
* "Crafted text files can run arbitrary commands when they are opened with Vim"
** Not a vulnerability ''in Kicksecure'' because the same issue would appear on vanilla Debian after installing Vim. However, this would be a vulnerability in Vim (at least in Debian's version of it).

If in doubt, please err on the side of submitting a vulnerability report. It is better to send an unnecessary vuln report and be asked to publish or redirect your findings than to publish your findings and learn later that the issue you found is more serious than initially thought.

== What constitutes a security vulnerability in Whonix ==
In addition to the core goals of Kicksecure, Whonix aims to prevent a user from being uniquely identifiable even in the event the Whonix-Workstation VM is compromised, if used properly. This is partially acheived by using virtualization software to separate the anonymizing VM (Whonix-Gateway) from the user's work area (Whonix-Workstation). Numerous measures are also provided to make it harder to fingerprint a user's work environment than it would be if they were using vanilla Debian. Anything that constitutes a security vulnerability in Kicksecure also constitutes a security vulnerability in Whonix. In addition, a bug is a security vulnerability in Whonix if it:

* Enables malware with root-level, kernel-level, or (hypothetically) higher levels of privilege in a Whonix-Workstation VM to determine the public IP address of the user, when the host OS and virtualization software are fully up-to-date.
* Allows malware running in the Whonix-Workstation VM to compromise the integrity of the Whonix-Gateway VM using a vulnerability in software written by Whonix developers as part of Whonix.

Examples of things that are out-of-scope for Whonix's security policy include, but are not limited to:

* Bugs that can only be exploited when the host OS or virtualization software is out of date.
* Bugs that enable malware of any privilege level to determine the public IP address of the user when the malware is running in Whonix-Gateway.
* Bugs that allow malware running in the Whonix-Workstation VM to compromise the integrity of the Whonix-Gateway VM using a vulnerability outside of Whonix's custom-written software.
* Bugs that defeat an anti-fingerprinting measure in Whonix. Fingerprinting measures are best-effort and not guaranteed to be effective.
* The lack of a particular anti-fingerprinting measure in Whonix.

Some hypothetical vulnerability examples would include:

* "whonix-firewall misconfiguration allows Whonix-Workstation to reach clearnet by connecting to a service over port 7897"
* "onion-grater flaw allows a crafted Tor control command from the workstation to overwrite an arbitrary file as root despite AppArmor restrictions"

Some examples of issues that would not be considered vulnerabilities in Whonix include:

* "tirdad kernel module allows VM escape from Whonix-Workstation when running under VirtualBox 6.0.24"
** Not a vulnerability because an outdated version of VirtualBox is required to exploit the vulnerability.
* "Malware running in Whonix-Gateway can disable the firewall"
** Not a vulnerability because the malware must run in the gateway for this to succeed.
* "Whonix ships a vulnerable version of Tor that allows the workstation to acheive arbitrary code execution in the Tor daemon"
** This would indeed be a vulnerability, but would be already public by nature and thus should be reported publicly rather than privately.
* "Javascript running in Tor Browser can crash kloak, enabling biometric fingerprinting of the user"
** Not a vulnerability because this defeats an anti-fingerprinting measure.
* "Host CPU information is exposed to Whonix-Workstation and can be fingerprinted"
** Not a vulnerability because this would need a new anti-fingerprinting measure to mitigate.

Similar to Kicksecure, please err on the side of submitting a vulnerability report if in doubt.

== What to include in your vulnerability report ==
Vulnerability reports are a variant of bug reports in general. Therefore our [https://www.kicksecure.com/wiki/Reporting_Bugs#Reporting_Guidelines Bug Reporting Guidelines] apply. Note that it is especially important to provide working steps to reproduce the vulnerable behavior, as it can be difficult to determine whether an issue is a security issue without these instructions.

The following is a hypothetical example of a useful vulnerability report. Note that the "vulnerability" mentioned in this report is purely fabricated and has never been present in Kicksecure's source code.

<pre>
Subject: Invoking org.freedesktop.FileManager1.ShowFolders with crafted input
  may acheive arbitrary code execution in fm-shim-backend

Hi,

I believe I have discovered a security vulnerability in Kicksecure. Details are as follows:

Kicksecure version: Kicksecure 18.

Affected component: security-misc/usr/src/security-misc/fm-shim-backend.c#security-misc-shared

Steps to reproduce:

* Run `dbus-send --print-reply --session --dest=org.freedesktop.FileManager1 /org/freedesktop/FileManager1 org.freedesktop.FileManager1.ShowFolders array:string:file:/// string:$'\000\000\000\000lotsofuglyshellcodehere'`

Expected behavior: A window should appear asking if I want to open `/` in my file manager.

Actual behavior: fm-shim-backend crashes and the file `/home/user/pwned` is created.

`handle_filemanager_method_call()` in fm-shim-backend.c memcpy's the StartupId
argument to ShowFolders to a fixed-size buffer without checking if the argument
will fit. This buffer overflow allows one to run arbitrary code as the user
fm-shim-backend runs as via return-oriented programming.
</pre>

== Where and how to send your vulnerability report ==
Private vulnerability reports should be sent via email to Patrick Schleizer via email. See [[Contact]].

While not required, it is '''strongly recommended''' that you use OpenPGP encryption when sending the vulnerability report, and that you continue to use it for all communication related to the vulnerability until the vulnerability is made public. Using OpenPGP prevents a potentially malicious third party from gaining unauthorized access to the vulnerability details before the vulnerability is fixed. If you aren't sure how to use OpenPGP to secure your email, see the [https://www.kicksecure.com/wiki/OpenPGP#Links list of recommended OpenPGP-related links] for more information.

== How your report will be handled ==
The Kicksecure and Whonix projects cannot provide an SLA for response to vulnerability reports, or any bug reports in general. Issues will be responded to at the discretion of maintainers, subject to their available time. Any timelines specified in this section are best-effort goals only.

You should receive written confirmation that your report has been received within three days of submitting the report. Confirmation of receipt does not mean your report has been researched or read in its entirety yet, it simply means that your report reached us and will be handled. If you have not received confirmation of receipt after three days, please make a post on the appropriate forum stating:

* That you sent a vulnerability report, and
* The date and approximate time at which you sent it.
* Do NOT include further details about the report in your post.

Within seven days of receipt, we will likely have studied the report and will respond accordingly. Depending on the nature, severity, and clarity of the report, we may:

* Immediately fix the vulnerability, publish the fix as a software update, and inform you that it is now safe to publish your findings. For legitimate vulnerability reports, we expect this to be our usual response.
* Explain why the behavior you see is not a vulnerability in Kicksecure or Whonix, and suggest you publicize your findings.
* Request further clarification if some aspect of the vulnerability remains unclear.
* Request that the vulnerability remain under embargo until it has been fixed, or until 90 days has passed since the vulnerability report was received, whichever happens first. Note that, just as Kicksecure does not allow indefinite embargos for vulnerabilities we report to others, we also do not request indefinite embargos from those who report vulnerabilities to us.
* Request that the details of the vulnerability be published immediately even though the vulnerability report is legitimate. This will only be requested if end-users would be substantially helped from having access to the vulnerability details even without a fix, and only if the benefits of this are deemed to outweigh the costs.

Other responses are also possible when appropriate.

== Credit ==
The commit fixing the vulnerability you reported will credit you and/or parties who assisted you in your research and reporting efforts in the commit message. These commit messages will eventually be used as part of a Kicksecure release post on the forums [https://forums.kicksecure.com/t/kicksecure-18-2-1-9-point-release/1797 like this one]. You will be mentioned in the list of major changes when this happens. We are happy to omit names from commit messages and changelogs if you request us to do so.

It is unlikely that we will link to blog posts or other public communications detailing the vulnerability. This is not to discourage reporters from blogging about their discoveries once it is safe to publicize a vulnerability report, it is simply for the sake of efficiency.

== Bug Bounties ==
While we sincerely appreciate and encourage reports of suspected security problems in Kicksecure and Whonix, please note that neither ENCRYPTED SUPPORT LLC nor any of Kicksecure or Whonix's developers and sponsors run any bug bounty programs related to Kicksecure or Whonix.

== Responsible use of AI in vulnerability reports ==
In addition to this section, please see our [[Policy on Artificial Intelligence]].

To a limited extent, we are willing to tolerate vulnerability reports that are "chatbot brain dumps" (i.e. highly verbose, raw LLM output). This is only because we have not received a large volume of such reports yet and expect the quantity of them to be manageable. This may change if we become flooded with low-quality AI-generated reports.

Reporters are strongly recommended to be cautious about a number of points which tend to make AI-assisted vulnerability reports needlessly difficult to handle:

* Length: AI-generated reports tend to be excessively long, containing multiple sections and excessive detail. This makes it difficult to spot important information such as affected files and impact. Please ensure that a clear summary of the problem and all critical details are presented first. Do not require developers to scan multiple pages of text. Configure your tools to produce concise, human-style reports.
* Impact evaluation: Many AI-generated reports lack an understanding of our threat model as specified above, and may go to great lengths inventing theoretical consequences. This adds noise and complicates triage. Please stick to verifiable facts (e.g., "this bug permits the workstation to reach clearnet without going through Tor") without enumerating speculative implications. Have your tool read this documentation as part of the evaluation process.
* Reproducer: AI-based tools are often capable of generating reproducers. Please always ensure your tool provides one and '''test it thoroughly.''' If the reproducer does not work, or if the tool cannot produce one, the validity of the report should be seriously questioned.

== Attribution ==

Parts of this vulnerability handling policy have been inspired by and partially copied from [https://www.qemu.org/contribute/security-process/ the QEMU security process], [https://www.python.org/dev/security/ Python's security process], and [https://docs.kernel.org/process/security-bugs.html the Linux Kernel's security bug documentation].

== See Also ==

* Kicksecure's [[Vulnerability Disclosure Policy]]