CVE-2020-11767 (GCVE-0-2020-11767)

Vulnerability from cvelistv5 – Published: 2020-04-15 01:05 – Updated: 2024-08-04 11:41
VLAI?
Summary
Istio through 1.5.1 and Envoy through 1.14.1 have a data-leak issue. If there is a TCP connection (negotiated with SNI over HTTPS) to *.example.com, a request for a domain concurrently configured explicitly (e.g., abc.example.com) is sent to the server(s) listening behind *.example.com. The outcome should instead be 421 Misdirected Request. Imagine a shared caching forward proxy re-using an HTTP/2 connection for a large subnet with many users. If a victim is interacting with abc.example.com, and a server (for abc.example.com) recycles the TCP connection to the forward proxy, the victim's browser may suddenly start sending sensitive data to a *.example.com server. This occurs because the forward proxy between the victim and the origin server reuses connections (which obeys the specification), but neither Istio nor Envoy corrects this by sending a 421 error. Similarly, this behavior voids the security model browsers have put in place between domains.
Severity ?
No CVSS data available.
CWE
  • n/a
Assigner
References
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-04T11:41:59.750Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://bugs.chromium.org/p/chromium/issues/detail?id=954160#c5"
          },
          {
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://github.com/envoyproxy/envoy/issues/6767"
          },
          {
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://github.com/istio/istio/issues/9429"
          },
          {
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://github.com/istio/istio/issues/13589"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "n/a",
          "vendor": "n/a",
          "versions": [
            {
              "status": "affected",
              "version": "n/a"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Istio through 1.5.1 and Envoy through 1.14.1 have a data-leak issue. If there is a TCP connection (negotiated with SNI over HTTPS) to *.example.com, a request for a domain concurrently configured explicitly (e.g., abc.example.com) is sent to the server(s) listening behind *.example.com. The outcome should instead be 421 Misdirected Request. Imagine a shared caching forward proxy re-using an HTTP/2 connection for a large subnet with many users. If a victim is interacting with abc.example.com, and a server (for abc.example.com) recycles the TCP connection to the forward proxy, the victim\u0027s browser may suddenly start sending sensitive data to a *.example.com server. This occurs because the forward proxy between the victim and the origin server reuses connections (which obeys the specification), but neither Istio nor Envoy corrects this by sending a 421 error. Similarly, this behavior voids the security model browsers have put in place between domains."
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "description": "n/a",
              "lang": "en",
              "type": "text"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2020-04-15T01:05:38",
        "orgId": "8254265b-2729-46b6-b9e3-3dfca2d5bfca",
        "shortName": "mitre"
      },
      "references": [
        {
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://bugs.chromium.org/p/chromium/issues/detail?id=954160#c5"
        },
        {
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/envoyproxy/envoy/issues/6767"
        },
        {
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/istio/istio/issues/9429"
        },
        {
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/istio/istio/issues/13589"
        }
      ],
      "x_legacyV4Record": {
        "CVE_data_meta": {
          "ASSIGNER": "cve@mitre.org",
          "ID": "CVE-2020-11767",
          "STATE": "PUBLIC"
        },
        "affects": {
          "vendor": {
            "vendor_data": [
              {
                "product": {
                  "product_data": [
                    {
                      "product_name": "n/a",
                      "version": {
                        "version_data": [
                          {
                            "version_value": "n/a"
                          }
                        ]
                      }
                    }
                  ]
                },
                "vendor_name": "n/a"
              }
            ]
          }
        },
        "data_format": "MITRE",
        "data_type": "CVE",
        "data_version": "4.0",
        "description": {
          "description_data": [
            {
              "lang": "eng",
              "value": "Istio through 1.5.1 and Envoy through 1.14.1 have a data-leak issue. If there is a TCP connection (negotiated with SNI over HTTPS) to *.example.com, a request for a domain concurrently configured explicitly (e.g., abc.example.com) is sent to the server(s) listening behind *.example.com. The outcome should instead be 421 Misdirected Request. Imagine a shared caching forward proxy re-using an HTTP/2 connection for a large subnet with many users. If a victim is interacting with abc.example.com, and a server (for abc.example.com) recycles the TCP connection to the forward proxy, the victim\u0027s browser may suddenly start sending sensitive data to a *.example.com server. This occurs because the forward proxy between the victim and the origin server reuses connections (which obeys the specification), but neither Istio nor Envoy corrects this by sending a 421 error. Similarly, this behavior voids the security model browsers have put in place between domains."
            }
          ]
        },
        "problemtype": {
          "problemtype_data": [
            {
              "description": [
                {
                  "lang": "eng",
                  "value": "n/a"
                }
              ]
            }
          ]
        },
        "references": {
          "reference_data": [
            {
              "name": "https://bugs.chromium.org/p/chromium/issues/detail?id=954160#c5",
              "refsource": "MISC",
              "url": "https://bugs.chromium.org/p/chromium/issues/detail?id=954160#c5"
            },
            {
              "name": "https://github.com/envoyproxy/envoy/issues/6767",
              "refsource": "MISC",
              "url": "https://github.com/envoyproxy/envoy/issues/6767"
            },
            {
              "name": "https://github.com/istio/istio/issues/9429",
              "refsource": "MISC",
              "url": "https://github.com/istio/istio/issues/9429"
            },
            {
              "name": "https://github.com/istio/istio/issues/13589",
              "refsource": "MISC",
              "url": "https://github.com/istio/istio/issues/13589"
            }
          ]
        }
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "8254265b-2729-46b6-b9e3-3dfca2d5bfca",
    "assignerShortName": "mitre",
    "cveId": "CVE-2020-11767",
    "datePublished": "2020-04-15T01:05:38",
    "dateReserved": "2020-04-15T00:00:00",
    "dateUpdated": "2024-08-04T11:41:59.750Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "fkie_nvd": {
      "configurations": "[{\"nodes\": [{\"operator\": \"OR\", \"negate\": false, \"cpeMatch\": [{\"vulnerable\": true, \"criteria\": \"cpe:2.3:a:envoyproxy:envoy:*:*:*:*:*:*:*:*\", \"versionEndIncluding\": \"1.14.1\", \"matchCriteriaId\": \"CCE5F040-C8AF-4F73-AB1F-D0A2752AD185\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:a:istio:istio:*:*:*:*:*:*:*:*\", \"versionEndIncluding\": \"1.5.1\", \"matchCriteriaId\": \"2122D404-F673-4F12-B91C-1338F3AEE5CC\"}]}]}]",
      "descriptions": "[{\"lang\": \"en\", \"value\": \"Istio through 1.5.1 and Envoy through 1.14.1 have a data-leak issue. If there is a TCP connection (negotiated with SNI over HTTPS) to *.example.com, a request for a domain concurrently configured explicitly (e.g., abc.example.com) is sent to the server(s) listening behind *.example.com. The outcome should instead be 421 Misdirected Request. Imagine a shared caching forward proxy re-using an HTTP/2 connection for a large subnet with many users. If a victim is interacting with abc.example.com, and a server (for abc.example.com) recycles the TCP connection to the forward proxy, the victim\u0027s browser may suddenly start sending sensitive data to a *.example.com server. This occurs because the forward proxy between the victim and the origin server reuses connections (which obeys the specification), but neither Istio nor Envoy corrects this by sending a 421 error. Similarly, this behavior voids the security model browsers have put in place between domains.\"}, {\"lang\": \"es\", \"value\": \"Istio versiones hasta 1.5.1 y Envoy versiones hasta 1.14.1, presenta un problema de p\\u00e9rdida de datos. Si existe una conexi\\u00f3n TCP (negociada con SNI a trav\\u00e9s de HTTPS) a *.example.com, se env\\u00eda una petici\\u00f3n de un dominio configurado de manera simult\\u00e1nea expl\\u00edcitamente (por ejemplo, abc.example.com) hacia los servidores que escuchan detr\\u00e1s de * .example.com. El resultado en su lugar deber\\u00eda ser 421 Misdirected Request. Imagine un proxy directo de almacenamiento en cach\\u00e9 compartido que reutiliza una conexi\\u00f3n HTTP/2 para una subred grande con muchos usuarios. Si una v\\u00edctima est\\u00e1 interactuando con abc.example.com, y un servidor (para abc.example.com) recicla la conexi\\u00f3n TCP al proxy directo, el navegador de la v\\u00edctima puede comenzar a enviar datos confidenciales hacia un servidor *.example.com. Esto ocurre porque el proxy de reenv\\u00edo entre la v\\u00edctima y el servidor de origen reutiliza las conexiones (que obedecen la especificaci\\u00f3n), pero ni Istio ni Envoy corrigen esto al enviar un error 421. Del mismo modo, este comportamiento anula los modelos de seguridad que los navegadores han implementado entre dominios.\"}]",
      "id": "CVE-2020-11767",
      "lastModified": "2024-11-21T04:58:34.233",
      "metrics": "{\"cvssMetricV31\": [{\"source\": \"nvd@nist.gov\", \"type\": \"Primary\", \"cvssData\": {\"version\": \"3.1\", \"vectorString\": \"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N\", \"baseScore\": 3.1, \"baseSeverity\": \"LOW\", \"attackVector\": \"NETWORK\", \"attackComplexity\": \"HIGH\", \"privilegesRequired\": \"NONE\", \"userInteraction\": \"REQUIRED\", \"scope\": \"UNCHANGED\", \"confidentialityImpact\": \"LOW\", \"integrityImpact\": \"NONE\", \"availabilityImpact\": \"NONE\"}, \"exploitabilityScore\": 1.6, \"impactScore\": 1.4}], \"cvssMetricV2\": [{\"source\": \"nvd@nist.gov\", \"type\": \"Primary\", \"cvssData\": {\"version\": \"2.0\", \"vectorString\": \"AV:N/AC:H/Au:N/C:P/I:N/A:N\", \"baseScore\": 2.6, \"accessVector\": \"NETWORK\", \"accessComplexity\": \"HIGH\", \"authentication\": \"NONE\", \"confidentialityImpact\": \"PARTIAL\", \"integrityImpact\": \"NONE\", \"availabilityImpact\": \"NONE\"}, \"baseSeverity\": \"LOW\", \"exploitabilityScore\": 4.9, \"impactScore\": 2.9, \"acInsufInfo\": false, \"obtainAllPrivilege\": false, \"obtainUserPrivilege\": false, \"obtainOtherPrivilege\": false, \"userInteractionRequired\": true}]}",
      "published": "2020-04-15T02:15:14.000",
      "references": "[{\"url\": \"https://bugs.chromium.org/p/chromium/issues/detail?id=954160#c5\", \"source\": \"cve@mitre.org\", \"tags\": [\"Issue Tracking\", \"Third Party Advisory\"]}, {\"url\": \"https://github.com/envoyproxy/envoy/issues/6767\", \"source\": \"cve@mitre.org\", \"tags\": [\"Third Party Advisory\"]}, {\"url\": \"https://github.com/istio/istio/issues/13589\", \"source\": \"cve@mitre.org\", \"tags\": [\"Exploit\", \"Third Party Advisory\"]}, {\"url\": \"https://github.com/istio/istio/issues/9429\", \"source\": \"cve@mitre.org\", \"tags\": [\"Third Party Advisory\"]}, {\"url\": \"https://bugs.chromium.org/p/chromium/issues/detail?id=954160#c5\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\", \"tags\": [\"Issue Tracking\", \"Third Party Advisory\"]}, {\"url\": \"https://github.com/envoyproxy/envoy/issues/6767\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\", \"tags\": [\"Third Party Advisory\"]}, {\"url\": \"https://github.com/istio/istio/issues/13589\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\", \"tags\": [\"Exploit\", \"Third Party Advisory\"]}, {\"url\": \"https://github.com/istio/istio/issues/9429\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\", \"tags\": [\"Third Party Advisory\"]}]",
      "sourceIdentifier": "cve@mitre.org",
      "vulnStatus": "Modified",
      "weaknesses": "[{\"source\": \"nvd@nist.gov\", \"type\": \"Primary\", \"description\": [{\"lang\": \"en\", \"value\": \"NVD-CWE-noinfo\"}]}]"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2020-11767\",\"sourceIdentifier\":\"cve@mitre.org\",\"published\":\"2020-04-15T02:15:14.000\",\"lastModified\":\"2024-11-21T04:58:34.233\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"Istio through 1.5.1 and Envoy through 1.14.1 have a data-leak issue. If there is a TCP connection (negotiated with SNI over HTTPS) to *.example.com, a request for a domain concurrently configured explicitly (e.g., abc.example.com) is sent to the server(s) listening behind *.example.com. The outcome should instead be 421 Misdirected Request. Imagine a shared caching forward proxy re-using an HTTP/2 connection for a large subnet with many users. If a victim is interacting with abc.example.com, and a server (for abc.example.com) recycles the TCP connection to the forward proxy, the victim\u0027s browser may suddenly start sending sensitive data to a *.example.com server. This occurs because the forward proxy between the victim and the origin server reuses connections (which obeys the specification), but neither Istio nor Envoy corrects this by sending a 421 error. Similarly, this behavior voids the security model browsers have put in place between domains.\"},{\"lang\":\"es\",\"value\":\"Istio versiones hasta 1.5.1 y Envoy versiones hasta 1.14.1, presenta un problema de p\u00e9rdida de datos. Si existe una conexi\u00f3n TCP (negociada con SNI a trav\u00e9s de HTTPS) a *.example.com, se env\u00eda una petici\u00f3n de un dominio configurado de manera simult\u00e1nea expl\u00edcitamente (por ejemplo, abc.example.com) hacia los servidores que escuchan detr\u00e1s de * .example.com. El resultado en su lugar deber\u00eda ser 421 Misdirected Request. Imagine un proxy directo de almacenamiento en cach\u00e9 compartido que reutiliza una conexi\u00f3n HTTP/2 para una subred grande con muchos usuarios. Si una v\u00edctima est\u00e1 interactuando con abc.example.com, y un servidor (para abc.example.com) recicla la conexi\u00f3n TCP al proxy directo, el navegador de la v\u00edctima puede comenzar a enviar datos confidenciales hacia un servidor *.example.com. Esto ocurre porque el proxy de reenv\u00edo entre la v\u00edctima y el servidor de origen reutiliza las conexiones (que obedecen la especificaci\u00f3n), pero ni Istio ni Envoy corrigen esto al enviar un error 421. Del mismo modo, este comportamiento anula los modelos de seguridad que los navegadores han implementado entre dominios.\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N\",\"baseScore\":3.1,\"baseSeverity\":\"LOW\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"HIGH\",\"privilegesRequired\":\"NONE\",\"userInteraction\":\"REQUIRED\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"LOW\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"NONE\"},\"exploitabilityScore\":1.6,\"impactScore\":1.4}],\"cvssMetricV2\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"2.0\",\"vectorString\":\"AV:N/AC:H/Au:N/C:P/I:N/A:N\",\"baseScore\":2.6,\"accessVector\":\"NETWORK\",\"accessComplexity\":\"HIGH\",\"authentication\":\"NONE\",\"confidentialityImpact\":\"PARTIAL\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"NONE\"},\"baseSeverity\":\"LOW\",\"exploitabilityScore\":4.9,\"impactScore\":2.9,\"acInsufInfo\":false,\"obtainAllPrivilege\":false,\"obtainUserPrivilege\":false,\"obtainOtherPrivilege\":false,\"userInteractionRequired\":true}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"NVD-CWE-noinfo\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:a:envoyproxy:envoy:*:*:*:*:*:*:*:*\",\"versionEndIncluding\":\"1.14.1\",\"matchCriteriaId\":\"CCE5F040-C8AF-4F73-AB1F-D0A2752AD185\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:a:istio:istio:*:*:*:*:*:*:*:*\",\"versionEndIncluding\":\"1.5.1\",\"matchCriteriaId\":\"2122D404-F673-4F12-B91C-1338F3AEE5CC\"}]}]}],\"references\":[{\"url\":\"https://bugs.chromium.org/p/chromium/issues/detail?id=954160#c5\",\"source\":\"cve@mitre.org\",\"tags\":[\"Issue Tracking\",\"Third Party Advisory\"]},{\"url\":\"https://github.com/envoyproxy/envoy/issues/6767\",\"source\":\"cve@mitre.org\",\"tags\":[\"Third Party Advisory\"]},{\"url\":\"https://github.com/istio/istio/issues/13589\",\"source\":\"cve@mitre.org\",\"tags\":[\"Exploit\",\"Third Party Advisory\"]},{\"url\":\"https://github.com/istio/istio/issues/9429\",\"source\":\"cve@mitre.org\",\"tags\":[\"Third Party Advisory\"]},{\"url\":\"https://bugs.chromium.org/p/chromium/issues/detail?id=954160#c5\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Issue Tracking\",\"Third Party Advisory\"]},{\"url\":\"https://github.com/envoyproxy/envoy/issues/6767\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Third Party Advisory\"]},{\"url\":\"https://github.com/istio/istio/issues/13589\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Exploit\",\"Third Party Advisory\"]},{\"url\":\"https://github.com/istio/istio/issues/9429\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Third Party Advisory\"]}]}}"
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.