ClickHouse

Description

No technology is perfect and ClickHouse believes that working with skilled security researchers across the globe is crucial in identifying weaknesses in any technology. We are excited for you to participate as a security researcher to help us identify vulnerabilities in our open-source assets. Good luck, and happy hunting! Ratings/Rewards: For the initial prioritization/rating of findings, this program will use the Bugcrowd Vulnerability Rating Taxonomy . However, it is important to note that in some cases a vulnerability priority will be modified due to its likelihood or impact. In any instance where an issue is downgraded, a full, detailed explanation will be provided to the researcher - along with the opportunity to appeal, and make a case for a higher priority.

Targets

Testing is only authorized on the targets listed as in scope. Any domain/property of ClickHouse not listed in the targets section is out of scope. This includes any/all subdomains not listed here. If you happen to identify a security vulnerability on a target that is not in scope, but it demonstrably belongs to ClickHouse, you can report it here. However, be aware that it is ineligible for rewards or points-based compensation. Testing Setup and Reporting ClickHouse OSS target We recommend researchers to follow the quickstart guide to familiarize themselves with clickhouse-client and clickehouse-server . To test out specific feature flags & security flags, we recommend going through our documentation at https://clickhouse.com/docs/en/intro for more information. If finding a bug requires a special testing methodology or tools, we would appreciate it if these will be described in the report, so we can triage the issue quicker and improve our infrastructure. If the report covers mitigation guidelines or a fix, it is also appreciated. High Level Example of a Report: Lab setup: - ClickHouse server version - Release v22.6.1.1985-stable - ClickHouse client version - Release v22.6.1.1985-stable - Host: Ubuntu Server 20.04 - Platform: x86_64 Additional Setup: - The encryption_codecs inside /etc/clickhouse-server/config.yaml must use aes_128_gcm_siv key. - Created an user and granted access to select GRANT SELECT(x,y) ON db.table TO user1 WITH GRANT OPTION so user1 can query x and y columns and able to grant access to these columns to other users according to https://clickhouse.com/docs/en/sql-reference/statements/grant/ Exploitation: - Detail step 1 - Detail step 2 Outcome: - User1 was able to access other columns and bypass the restrictions placed on their account. Extra Details: - Crashlog of the application. - Proof of concept code/queries ran. - Methodology or tools used to identify the issue - Mitigation guidelines Focus Areas: Bypasses against Role Based Access Control management. Bypasses against any additional security controls implemented in ClickHouse (this may require specific setup with understanding of ClickHouse and various security configurations such as enabling mTLS, encryption). Various memory corruption and buffer overflow vulnerabilities. ClickHouse Cloud Platform target Security researchers can start testing by registering for a free account at https://clickhouse.com/ by using an @bugcrowdninja email address. Your account will come with $300 worth of testing credits. Do not use unlimited credit cards or throw away cards. This behavior will result in removal from the program. Focus Areas: IDOR Injection Stored XSS Server-side Request Forgery (SSRF) Sensitive data exposure Business logic flaws Remote Code Execution (RCE) SQL Injection (SQLi) Authentication related issues Authorization related issues Unauthorized API actions Clever vulnerabilities that bypass our security controls Excluded Submission Types Lack of rate limiting Clickjacking Missing security deaders EXIF geolocation data Missing or incorrect SPF/DKIM/DMARC records Software version disclosure POST-based reflected XSS / self XSS Social engineering and physical attacks Any customer hosted systems or services Safe Harbor: When conducting vulnerability research according to this policy, we consider this research to be: Authorized in accordance with the Computer Fraud and Abuse Act (CFAA) (and/or similar state laws), and we will not initiate or support legal action against you for accidental, good faith violations of this policy; Exempt from the Digital Millennium Copyright Act (DMCA), and we will not bring a claim against you for circumvention of technology controls; Exempt from restrictions in our Terms & Conditions that would interfere with conducting security research, and we waive those restrictions on a limited basis for work done under this policy; and Lawful, helpful to the overall security of the Internet, and conducted in good faith. You are expected, as always, to comply with all applicable laws. If during your testing you discover exposed internal credentials, achieve unauthorized access to internal systems, or identify a vulnerability that could lead to internal system compromise, immediately cease testing and report your findings. We will assess the full impact of your discovery and ensure you receive the maximum applicable reward based on the potential severity. Any attempts to further enumerate, perform lateral movement, or escalate access after discovering such vulnerabilities will be considered a violation of this program's rules resulting in forfeiture of all rewards and potential removal from the program. If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please inquire via [email protected] before going any further.

ClickHouse Cloud Platform target (in scope)

Target Information: ClickHouse Cloud is our SaaS platform which provides users with a managed ClickHouse service with seamless scaling and serverless operations. ClickHouse Cloud consists of several components. The Control Plane web application allows users to manage user access, start/stop instances, monitor usage information and configure advanced features such as IP Filtering, Advanced Scaling etc. The Data Plane and its components manage and store customers’ ClickHouse services and data. Documentation: https://clickhou.se/bugcrowddocs Special requirements and guidelines: ClickHouse is updated regularly. Keep an eye out on their Security Policy page https://github.com/ClickHouse/ClickHouse/security/policy in order to ensure you are testing on a supported version. Security researchers must ensure the registration email for their testing account is a bugcrowd email address ending with @bugcrowdninja.com. For more info regarding bugcrowdninja email addresses, see here . If you find a vulnerability that exposes customer or employee personal information, stop testing and report the issue immediately. If you find a vulnerability that allows you to gain shell access to our environment, stop testing and report the issue immediately. Do not purposefully attempt to degrade systems or services during testing. Only target your own account and do not attempt to access data from anyone else’s account that you do not explicitly own. Reporting requirements: Researchers must follow guidelines from Bugcrowd in reporting a security vulnerability and the report must describe the vulnerability in detail, where it was discovered, the steps to reproduce and, most importantly, the potential impact of exploitation.

ClickHouse OSS target (in scope)

Target Information: The source code is written in C++. ClickHouse is an open-source column-oriented DBMS (columnar database management system) for online analytical processing (OLAP), which allows users to generate analytical reports using SQL queries in real-time. The main focus of the public program is the open source version of the ClickHouse platform available at https://github.com/ClickHouse/ClickHouse. The repository contains source code for both the ClickHouse server and client(s) components. The ClickHouse software binaries can be downloaded from https://clickhouse.com/. Documentation: https://clickhouse.com/docs/en/intro Supported Versions: ClickHouse is updated regularly. Keep an eye out on our Security Policy page https://github.com/ClickHouse/ClickHouse/security/policy in order to ensure you are testing on a supported version. Reporting Requirements Researchers must follow guidelines from Bugcrowd in reporting a security vulnerability. Due to the nature of this specific target, the following are additional requirements to be qualified for a bug bounty: The report should contain a description of the error and step-by-step instructions for reproducing it. The issue should be reproducible in the latest official release and the latest build from master. Unmodified source code and binaries have to be used in reproducing scenarios. The issue should not be already published. If the issue is already found by another researcher, it is not qualified for bug bounty program. The issue should be reproducible on Linux, x86_64 platform and should not depend on the Linux kernel version, libc version and configuration of environment like DNS resolvers, SSL certificates, filesystem and block devices configuration, etc. It should not depend on hardware failures. The issue should be reproducible without installation of additional software on the machines with clickhouse-server. If the issue requires usage of features marked as experimental in the documentation or code or enabling experimental flags (settings, configurations), it is not qualified for the bug bounty program. The issue should be reproducible with release builds from ClickHouse CI infrastructure. Debug and sanitized builds, builds with another compiler or compiler options are not qualified. The issue should be related to the clickhouse-server component.

Langfuse Cloud Platform (in scope)

Target Information: Langfuse is an open source LLM engineering platform. Langfuse helps you ship AI Agents/Products from prototype to production and beyond. Once in production, it powers your continuous improvement loop using production data to make your agents and LLM applications even more powerful. Documentation: Source code: https://github.com/langfuse/langfuse https://langfuse.com/docs https://langfuse.com/security/responsible-disclosure Reporting Requirements Security researchers must ensure the registration email for their testing account is a bugcrowd email address ending with @bugcrowdninja.com. For more info regarding bugcrowdninja email addresses, see here. If you find a vulnerability that exposes customer or employee personal information, stop testing and report the issue immediately. If you find a vulnerability that allows you to gain shell access to our environment, stop testing and report the issue immediately. Do not purposefully attempt to degrade systems or services during testing. Only target your own account and do not attempt to access data from anyone else’s account that you do not explicitly own. Researchers must follow guidelines from Bugcrowd in reporting a security vulnerability. The report should contain a clear description of the vulnerability including its potential impact, steps to reproduce (including any specific configurations or conditions required), and any proof-of-concept code, scripts, or screenshots that demonstrate the vulnerability.

Out of Scope (out of scope)

Important : New support cases, Chat, Request new integration form and Share feedback form are no longer included in target scope as these actions can generate unnecessary noises for our support team. Postgres offering : The Postgres offering of ClickHouse allows users to interact with the underlying system by design given it's full tenant isolation. Do not report such findings unless there is a potential impact to escalate outside the tenant permission boundaries. Do not use vulnerability scanners on this program . The use of custom scripts and fuzzing tools on this program must be targeted, specific testing, and then only at less than five requests per second to reduce noise and minimize potential disruption for our customers. Results from a static code analysis tool with no manual verification or a proof of concept. A list of out-of-date dependencies - chances are we are aware of this and the team is making efforts to update them accordingly without introducing any breaking changes. If you think a particular vulnerability is severe and exploitable from the way it is implemented in the ClickHouse codebase, please provide a proof of concept. Theoretical security issues. Web vulnerabilities against the built-in “play” HTTP server with the default local setup and no real-world impact (e.g. clickjacking, CSRF, missing security headers, etc.) Third party websites or systems hosted by non-ClickHouse entities that ClickHouse staff use DoS / DDoS attacks that may cause disruption to our service Payment processing (handled by a third party) Social Engineering Internal information such as users or processes in the system.* tables that cannot be exploited or do not leak actionable sensitive information Missing rate limiting without demonstrating a concrete security impact Automated scanner output without manual verification or a working proof of concept Missing security headers (e.g., CSP, X-Frame-Options) without a demonstrated exploit, or missing Secure/HttpOnly flag on non-sensitive cookies Testing that would result in sending spam or other unsolicited messages to users Testing is only authorized on the targets listed as in scope. Any domain/property of ClickHouse not listed in the targets section is out of scope. This includes any/all subdomains not listed above. If you happen to identify a security vulnerability on a target that is not in scope, but it demonstrably belongs to ClickHouse, you can report it here. However, be aware that it is ineligible for rewards or points-based compensation.