CVE-2022-21679 in Istio
Summary
by MITRE • 01/20/2022
Istio is an open platform to connect, manage, and secure microservices. In Istio 1.12.0 and 1.12.1 The authorization policy with hosts and notHosts might be accidentally bypassed for ALLOW action or rejected unexpectedly for DENY action during the upgrade from 1.11 to 1.12.0/1.12.1. Istio 1.12 supports the hosts and notHosts fields in authorization policy with a new Envoy API shipped with the 1.12 data plane. A bug in the 1.12.0 and 1.12.1 incorrectly uses the new Envoy API with the 1.11 data plane. This will cause the hosts and notHosts fields to be always matched regardless of the actual value of the host header when mixing 1.12.0/1.12.1 control plane and 1.11 data plane. Users are advised to upgrade or to not mix the 1.12.0/1.12.1 control plane with 1.11 data plane if using hosts or notHosts field in authorization policy.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 01/26/2022
This vulnerability affects Istio service mesh deployments where version 1.12.0 or 1.12.1 control planes are mixed with 1.11 data planes, creating a critical authorization bypass scenario. The issue stems from a regression in the authorization policy implementation where the hosts and notHosts fields in authorization policies fail to properly evaluate host header values during the upgrade process. When Istio 1.12.0/1.12.1 control plane attempts to utilize the new Envoy API features designed for the 1.12 data plane while communicating with 1.11 data plane components, the system incorrectly processes these fields leading to improper access control decisions. The vulnerability manifests as a security bypass where ALLOW actions may be incorrectly granted regardless of host header values, or DENY actions may be unexpectedly rejected, effectively undermining the intended authorization policies.
The technical flaw represents a mismatch between control plane and data plane versions that results in improper API usage patterns. Specifically, the 1.12.0/1.12.1 control plane attempts to leverage new Envoy API functionality that was designed for the 1.12 data plane, but when this control plane communicates with the 1.11 data plane, the underlying implementation fails to properly translate or handle the hosts and notHosts field evaluations. This creates a scenario where the authorization decision logic becomes effectively disabled or misapplied, causing all host header values to be treated as matching regardless of their actual content. The vulnerability is particularly concerning because it affects the fundamental security controls that govern access to microservices within the Istio mesh, potentially allowing unauthorized access to services that should be restricted based on host header values.
The operational impact of this vulnerability extends beyond simple access control bypasses to potentially expose sensitive microservices to unauthorized access or create false security postures where administrators believe their authorization policies are properly enforced. Organizations running mixed-version Istio deployments may experience unexpected behavior where legitimate security controls are circumvented, leading to potential data breaches or unauthorized service access. The issue is particularly problematic during upgrade scenarios where administrators might be using a hybrid approach with some components on 1.12 and others on 1.11, as this creates an environment where the authorization policies become unreliable and unpredictable. This vulnerability directly impacts the integrity of the service mesh security model and can result in unauthorized access to critical microservices within the mesh architecture.
Security mitigations for this vulnerability require immediate action to ensure version consistency between control plane and data plane components. Organizations should upgrade all Istio components to the same version to eliminate the mixed-version scenario that triggers this bug. The recommended approach involves either upgrading the entire Istio deployment to version 1.12.0 or later, or ensuring that all data plane components are upgraded to 1.12.0 or later to match the control plane functionality. Additionally, administrators should review their authorization policies that utilize hosts and notHosts fields and implement alternative security controls or validation mechanisms while the upgrade process is underway. This vulnerability aligns with CWE-284 Access Control Bypass and ATT&CK technique T1078 Valid Accounts, as it allows unauthorized access to services that should be protected by authorization policies. Organizations should also implement monitoring and alerting for unexpected authorization decisions or access patterns that might indicate this vulnerability is active in their environment.
This vulnerability highlights the importance of proper version management and testing during service mesh upgrades, particularly in complex environments where multiple components may be at different versions. The issue demonstrates how seemingly minor API changes in control plane components can have significant security implications when mixed with older data plane implementations. Organizations should implement comprehensive testing procedures that validate authorization policies across mixed-version scenarios before deploying upgrades in production environments. The vulnerability serves as a reminder that service mesh security controls are only as strong as the weakest component in the deployment, and that version consistency is critical for maintaining the intended security posture. Regular security assessments and proper change management processes should be implemented to prevent similar issues from arising during future upgrades or deployments.