cve-2020-7942
Vulnerability from cvelistv5
Published
2020-02-19 20:52
Modified
2024-08-04 09:48
Severity ?
Summary
Previously, Puppet operated on a model that a node with a valid certificate was entitled to all information in the system and that a compromised certificate allowed access to everything in the infrastructure. When a node's catalog falls back to the `default` node, the catalog can be retrieved for a different node by modifying facts for the Puppet run. This issue can be mitigated by setting `strict_hostname_checking = true` in `puppet.conf` on your Puppet master. Puppet 6.13.0 and 5.5.19 changes the default behavior for strict_hostname_checking from false to true. It is recommended that Puppet Open Source and Puppet Enterprise users that are not upgrading still set strict_hostname_checking to true to ensure secure behavior. Affected software versions: Puppet 6.x prior to 6.13.0 Puppet Agent 6.x prior to 6.13.0 Puppet 5.5.x prior to 5.5.19 Puppet Agent 5.5.x prior to 5.5.19 Resolved in: Puppet 6.13.0 Puppet Agent 6.13.0 Puppet 5.5.19 Puppet Agent 5.5.19
Impacted products
Vendor Product Version
Puppet Puppet Agent Version: 5.5.x prior to 5.5.19
Version: Fixed in 5.5.19
Version: 6.x prior to 6.13.0
Version: Fixed in 6.13.0
Show details on NVD website


{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-04T09:48:24.553Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_refsource_CONFIRM",
              "x_transferred"
            ],
            "url": "https://puppet.com/security/cve/CVE-2020-7942/"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "Puppet",
          "vendor": "Puppet",
          "versions": [
            {
              "status": "affected",
              "version": "5.5.x prior to 5.5.19"
            },
            {
              "status": "affected",
              "version": "Fixed in 5.5.19"
            },
            {
              "status": "affected",
              "version": "6.x prior to 6.13.0"
            },
            {
              "status": "affected",
              "version": "Fixed in 6.13.0"
            }
          ]
        },
        {
          "product": "Puppet Agent",
          "vendor": "Puppet",
          "versions": [
            {
              "status": "affected",
              "version": "5.5.x prior to 5.5.19"
            },
            {
              "status": "affected",
              "version": "Fixed in 5.5.19"
            },
            {
              "status": "affected",
              "version": "6.x prior to 6.13.0"
            },
            {
              "status": "affected",
              "version": "Fixed in 6.13.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Previously, Puppet operated on a model that a node with a valid certificate was entitled to all information in the system and that a compromised certificate allowed access to everything in the infrastructure. When a node\u0027s catalog falls back to the `default` node, the catalog can be retrieved for a different node by modifying facts for the Puppet run. This issue can be mitigated by setting `strict_hostname_checking = true` in `puppet.conf` on your Puppet master. Puppet 6.13.0 and 5.5.19 changes the default behavior for strict_hostname_checking from false to true. It is recommended that Puppet Open Source and Puppet Enterprise users that are not upgrading still set strict_hostname_checking to true to ensure secure behavior. Affected software versions: Puppet 6.x prior to 6.13.0 Puppet Agent 6.x prior to 6.13.0 Puppet 5.5.x prior to 5.5.19 Puppet Agent 5.5.x prior to 5.5.19 Resolved in: Puppet 6.13.0 Puppet Agent 6.13.0 Puppet 5.5.19 Puppet Agent 5.5.19"
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "description": "Arbitrary retrieval",
              "lang": "en",
              "type": "text"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2020-04-02T19:00:07",
        "orgId": "ca2a266c-be2f-4d4b-92d0-47b76b1a9c4e",
        "shortName": "puppet"
      },
      "references": [
        {
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://puppet.com/security/cve/CVE-2020-7942/"
        }
      ],
      "x_legacyV4Record": {
        "CVE_data_meta": {
          "ASSIGNER": "security@puppet.com",
          "ID": "CVE-2020-7942",
          "STATE": "PUBLIC"
        },
        "affects": {
          "vendor": {
            "vendor_data": [
              {
                "product": {
                  "product_data": [
                    {
                      "product_name": "Puppet",
                      "version": {
                        "version_data": [
                          {
                            "version_value": "5.5.x prior to 5.5.19"
                          },
                          {
                            "version_value": "Fixed in 5.5.19"
                          },
                          {
                            "version_value": "6.x prior to 6.13.0"
                          },
                          {
                            "version_value": "Fixed in 6.13.0"
                          }
                        ]
                      }
                    },
                    {
                      "product_name": "Puppet Agent",
                      "version": {
                        "version_data": [
                          {
                            "version_value": "5.5.x prior to 5.5.19"
                          },
                          {
                            "version_value": "Fixed in 5.5.19"
                          },
                          {
                            "version_value": "6.x prior to 6.13.0"
                          },
                          {
                            "version_value": "Fixed in 6.13.0"
                          }
                        ]
                      }
                    }
                  ]
                },
                "vendor_name": "Puppet"
              }
            ]
          }
        },
        "data_format": "MITRE",
        "data_type": "CVE",
        "data_version": "4.0",
        "description": {
          "description_data": [
            {
              "lang": "eng",
              "value": "Previously, Puppet operated on a model that a node with a valid certificate was entitled to all information in the system and that a compromised certificate allowed access to everything in the infrastructure. When a node\u0027s catalog falls back to the `default` node, the catalog can be retrieved for a different node by modifying facts for the Puppet run. This issue can be mitigated by setting `strict_hostname_checking = true` in `puppet.conf` on your Puppet master. Puppet 6.13.0 and 5.5.19 changes the default behavior for strict_hostname_checking from false to true. It is recommended that Puppet Open Source and Puppet Enterprise users that are not upgrading still set strict_hostname_checking to true to ensure secure behavior. Affected software versions: Puppet 6.x prior to 6.13.0 Puppet Agent 6.x prior to 6.13.0 Puppet 5.5.x prior to 5.5.19 Puppet Agent 5.5.x prior to 5.5.19 Resolved in: Puppet 6.13.0 Puppet Agent 6.13.0 Puppet 5.5.19 Puppet Agent 5.5.19"
            }
          ]
        },
        "problemtype": {
          "problemtype_data": [
            {
              "description": [
                {
                  "lang": "eng",
                  "value": "Arbitrary retrieval"
                }
              ]
            }
          ]
        },
        "references": {
          "reference_data": [
            {
              "name": "https://puppet.com/security/cve/CVE-2020-7942/",
              "refsource": "CONFIRM",
              "url": "https://puppet.com/security/cve/CVE-2020-7942/"
            }
          ]
        }
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "ca2a266c-be2f-4d4b-92d0-47b76b1a9c4e",
    "assignerShortName": "puppet",
    "cveId": "CVE-2020-7942",
    "datePublished": "2020-02-19T20:52:03",
    "dateReserved": "2020-01-23T00:00:00",
    "dateUpdated": "2024-08-04T09:48:24.553Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2020-7942\",\"sourceIdentifier\":\"security@puppet.com\",\"published\":\"2020-02-19T21:15:11.747\",\"lastModified\":\"2024-11-21T05:38:03.537\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"Previously, Puppet operated on a model that a node with a valid certificate was entitled to all information in the system and that a compromised certificate allowed access to everything in the infrastructure. When a node\u0027s catalog falls back to the `default` node, the catalog can be retrieved for a different node by modifying facts for the Puppet run. This issue can be mitigated by setting `strict_hostname_checking = true` in `puppet.conf` on your Puppet master. Puppet 6.13.0 and 5.5.19 changes the default behavior for strict_hostname_checking from false to true. It is recommended that Puppet Open Source and Puppet Enterprise users that are not upgrading still set strict_hostname_checking to true to ensure secure behavior. Affected software versions: Puppet 6.x prior to 6.13.0 Puppet Agent 6.x prior to 6.13.0 Puppet 5.5.x prior to 5.5.19 Puppet Agent 5.5.x prior to 5.5.19 Resolved in: Puppet 6.13.0 Puppet Agent 6.13.0 Puppet 5.5.19 Puppet Agent 5.5.19\"},{\"lang\":\"es\",\"value\":\"Anteriormente, Puppet operaba en un modelo en el que un nodo con un certificado v\u00e1lido ten\u00eda derecho a toda la informaci\u00f3n del sistema y que un certificado comprometido permit\u00eda el acceso a todo en la infraestructura. Cuando el cat\u00e1logo de un nodo retrocede al nodo \\\"default\\\", el cat\u00e1logo puede ser recuperado para un nodo diferente mediante la modificaci\u00f3n de datos para una ejecuci\u00f3n de Puppet. Este problema puede ser mitigado al configurar \\\"strictly_hostname_checking = true\\\" en \\\"puppet.conf\\\" en su maestro de Puppet. Puppet versi\u00f3n 6.13.0 y versi\u00f3n 5.5.19 cambia el comportamiento predeterminado para el strict_hostname_checking de falso a verdadero. Se recomienda que los usuarios de Puppet Open Source y Puppet Enterprise que no est\u00e1n actualizando establezcan stric_nombre_host_checking en verdadero para garantizar un comportamiento seguro. Versiones de software afectadas: Puppet versi\u00f3n 6.x en versiones anteriores a la 6.13.0 Puppet Agent versi\u00f3n 6.x en versiones anteriores a la 6.13.0 Puppet versi\u00f3n 5.5.x en versiones anteriores a la 5.5.19 Puppet Agent versi\u00f3n 5.5.x en versiones anteriores a la 5.5.19 Resuelto en: Puppet versi\u00f3n 6.13.0 Puppet Agente versi\u00f3n 6.13.0 Puppet versi\u00f3n 5.5.19 Puppet Agent versi\u00f3n 5.5.19.\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N\",\"baseScore\":6.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"NONE\"},\"exploitabilityScore\":2.8,\"impactScore\":3.6}],\"cvssMetricV2\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"2.0\",\"vectorString\":\"AV:N/AC:L/Au:S/C:P/I:N/A:N\",\"baseScore\":4.0,\"accessVector\":\"NETWORK\",\"accessComplexity\":\"LOW\",\"authentication\":\"SINGLE\",\"confidentialityImpact\":\"PARTIAL\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"NONE\"},\"baseSeverity\":\"MEDIUM\",\"exploitabilityScore\":8.0,\"impactScore\":2.9,\"acInsufInfo\":false,\"obtainAllPrivilege\":false,\"obtainUserPrivilege\":false,\"obtainOtherPrivilege\":false,\"userInteractionRequired\":false}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-295\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:a:puppet:puppet:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.5.0\",\"versionEndExcluding\":\"5.5.19\",\"matchCriteriaId\":\"E1316D93-D540-4E07-97B9-0FD9DAC19D5E\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:a:puppet:puppet:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.0.0\",\"versionEndExcluding\":\"6.13.0\",\"matchCriteriaId\":\"2A32C5AF-A28C-464B-949D-570BD98D36C9\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:a:puppet:puppet_agent:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.5.0\",\"versionEndExcluding\":\"5.5.19\",\"matchCriteriaId\":\"09EAB60C-0BE2-4FCA-9867-2D6CA4F84F35\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:a:puppet:puppet_agent:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.0.0\",\"versionEndExcluding\":\"6.13.0\",\"matchCriteriaId\":\"C76E5E7E-185B-48E7-AC61-C7F97F1B46BC\"}]}]}],\"references\":[{\"url\":\"https://puppet.com/security/cve/CVE-2020-7942/\",\"source\":\"security@puppet.com\",\"tags\":[\"Vendor Advisory\"]},{\"url\":\"https://puppet.com/security/cve/CVE-2020-7942/\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Vendor Advisory\"]}]}}"
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.