OpenHarmony Security Bounty Program

Release date: September 23, 2023

Overview

The OpenHarmony community attaches great importance to the security of community software versions. The security issues include issues found during the routine security issue scans and internal security research, as well as security issues reported by users. The OpenHarmony Security Bounty Program (referred to as the "Program" hereinafter) aims to encourage feedback of security vulnerabilities found in OpenHarmony to bugbounty@mail.openharmony.io via emails encrypted by the PGP public key. The OpenHarmony Security Issue Response Team will try to address all feedback on a case-by-case basis as soon as possible.

Program Scope

The Program applies to the latest OpenHarmony Release version and OpenHarmony LTS versions for standard-, small-, and mini-system devices.

Security Vulnerability Scoring Criteria

In the OpenHarmony single-device scenario, vulnerabilities are classified into four levels: critical, high, medium, and low, based on their impact.

Bounty Program

The bonus amount varies depending on the severity level of the security vulnerability and the quality of the report. The OpenHarmony Security Response Team determines the final bonus based on the factors including but not limited to the following:

• Details in the vulnerability report. The report must comply with the Report Requirements in this Program and contain at least the description of the vulnerability and exploit methods, and attack code.

• Initial attack path, which can be remote (zero-click, one-click) or local.

• Whether the attack code is closely related to a specific device or software version, or whether the attack code can be executed on all devices or software versions.

• User perception of the attack process.

• Stability of the attack code.

• Whether the attack code can be executed in the latest stable LTS version.

• System type, security hardening solution, and mitigation measures.

NOTE

The Program does not apply to the vulnerabilities that bypass the screen lock using synthetic biometric data (including but are not limited to fingerprints and counterfeit masks).

Vulnerabilities Not Eligible for Reward

• Software functional errors that do not affect security.
• Exploits that reply on tricking users, such as phishing or clickjacking.
• Vulnerabilities that affect not only the OpenHarmony (including but not limited to protocols and third-party open-source software). You are advised to submit them to the corresponding channels. However, the vulnerabilities that have great impact on OpenHarmony can be treated as an exception.
• Vulnerabilities whose technical details (e.g. PoC) have been disclosed by means of websites, we-media, email groups, public speeches, and instant chat groups, before being reported to the OpenHarmony community.
• Vulnerabilities that are not reported for the first time. For a vulnerability repeatedly reported by one or more persons, only the first report is eligible for reward.
• Vulnerabilities which can be exploited and exert impact only under certain permissions, while an attacker can use the permissions to produce the same impact without exploiting the vulnerabilities.
• Vulnerabilities that can only be triggered locally, causing temporary DoS of the application.
• Other invalid vulnerabilities.

Report Requirements

The security vulnerability report should contain detailed description of the vulnerability and a complete PoC. It will be better if the report provides complete exploit or fix code.

Vulnerability Description

The vulnerability description should include:

• Detailed version information about the affected components.
• Description of the issue or symptom found in the component or module.
• Detailed explanation of the code logic in the component or module, which can be composed of decompiled code, disassembled code, or open-source code with necessary explanation.
• Complete procedure to reproduce the issue. If multiple steps are required or a specific environment must be used, describe the procedure in the environment after factory settings are restored.

PoC or Exploit

• The PoC or exploit contains complete and compilable code, including all source code, dependent libraries, and compilation files.
• The PoC or exploit contains how to build the compilation and running environment, including the standard compilation environment or a special environment, such as the special compilation or running environment and compilation options.
• The result of the PoC or exploit is consistent with that described in the report.
• If the PoC or exploit contains struct definitions, describe the structs and how to construct the structs and explain the composition and meaning of the field that triggers the security vulnerability.
• The PoC and exploit should not infringe any third-party intellectual property rights. For example, the PoC and exploit do not contain unauthorized intellectual material, such as icons, that is owned by a third party.
• The PoC and exploit do not contain religious taboos or content prohibited by law.

(Optional) Code to Fix or Mitigate the Vulnerability

The report contains the detailed solution to fix the vulnerability and the patch code that can be used.

Terminology

Forbidden Behaviors During Testing

• Do not access, download, modify, or delete data that does not belong to you without permission. Only PoC is allowed to prove the existence of the vulnerability.

• Phishing or social engineering attacks are prohibited.

• Do not use security vulnerabilities and related information for any illegal purpose. The following activities are prohibited:

  1. Access the computer information network or using resources in the computer information network without permission.

  2. Delete, modify, or add the functions of the computer information network without permission.

  3. Delete, modify, or add data or applications stored, processed, or transmitted in the computer information network without permission.

  4. Intentionally produce and spread destructive programs, such as computer viruses.

  5. Access the computer information network to obtain data stored in related website systems and platforms without permission.

  6. Other behaviors that jeopardize the security of the computer information network.

You shall be fully liable for any loss caused to the OpenHarmony community due to the above behaviors. If your behavior violates laws and regulations, you should bear the corresponding legal consequences.

Participant Restriction

Members of the OpenHarmony Security Issue Response Team and related project maintainers and committers cannot participate in this Program.

Statement

1. We hope that you do not disclose or spread security vulnerabilities before they are fixed. We promise that every issue you reported will be tracked, analyzed, handled, and replied to by dedicated personnel in a timely manner, and your contribution will be awarded according to the Bounty Program.

2. Security vulnerabilities should be tested in compliance with laws and regulations. The OpenHarmony community reserves the right to take legal actions against activities that violate laws, administrative regulations, management regulations of the OpenHarmony community, and website agreements, such as exploiting security vulnerabilities to ruin user interests, affecting service provisioning, stealing user data, and maliciously spreading security vulnerabilities or data.

Effectiveness and Modification

The Program takes effect as of the date of release. The OpenHarmony Security Issue Response Team may modify the Program as required. You will find the latest version on the OpenHarmony official website. Unless otherwise specified, the updated version takes effect as of the date of release.

If you have any comments or suggestions, please contact bugbounty@mail.openharmony.io.