Impact

Escalation of Privileges when failure_mode_allow: true is configured for ext_authz filter. For affected components that are used for logging and/or visibility, requests may not be logged by the receiving service.

Affected components

ext_authz, ext_proc, tap, ratelimit filters and gRPC access log service.

Attack vector/s

The attacker can use this vulnerability to bypass auth checks when ext_authz is used.

Description

When Envoy was configured to use ext_authz, ext_proc, tap, ratelimit filters, and grpc access log service and an http header with non-UTF-8 data was received, Envoy would generate an invalid protobuf message and send it to the configured service. The receiving service would typically generate an error when decoding the protobuf message.

For ext_authz that was configured with failure_mode_allow: true, the request would have been allowed in this case.

For the other services, this could have resulted in other unforseen errors such as a lack of visibility into requests (eg request not logged).

Envoy will now by default sanitize the values sent in gRPC service calls to be valid UTF-8, replacing data that is not valid UTF-8 with a ! character.
This behavioral change can be temporarily reverted by setting runtime guard envoy.reloadable_features.service_sanitize_non_utf8_strings to false.

Example exploit or proof-of-concept

Sending a request with non-UTF-8 header values will reproduce this issue when an gRPC upstream is configured.

Mitigation

Setting failure_mode_allow: false for ext_authz.

Discoverer/credits

Marek Szlagor [email protected]