Project

systemd is a suite of basic building blocks for a Linux system. It provides a system and service manager that runs as PID 1 and starts the rest of the system.

systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, maintains mount and automount points, and implements an elaborate transactional dependency-based service control logic. systemd works as a replacement for SysV init.

Other parts include a logging daemon, utilities to control basic system configuration like the hostname, date, locale, maintain a list of logged-in users, running containers and virtual machines, system accounts, runtime directories and settings, and daemons to manage simple network configuration, network time synchronization, log forwarding, and name resolution.

This bug bounty program is paid for by the Sovereign Tech Resilience program.

Scopes

You can find our repositories on Github

Program Rules

• We welcome external reviews by security researchers in order to identify bugs in our components.
• The scope of this program only applies to the software we build, not to our CI infrastructure or our git/website hosting, and any such attack is prohibited.
• Issues must be reproducible in our setup in order to be accepted as valid.
• We operate this bounty program on a "One Fix One Reward" basis. We consider an issue duplicated if it was previously reported through other channels, and also if it affects a common code module and it was already reported for a different component.
• The systemd project ships many tools and components, most of which are optional, and some of which are experimental. The scope of this program only applies to a select subset of such components, as defined later. This selection is subject to change in the future.
• The systemd project ships many optional features that require root or admin privileges to enable. While bugs in disabled-by-default features are still eligible for the bounty program, the criticality will be lowered due to reduced impact.
• All reports must be validated manually, submission from automated tools won't be considered and may lead to sanctions (code analysis tools, AI, …)

Precautions

• Do not include Personally Identifiable Information (PII) in your report and redact or obfuscate any PII that is part of your PoC (journald logs, screenshot, terminal captures, etc.).

About report's content

To be eligible, your reports must include the hereafter information :

General description of the issue

• Details about the impacted function and specific conditions to be met, including the vulnerable code snippet
• Impacted version
• A step by step proof of concept allowing to reliably reproduce the issue, including network exploitation
• A video of the PoC, demonstrating the full exploitation
• Recommendations and fix suggestions

A detailed template will be provided automatically when submitting a report, please stick to it. This will help us ensure a smooth and swift processing of your reports.

Mind that reports that do not follow the template’s guidelines won’t be eligible for reward. Abuse may lead to further sanctions (e.g. spamming or repeated submission of invalid reports).

All reports must include screenshots, video(s), logs and evidence, that show the full exploitation on your end. Providing us with a script to run ourselves will be deemed insufficient. Reports that fail to present required evidence, will likely be rejected.

Eligibility

Every valid report that helps us improve the security of the project is welcome, however, in order to qualify for monetary rewards the following eligibility requirements must be met at a minimum:

• Source of the issue must be in the code published and developed on https://github.com/systemd/systemd (as opposed to a different repository in the same org, or a distribution-specific patch).
• The vulnerability must be new and not have been reported before, here or elsewhere.
• The vulnerability must meet the qualifying criteria as defined in the relevant section.
• A reproducer (code and/or configuration and/or sequence of commands) must accompany the report, the issue must be clearly described, and the issue must be reproducible.
• You must not be a maintainer of the systemd project.
• Our analysis is always based on the worst impact demonstrated in your PoC
• Only reports affecting the main branch of the project are eligible.
• The report must contain the following elements:
  • Clear textual description of the vulnerability, how it can be exploited, the security impact it has on the application, its users and the company, and remediation advice on fixing the vulnerability
  • Proof of exploitation: screenshots demonstrating the exploit was performed, and showing the final impact
  • Provide complete steps with the necessary information to reproduce the exploit, including (if necessary) code snippets, payloads, commands etc

Rating and Responsible Disclosure

CVSS is used to rate and categorize vulnerabilities. Vulnerabilities will be publicly disclosed after sufficient time has passed and fixes have been backported where needed, if deemed necessary in coordination with mainstream Linux distributions.

Advisories will be published on the advisory page of our GitHub repository, and where deemed necessary as CVEs and on external mailing-lists like oss-security.

We handle the full disclosure process and expect submitters not to disclose any findings themselves. If requested, we will fully credit the reporters in the advisories.

The process for external reporting is described on GitHub