mirror of https://github.com/istio/istio.io.git
Cherry-pick changes from 1.9 security releases to master (#9735)
This commit is contained in:
Eric Van Norman
GitHub
parent
f0d8aa3415
commit
74df6d070a
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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!
|
||||
|
|
@ -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 <<EOF > 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.
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ current `<minor>` release. A patch is usually a small change relative to the `<m
|
|||
| 1.6 | No | May 21, 2020 | November 23, 2020 | 1.15, 1.16, 1.17, 1.18 | |
|
||||
| 1.5 and earlier | No | | | | |
|
||||
|
||||
## Releases without known Common Vulnerabilities and Exposures (CVEs)
|
||||
## Supported releases without known Common Vulnerabilities and Exposures (CVEs)
|
||||
|
||||
{{< warning >}}
|
||||
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 |
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
@ -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)
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
Loading…
Reference in New Issue