From 74df6d070aa400e52f0eac5ad5e3a2c642228110 Mon Sep 17 00:00:00 2001 From: Eric Van Norman Date: Thu, 13 May 2021 09:44:16 -0500 Subject: [PATCH] Cherry-pick changes from 1.9 security releases to master (#9735) --- .spelling | 5 + content/en/blog/2021/patch-tuesdays/index.md | 75 +++++++ .../docs/ops/best-practices/security/index.md | 192 ++++++++++++++++++ .../docs/releases/supported-releases/index.md | 7 +- .../releases/1.8.x/announcing-1.8.6/index.md | 48 +++++ .../releases/1.9.x/announcing-1.9.5/index.md | 32 +++ .../security/istio-security-2021-005/index.md | 86 ++++++++ .../security/istio-security-2021-006/index.md | 43 ++++ 8 files changed, 484 insertions(+), 4 deletions(-) create mode 100644 content/en/blog/2021/patch-tuesdays/index.md create mode 100644 content/en/news/releases/1.8.x/announcing-1.8.6/index.md create mode 100644 content/en/news/releases/1.9.x/announcing-1.9.5/index.md create mode 100644 content/en/news/security/istio-security-2021-005/index.md create mode 100644 content/en/news/security/istio-security-2021-006/index.md diff --git a/.spelling b/.spelling index 6b6c265609..01e5ec7474 100644 --- a/.spelling +++ b/.spelling @@ -229,6 +229,9 @@ CVE-2021-21378 CVE-2021-28682 CVE-2021-28683 CVE-2021-29258 +CVE-2021-31920 +CVE-2021-29492 +CVE-2021-31921 CVEs cves cvss @@ -397,6 +400,8 @@ ISTIO-SECURITY-2020-003 ISTIO-SECURITY-2020-004 ISTIO-SECURITY-2020-005 ISTIO-SECURITY-2020-006 +ISTIO-SECURITY-2021-005 +ISTIO-SECURITY-2021-006 istio-system istio.io istio.io. diff --git a/content/en/blog/2021/patch-tuesdays/index.md b/content/en/blog/2021/patch-tuesdays/index.md new file mode 100644 index 0000000000..c725a06875 --- /dev/null +++ b/content/en/blog/2021/patch-tuesdays/index.md @@ -0,0 +1,75 @@ +--- +title: "Updates to how Istio security releases are handled: Patch Tuesday, embargoes, and 0-days" +description: The Product Security working group announces Patch Tuesdays, how 0-days and embargoes are handled, updates to the security best practices page and the notification of the early disclosure list. +publishdate: 2021-05-11 +attribution: "Jacob Delgado (Aspen Mesh)" +keywords: [cve,product security] +--- + +While most of the work in the Istio Product Security Working Group is done behind the scenes, we are listening +to the community in setting expectations for security releases. We understand that it is difficult for mesh +administrators, operators and vendors to be aware of security bulletins and security releases. + +We currently disclose vulnerabilities and security releases via numerous channels: + +* [istio.io](https://istio.io) via our [Release Announcements](/news/releases/) and [Security Bulletins](/news/security/) +* [Discuss](https://discuss.istio.io/c/announcements/5) +* announcements channel on [Slack](https://istio.slack.com) +* [Twitter](https://twitter.com/IstioMesh) +* [RSS](/news/feed.xml) + +When operating any software, it is preferable to plan for possible downtime when upgrading. Given the work that the Istio +community is doing around Day 2 operations in 2021, the Environments working group has done a good job to streamline many +upgrade issues users have seen. The Product Security Working Group intends to help Day 2 operations by having routine +security release days so that upgrade operations can be planned in advance for our users. + +## Patch Tuesdays + +The Product Security working group is intending to ship a security release the 2nd Tuesday of each month. These security +releases may contain fixes for multiple CVEs. It is the intent of the Product Security working group to have these +security releases not contain any other fixes, although that may not always be possible. + +### First Patch Tuesday + +We are pleased to announce that [Istio 1.9.5](/news/releases/1.9.x/announcing-1.9.5/), and the final release of Istio 1.8, +[1.8.6](/news/releases/1.8.x/announcing-1.8.6/), are the first security releases to fit this pattern. As Istio 1.10 will +be shipping soon we are intending to continue this new tradition in June. + +These releases fix 3 CVEs. Please see the release pages for information regarding the specific CVEs fixed. + +## Unscheduled security releases + +### 0-day vulnerabilities + +Unfortunately, 0-day vulnerabilities cannot be planned. Upon disclosure, the Product Security Working Group will +need to issue an out-of-band security release. The above methods will be used to disclose such issues, so please use +at least one of them to be notified of such disclosures. + +### Third party embargoes + +Similar to 0-day vulnerabilities, security releases can be dictated by third party embargoes, namely Envoy. +When this occurs, Istio will release a same-day patch once the embargo is lifted. + +## Security Best Practices + +The [Istio Security Best Practices](/docs/ops/best-practices/security/) has seen many improvements over the past few +months. We recommend you check it regularly, as many of our recent security bulletins can be mitigated by utilizing +methods discussed in the Security Best Practices page. + +## Early Disclosure List + +If you meet [the criteria](https://github.com/istio/community/blob/master/EARLY-DISCLOSURE.md#membership-criteria) to be +a part of the [Istio Early Disclosure](https://github.com/istio/community/blob/master/EARLY-DISCLOSURE.md) list, please +apply for membership. Patches for upcoming security releases will be made available to the early disclosure list ~2 weeks +prior to Istio's Patch Tuesday. + +There will be times when an upcoming Istio security release will also need patches from Envoy. We cannot redistribute +Envoy patches due to their embargo. [Please refer to Envoy's guidance](https://github.com/envoyproxy/envoy/security/policy) +on how to join their early disclosure list. + +## Security Feedback + +The Product Security Working Group holds bi-weekly meetings on Tuesdays from 9:00-9:30 Pacific. For more information see +the [Istio Working Group Calendar](https://calendar.google.com/calendar/embed?src=4uhe8fi8sf1e3tvmvh6vrq2dog%40group.calendar.google.com&ctz=America%2FLos_Angeles). + +Our next public meeting will be held on May 25, 2021. Please join us! diff --git a/content/en/docs/ops/best-practices/security/index.md b/content/en/docs/ops/best-practices/security/index.md index 97db57dea2..71c740c345 100644 --- a/content/en/docs/ops/best-practices/security/index.md +++ b/content/en/docs/ops/best-practices/security/index.md @@ -24,6 +24,131 @@ This means that anyone with a valid certificate can still access a service. To fully lock down traffic, it is recommended to configure [authorization policies](/docs/tasks/security/authorization/). These allow creating fine-grained policies to allow or deny traffic. For example, you can allow only requests from the `app` namespace to access the `hello-world` service. +## Authorization policies + +Istio [authorization](/docs/concepts/security/#authorization) plays a critical part in Istio security. +It takes effort to configure the correct authorization policies to best protect your clusters. +It is important to understand the implications of these configurations as Istio cannot determine the proper authorization for all users. +Please follow this section in its entirety. + +### Apply default-deny authorization policies + +We recommend you define your Istio authorization policies following the default-deny pattern to enhance your cluster's security posture. +The default-deny authorization pattern means your system denies all requests by default, and you define the conditions in which the requests are allowed. +In case you miss some conditions, traffic will be unexpectedly denied, instead of traffic being unexpectedly allowed. +The latter typically being a security incident while the former may result in a poor user experience, a service outage or will not match your SLO/SLA. + +For example, in the [authorization for HTTP traffic task](/docs/tasks/security/authorization/authz-http/), +the authorization policy named `allow-nothing` makes sure all traffic is denied by default. +From there, other authorization policies allow traffic based on specific conditions. + +### Customize your system on path normalization + +Istio authorization policies can be based on the URL paths in the HTTP request. +[Path normalization (a.k.a., URI normalization)](https://en.wikipedia.org/wiki/URI_normalization) modifies and standardizes the incoming requests' paths, +so that the normalized paths can be processed in a standard way. +Syntactically different paths may be equivalent after path normalization. + +Istio supports the following normalization schemes on the request paths, +before evaluating against the authorization policies and routing the requests: + +| Option | Description | Example | +| --- | --- | --- | +| `NONE` | No normalization is done. Anything received by Envoy will be forwarded exactly as-is to any backend service. | `../%2Fa../b` is evaluated by the authorization policies and sent to your service. | +| `BASE` | This is currently the option used in the *default* installation of Istio. This applies the [`normalize_path`](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto#envoy-v3-api-field-extensions-filters-network-http-connection-manager-v3-httpconnectionmanager-normalize-path) option on Envoy proxies, which follows [RFC 3986](https://tools.ietf.org/html/rfc3986) with extra normalization to convert backslashes to forward slashes. | `/a/../b` is normalized to `/b`. `\da` is normalized to `/da`. | +| `MERGE_SLASHES` | Slashes are merged after the _BASE_ normalization. | `/a//b` is normalized to `/a/b`. | +| `DECODE_AND_MERGE_SLASHES` | The most strict setting when you allow all traffic by default. This setting is recommended, with the caveat that you will need to thoroughly test your authorization policies routes. [Percent-encoded](https://tools.ietf.org/html/rfc3986#section-2.1) slash and backslash characters (`%2F`, `%2f`, `%5C` and `%5c`) are decoded to `/` or `\`, before the `MERGE_SLASHES` normalization. | `/a%2fb` is normalized to `/a/b`. | + +To emphasize, the normalization algorithms are conducted in the following order: + +1. Percent-decode `%2F`, `%2f`, `%5C` and `%5c`. +1. The [RFC 3986](https://tools.ietf.org/html/rfc3986) and other normalization implemented by the [`normalize_path`](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto#envoy-v3-api-field-extensions-filters-network-http-connection-manager-v3-httpconnectionmanager-normalize-path) option in Envoy. +1. Merge slashes + +{{< warning >}} +While these normalization options represent recommendations from HTTP standards and common industry practices, +applications may interpret a URL in any way it chooses to. When using denial policies, ensure that you understand how your application behaves. +{{< /warning >}} + +### Examples of configuration + +Ensuring Envoy normalizes request paths to match your backend services' expectation is critical to the security of your system. +The following examples can be used as reference for you to configure your system. +The normalized URL paths, or the original URL paths if _NONE_ is selected, will be: + +1. Used to check against the authorization policies +1. Forwarded to the backend application + +| Your application... | Choose... | +| --- | --- | +| Relies on the proxy to do normalization | `BASE`, `MERGE_SLASHES` or `DECODE_AND_MERGE_SLASHES` | +| Normalizes request paths based on [RFC 3986](https://tools.ietf.org/html/rfc3986) and does not merge slashes | `BASE` | +| Normalizes request paths based on [RFC 3986](https://tools.ietf.org/html/rfc3986), merges slashes but does not decode [percent-encoded](https://tools.ietf.org/html/rfc3986#section-2.1) slashes | `MERGE_SLASHES` | +| Normalizes request paths based on [RFC 3986](https://tools.ietf.org/html/rfc3986), decodes [percent-encoded](https://tools.ietf.org/html/rfc3986#section-2.1) slashes and merges slashes | `DECODE_AND_MERGE_SLASHES` | +| Processes request paths in a way that is incompatible with [RFC 3986](https://tools.ietf.org/html/rfc3986) | `NONE` | + +#### How to configure + +You specify the normalization by directly editing the [mesh config](/docs/reference/config/istio.mesh.v1alpha1/). +You need to manually edit the mesh config to specify this option: + + {{< text bash >}} + $ istioctl upgrade --set meshConfig.pathNormalization.normalization=DECODE_AND_MERGE_SLASHES + {{< /text >}} + +or by altering your operator overrides file + + {{< text bash >}} + $ cat < iop.yaml + apiVersion: install.istio.io/v1alpha1 + kind: IstioOperator + spec: + meshConfig: + pathNormalization: + normalization: DECODE_AND_MERGE_SLASHES + EOF + $ istioctl install -f iop.yaml + {{< /text >}} + +### Less common normalization configurations + +#### Case Normalization + +In some environments, it may be useful to have paths in authorization policies compared in a case insensitive manner. +For example, treating `https://myurl/get` and `https://myurl/GeT` as equivalent. +In those cases, the `EnvoyFilter` shown below can be used. +This filter will change both the path used for comparison and the path presented to the application. + + {{< text syntax=yaml snip_id=ingress_case_insensitive_envoy_filter >}} + apiVersion: networking.istio.io/v1alpha3 + kind: EnvoyFilter + metadata: + name: ingress-case-insensitive + namespace: istio-system + spec: + configPatches: + - applyTo: HTTP_FILTER + match: + context: GATEWAY + listener: + filterChain: + filter: + name: "envoy.filters.network.http_connection_manager" + subFilter: + name: "envoy.filters.http.router" + patch: + operation: INSERT_BEFORE + value: + name: envoy.lua + typed_config: + "@type": "type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua" + inlineCode: | + function envoy_on_request(request_handle) + local path = request_handle:headers():get(":path") + request_handle:headers():replace(":path", string.lower(path)) + end + {{< /text >}} + ## Understand traffic capture limitations The Istio sidecar works by capturing both inbound traffic and outbound traffic and directing them through the sidecar proxy. @@ -132,6 +257,73 @@ It may be desired to enforce stricter physical isolation for sensitive services. shared gateway instance for less sensitive domains like `blog.example.com` and `store.example.com`. This can offer a stronger defense-in-depth and help meet certain regulatory compliance guidelines. +### Explicitly disable all the sensitive http host under relaxed SNI host matching + +It is reasonable to use multiple `Gateway`s to define mutual TLS and simple TLS on different hosts. +For example, use mutual TLS for SNI host `admin.example.com` and simple TLS for SNI host `*.example.com`. + +{{< text yaml >}} +kind: Gateway +metadata: + name: guestgateway +spec: + selector: + istio: ingressgateway + servers: + - port: + number: 443 + name: https + protocol: HTTPS + hosts: + - "*.example.com" + tls: + mode: SIMPLE +--- +kind: Gateway +metadata: + name: admingateway +spec: + selector: + istio: ingressgateway + servers: + - port: + number: 443 + name: https + protocol: HTTPS + hosts: + - admin.example.com + tls: + mode: MUTUAL +{{< /text >}} + +If the above is necessary, it's highly recommended to explicitly disable the http host `admin.example.com` in the `VirtualService` that attaches to `*.example.com`. The reason is that currently the underlying [envoy proxy does not require](https://github.com/envoyproxy/envoy/issues/6767) the http 1 header `Host` or the http 2 pseudo header `:authority` following the SNI constraints, an attacker can reuse the guest-SNI TLS connection to access admin `VirtualService`. The http response code 421 is designed for this `Host` SNI mismatch and can be used to fulfill the disable. + +{{< text yaml >}} +apiVersion: networking.istio.io/v1alpha3 +kind: VirtualService +metadata: + name: disable-sensitive +spec: + hosts: + - "admin.example.com" + gateways: + - guestgateway + http: + - match: + - uri: + prefix: / + fault: + abort: + percentage: + value: 100 + httpStatus: 421 + route: + - destination: + port: + number: 8000 + host: dest.default.cluster.local +{{< /text >}} + ## Protocol detection Istio will [automatically determine the protocol](/docs/ops/configuration/traffic-management/protocol-selection/#automatic-protocol-selection) of traffic it sees. diff --git a/content/en/docs/releases/supported-releases/index.md b/content/en/docs/releases/supported-releases/index.md index 1df62cb47a..021b90fd98 100644 --- a/content/en/docs/releases/supported-releases/index.md +++ b/content/en/docs/releases/supported-releases/index.md @@ -62,7 +62,7 @@ current `` release. A patch is usually a small change relative to the `}} Istio does not guarantee that minor releases that fall outside the support window have all known CVEs patched. @@ -71,6 +71,5 @@ Please keep up-to-date and use a supported version. | Minor Releases | Patched versions with no known CVEs | |----------------------------|--------------------------------------| -| 1.9.x | 1.9.3+ | -| 1.8.x | 1.8.5+ | -| 1.7 and earlier | None | +| 1.9.x | 1.9.5+ | +| 1.8 and earlier | None | diff --git a/content/en/news/releases/1.8.x/announcing-1.8.6/index.md b/content/en/news/releases/1.8.x/announcing-1.8.6/index.md new file mode 100644 index 0000000000..34627e8677 --- /dev/null +++ b/content/en/news/releases/1.8.x/announcing-1.8.6/index.md @@ -0,0 +1,48 @@ +--- +title: Announcing Istio 1.8.6 +linktitle: 1.8.6 +subtitle: Patch Release +description: Istio 1.8.6 patch release. +publishdate: 2021-05-11 +release: 1.8.6 +aliases: + - /news/announcing-1.8.6 +--- + +This release fixes the security vulnerabilities described in our May 11th posts, [ISTIO-SECURITY-2021-005](/news/security/istio-security-2021-005) and [ISTIO-SECURITY-2021-006](/news/security/istio-security-2021-006). + +{{< relnote >}} + +{{< tip >}} +This is the final release of 1.8. Please upgrade your Istio installation to a supported version. +{{< /tip >}} + +## Security update + +The following 2 CVEs are highly related. + +- __[CVE-2021-31920](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31920)__: +Istio contains a remotely exploitable vulnerability where an HTTP request path with multiple slashes or escaped slash characters (`%2F` or `%5C`) could potentially bypass an Istio authorization policy when path based authorization rules are used. See the [ISTIO-SECURITY-2021-005 bulletin](/news/security/istio-security-2021-005) for more details. + - __CVSS Score__: 8.1 [AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) +- __[CVE-2021-29492](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-29492)__: + Envoy contains a remotely exploitable vulnerability where an HTTP request with escaped slash characters can bypass Envoy's authorization mechanisms. + - __CVSS Score__: 8.3 +- __[CVE-2021-31921](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31921)__: + Istio contains a remotely exploitable vulnerability where an external client can access unexpected services in the cluster, bypassing authorization checks, when a gateway is configured with `AUTO_PASSTHROUGH` routing configuration. See the [ISTIO-SECURITY-2021-006 bulletin](/news/security/istio-security-2021-006) for more details. + - __CVSS Score__: 10.0 [AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) + +## Changes + +**Added** [security best practice for authorization policies](/docs/ops/best-practices/security/#authorization-policies) + +**Fixed** istiod so it will no longer generate listeners for privileged gateway ports (<1024) if the gateway Pod does not have sufficient permissions. [Issue 27566](https://github.com/istio/istio/issues/27566) + +**Fixed** an issue where transport socket parameters are now taken into account when configured in `EnvoyFilter`. [Issue 28996](https://github.com/istio/istio/issues/28996) + +**Fixed** `PeerAuthentication` to not turn off mTLS while using multi-network, non-mTLS endpoints from the cross-network load-balancing endpoints to prevent 500 errors. [Issue 28798](https://github.com/istio/istio/issues/28798) + +**Fixed** a bug causing runaway logs in istiod after disabling the default ingress controller. [Issue 31336](https://github.com/istio/istio/issues/31336) + +**Fixed** the Kubernetes API server so it is now considered to be cluster-local by default . This means that any pod attempting to reach `kubernetes.default.svc` will always be directed to the in-cluster server. [Issue 31340](https://github.com/istio/istio/issues/31340) + +**Fixed** Istio operator to prune resources that do not belong to the specific Istio operator CR. [Issue 30833](https://github.com/istio/istio/issues/30833) diff --git a/content/en/news/releases/1.9.x/announcing-1.9.5/index.md b/content/en/news/releases/1.9.x/announcing-1.9.5/index.md new file mode 100644 index 0000000000..813bd190c1 --- /dev/null +++ b/content/en/news/releases/1.9.x/announcing-1.9.5/index.md @@ -0,0 +1,32 @@ +--- +title: Announcing Istio 1.9.5 +linktitle: 1.9.5 +subtitle: Patch Release +description: Istio 1.9.5 patch release. +publishdate: 2021-05-11 +release: 1.9.5 +aliases: + - /news/announcing-1.9.5 +--- + +This release fixes the security vulnerabilities described in our May 11th posts, [ISTIO-SECURITY-2021-005](/news/security/istio-security-2021-005) and [ISTIO-SECURITY-2021-006](/news/security/istio-security-2021-006). + +{{< relnote >}} + +## Security update + +The following 2 CVEs are highly related. + +- __[CVE-2021-31920](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31920)__: +Istio contains a remotely exploitable vulnerability where an HTTP request path with multiple slashes or escaped slash characters (`%2F` or `%5C`) could potentially bypass an Istio authorization policy when path based authorization rules are used. See the [ISTIO-SECURITY-2021-005 bulletin](/news/security/istio-security-2021-005) for more details. + - __CVSS Score__: 8.1 [AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) +- __[CVE-2021-29492](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-29492)__: +Envoy contains a remotely exploitable vulnerability where an HTTP request with escaped slash characters can bypass Envoy's authorization mechanisms. + - __CVSS Score__: 8.3 +- __[CVE-2021-31921](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31921)__: +Istio contains a remotely exploitable vulnerability where an external client can access unexpected services in the cluster, bypassing authorization checks, when a gateway is configured with `AUTO_PASSTHROUGH` routing configuration. See the [ISTIO-SECURITY-2021-006 bulletin](/news/security/istio-security-2021-006) for more details. + - __CVSS Score__: 10.0 [AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) + +## Changes + +**Added** [security best practice for authorization policies](/docs/ops/best-practices/security/#authorization-policies) diff --git a/content/en/news/security/istio-security-2021-005/index.md b/content/en/news/security/istio-security-2021-005/index.md new file mode 100644 index 0000000000..4c93986174 --- /dev/null +++ b/content/en/news/security/istio-security-2021-005/index.md @@ -0,0 +1,86 @@ +--- +title: ISTIO-SECURITY-2021-005 +subtitle: Security Bulletin +description: +cves: [CVE-2021-31920] +cvss: "8.1" +vector: "AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N" +releases: ["All releases prior to 1.8.6", "1.9.0 to 1.9.4"] +publishdate: 2021-05-11 +keywords: [CVE] +skip_seealso: true +--- + +{{< security_bulletin >}} + +## Issue + +Istio contains a remotely exploitable vulnerability where an HTTP request path with multiple slashes or escaped slash characters (`%2F` or `%5C`) +could potentially bypass an Istio authorization policy when path based authorization rules are used. Related Envoy CVE: +[`CVE-2021-29492`](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-29492). + +For example, assume an Istio cluster administrator defines an authorization DENY policy to reject the request at path `/admin`. +A request sent to the URL path `//admin` will NOT be rejected by the authorization policy. + +According to the [RFC 3986](https://tools.ietf.org/html/rfc3986#section-6), +the path `//admin` with multiple slashes should technically be treated as a different path from the `/admin`. +However, some backend services choose to normalize the URL paths by merging multiple slashes to a single slash. +This can result in a bypass of the authorization policy (`//admin` does not match `/admin`) and a user can access the resource at path `/admin` +in the backend; this would represent a security incident. + +## Am I impacted? + +Your cluster is **impacted** by this vulnerability if you have authorization policies using `ALLOW action + notPaths field` +or `DENY action + paths field` patterns. +These patterns are vulnerable to unexpected policy bypasses and you should upgrade to fix the security issue as soon as possible. + +The following is an example of vulnerable policy that uses `DENY action + paths field` pattern: + + {{< text yaml >}} + apiVersion: security.istio.io/v1beta1 + kind: AuthorizationPolicy + metadata: + name: deny-path-admin + spec: + action: DENY + rules: + - to: + - operation: + paths: ["/admin"] + {{< /text >}} + +The following is another example of vulnerable policy that uses `ALLOW action + notPaths field` pattern: + + {{< text yaml >}} + apiVersion: security.istio.io/v1beta1 + kind: AuthorizationPolicy + metadata: + name: allow-path-not-admin + spec: + action: ALLOW + rules: + - to: + - operation: + notPaths: ["/admin"] + {{< /text >}} + +Your cluster is **NOT impacted** by this vulnerability if: + +* You don’t have authorization policies +* Your authorization policies don’t define `paths` or `notPaths` fields. +* Your authorization policies use `ALLOW action + paths field` or `DENY action + notPaths field` patterns. + These patterns could only cause unexpected rejection instead of policy bypasses. The upgrade is optional for these cases. + +## Mitigation + +1. Update your cluster to the latest supported version. + These versions support configuring the Envoy proxies in the system with more normalization options: + * Istio 1.8.6, if using 1.8.x + * Istio 1.9.5 or up + * The patch version specified by your cloud provider +1. Follow the [security best practices](/docs/ops/best-practices/security/#authorization-policies) + to configure your authorization policies. + +## Credit + +We would like to thank [`Ruilin`](https://github.com/Ruil1n) and `Test123` for discovering this issue. diff --git a/content/en/news/security/istio-security-2021-006/index.md b/content/en/news/security/istio-security-2021-006/index.md new file mode 100644 index 0000000000..6bcf61a96a --- /dev/null +++ b/content/en/news/security/istio-security-2021-006/index.md @@ -0,0 +1,43 @@ +--- +title: ISTIO-SECURITY-2021-006 +subtitle: Security Bulletin +description: +cves: [CVE-2021-31921] +cvss: "10" +vector: "AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H" +releases: ["All releases prior to 1.8.6", "1.9.0 to 1.9.4"] +publishdate: 2021-05-11 +keywords: [CVE] +skip_seealso: true +--- + +{{< security_bulletin >}} + +## Issue + +Istio contains a remotely exploitable vulnerability where an external client can access unexpected services in the cluster, +bypassing authorization checks, when a gateway is configured with `AUTO_PASSTHROUGH` routing configuration. + +## Am I impacted? + +This vulnerability impacts only usage of the `AUTO_PASSTHROUGH` Gateway type, which is typically only used in multi-network multi-cluster deployments. + +The TLS mode of all Gateways in the cluster can be detected with the following command: + + {{< text bash >}} + $ kubectl get gateways.networking.istio.io -A -o "custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,TLS_MODE:.spec.servers[*].tls.mode" + {{< /text >}} + +If the output shows any `AUTO_PASSTHROUGH` Gateways, you may be impacted. + +## Mitigation + +Update your cluster to the latest supported version: + +* Istio 1.8.6, if using 1.8.x +* Istio 1.9.5 or up +* The patch version specified by your cloud provider + +## Credit + +We would like to thank John Howard (Google) for reporting this issue.