Google Vulnerability Reward Program (VRP)

    The goal of the VRP is to provide a formal process to honor contributions from external security researchers to Envoy’s security. Vulnerabilities should meet the following conditions to be eligible for the program:

    1. Vulnerabilities must meet one of the below objectives, demonstrated with the supplied Docker-based and be consistent with the program’s threat model.

    2. Vulnerabilities must be reported to and be kept under embargo while triage and potential security releases occur. Please follow the disclosure guidance when submitting reports. Disclosure SLOs are documented . In general, security disclosures are subject to the Linux Foundation’s privacy policy with the added proviso that VRP reports (including reporter e-mail address and name) may be freely shared with Google for VRP purposes.

    3. Vulnerabilities must not be previously known in a public forum, e.g. GitHub issues trackers, CVE databases (when previously associated with Envoy), etc. Existing CVEs that have not been previously associated with an Envoy vulnerability are fair game.

    4. Vulnerabilities must not be also submitted to a parallel reward program run by Google or .

    Rewards are at the discretion of the Envoy OSS security team and Google. They will be conditioned on the above criteria. If multiple instances of the same vulnerability are reported at the same time by independent researchers or the vulnerability is already tracked under embargo by the OSS Envoy security team, we will aim to fairly divide the reward amongst reporters.

    Threat model

    The base threat model matches that of Envoy’s . We add a number of temporary restrictions to provide a constrained attack surface for the initial stages of this program. We exclude any threat from:

    • Runtime services such as access logging, external authorization, etc.

    • Untrusted upstreams.

    • DoS attacks except as stipulated below.

    • Any filters apart from the HTTP connection manager network filter and HTTP router filter.

    • Admin console; this is disabled in the execution environment.

    In the future we may relax some of these restrictions as we increase the sophistication of the program’s execution environment.

    We supply Docker images that act as the reference environment for this program:

    • envoyproxy/envoy-google-vrp images are based on Envoy point releases. Only the latest point release at the time of vulnerability submission is eligible for the program. The first point release available for VRP will be the 1.15.0 Envoy release.

    • images are based on Envoy main builds. Only builds within the last 5 days at the time of vulnerability submission are eligible for the program. They must not be subject to any publicly disclosed vulnerability at that point in time.

    Two Envoy processes are available when these images are launched via :

    • The edge Envoy is listening on ports 10000 (HTTPS). It has a static configuration that is configured according to Envoy’s . It has sinkhole, direct response and request forwarding routing rules (in order):

      1. /content/*: route to the origin Envoy server.

      2. /*: return 403 (denied).

    When running the Docker images, the following command line options should be supplied:

    • -m 3g to ensure that memory is bounded to 3GB. At least this much memory should be available to the execution environment. Each Envoy process has an overload manager configured to limit at 1GB.

    • -e ENVOY_ORIGIN_EXTRA_ARGS="<...>" supplies additional CLI args for the origin Envoy. This needs to be set but can be empty.

    Objectives

    Vulnerabilities will be evidenced by requests on 10000 that trigger a failure mode that falls into one of these categories:

    • Query-of-death: requests that cause the Envoy process to segfault or abort in some immediate way.

    • OOM: requests that cause the edge Envoy process to OOM. There should be no more than 100 connections and streams in total involved to cause this to happen (i.e. brute force connection/stream DoS is excluded).

    • Routing rule bypass: requests that are able to access .

    • TLS certificate exfiltration: requests that are able to obtain the edge Envoy’s serverkey.pem.

    • Remote code exploits: any root shell obtained via the network data plane.

    A basic invocation of the execution environment that will bring up the edge Envoy on local port 10000 looks like:

    When debugging, additional args may prove useful, e.g. in order to obtain trace logs, make use of wireshark and gdb:

    You can obtain a shell in the Docker container with:

    The Docker images include gdb, , tshark (feel free to contribute other suggestions via PRs updating the ).

    Rebuilding the Docker image

    It’s helpful to be able to regenerate your own Docker base image for research purposes. To do this without relying on CI, follow the instructions at the top of . An example of this flow looks like: