CVE-2017-9106 (GCVE-0-2017-9106)
Vulnerability from cvelistv5
Published
2020-06-18 13:08
Modified
2024-08-05 16:55
Severity ?
CWE
  • n/a
Summary
An issue was discovered in adns before 1.5.2. adns_rr_info mishandles a bogus *datap. The general pattern for formatting integers is to sprintf into a fixed-size buffer. This is correct if the input is in the right range; if it isn't, the buffer may be overrun (depending on the sizes of the types on the current platform). Of course the inputs ought to be right. And there are pointers in there too, so perhaps one could say that the caller ought to check these things. It may be better to require the caller to make the pointer structure right, but to have the code here be defensive about (and tolerate with an error but without crashing) out-of-range integer values. So: it should defend each of these integer conversion sites with a check for the actual permitted range, and return adns_s_invaliddata if not. The lack of this check causes the SOA sign extension bug to be a serious security problem: the sign extended SOA value is out of range, and overruns the buffer when reconverted. This is related to sign extending SOA 32-bit integer fields, and use of a signed data type.
References
Impacted products
Vendor Product Version
n/a n/a Version: n/a
Show details on NVD website

To clipboard 

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-05T16:55:22.246Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=adns.git"
          },
          {
            "tags": [
              "x_refsource_CONFIRM",
              "x_transferred"
            ],
            "url": "https://www.chiark.greenend.org.uk/pipermail/adns-announce/2020/000004.html"
          },
          {
            "tags": [
              "x_refsource_CONFIRM",
              "x_transferred"
            ],
            "url": "http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=adns.git%3Ba=blob%3Bf=changelog"
          },
          {
            "name": "FEDORA-2020-530188bf36",
            "tags": [
              "vendor-advisory",
              "x_refsource_FEDORA",
              "x_transferred"
            ],
            "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/TRVHN3GGVNQWAOL3PWC5FLAV7HUESLZR/"
          },
          {
            "name": "FEDORA-2020-e59bcaf702",
            "tags": [
              "vendor-advisory",
              "x_refsource_FEDORA",
              "x_transferred"
            ],
            "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/UGFZ4SPV6KFQK6ZNUZFB5Y32OYFOM5YJ/"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "n/a",
          "vendor": "n/a",
          "versions": [
            {
              "status": "affected",
              "version": "n/a"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "An issue was discovered in adns before 1.5.2. adns_rr_info mishandles a bogus *datap. The general pattern for formatting integers is to sprintf into a fixed-size buffer. This is correct if the input is in the right range; if it isn\u0027t, the buffer may be overrun (depending on the sizes of the types on the current platform). Of course the inputs ought to be right. And there are pointers in there too, so perhaps one could say that the caller ought to check these things. It may be better to require the caller to make the pointer structure right, but to have the code here be defensive about (and tolerate with an error but without crashing) out-of-range integer values. So: it should defend each of these integer conversion sites with a check for the actual permitted range, and return adns_s_invaliddata if not. The lack of this check causes the SOA sign extension bug to be a serious security problem: the sign extended SOA value is out of range, and overruns the buffer when reconverted. This is related to sign extending SOA 32-bit integer fields, and use of a signed data type."
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "description": "n/a",
              "lang": "en",
              "type": "text"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2020-07-02T02:06:09",
        "orgId": "8254265b-2729-46b6-b9e3-3dfca2d5bfca",
        "shortName": "mitre"
      },
      "references": [
        {
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=adns.git"
        },
        {
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://www.chiark.greenend.org.uk/pipermail/adns-announce/2020/000004.html"
        },
        {
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=adns.git%3Ba=blob%3Bf=changelog"
        },
        {
          "name": "FEDORA-2020-530188bf36",
          "tags": [
            "vendor-advisory",
            "x_refsource_FEDORA"
          ],
          "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/TRVHN3GGVNQWAOL3PWC5FLAV7HUESLZR/"
        },
        {
          "name": "FEDORA-2020-e59bcaf702",
          "tags": [
            "vendor-advisory",
            "x_refsource_FEDORA"
          ],
          "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/UGFZ4SPV6KFQK6ZNUZFB5Y32OYFOM5YJ/"
        }
      ],
      "x_legacyV4Record": {
        "CVE_data_meta": {
          "ASSIGNER": "cve@mitre.org",
          "ID": "CVE-2017-9106",
          "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": "An issue was discovered in adns before 1.5.2. adns_rr_info mishandles a bogus *datap. The general pattern for formatting integers is to sprintf into a fixed-size buffer. This is correct if the input is in the right range; if it isn\u0027t, the buffer may be overrun (depending on the sizes of the types on the current platform). Of course the inputs ought to be right. And there are pointers in there too, so perhaps one could say that the caller ought to check these things. It may be better to require the caller to make the pointer structure right, but to have the code here be defensive about (and tolerate with an error but without crashing) out-of-range integer values. So: it should defend each of these integer conversion sites with a check for the actual permitted range, and return adns_s_invaliddata if not. The lack of this check causes the SOA sign extension bug to be a serious security problem: the sign extended SOA value is out of range, and overruns the buffer when reconverted. This is related to sign extending SOA 32-bit integer fields, and use of a signed data type."
            }
          ]
        },
        "problemtype": {
          "problemtype_data": [
            {
              "description": [
                {
                  "lang": "eng",
                  "value": "n/a"
                }
              ]
            }
          ]
        },
        "references": {
          "reference_data": [
            {
              "name": "http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=adns.git",
              "refsource": "MISC",
              "url": "http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=adns.git"
            },
            {
              "name": "https://www.chiark.greenend.org.uk/pipermail/adns-announce/2020/000004.html",
              "refsource": "CONFIRM",
              "url": "https://www.chiark.greenend.org.uk/pipermail/adns-announce/2020/000004.html"
            },
            {
              "name": "http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=adns.git;a=blob;f=changelog",
              "refsource": "CONFIRM",
              "url": "http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=adns.git;a=blob;f=changelog"
            },
            {
              "name": "FEDORA-2020-530188bf36",
              "refsource": "FEDORA",
              "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/TRVHN3GGVNQWAOL3PWC5FLAV7HUESLZR/"
            },
            {
              "name": "FEDORA-2020-e59bcaf702",
              "refsource": "FEDORA",
              "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UGFZ4SPV6KFQK6ZNUZFB5Y32OYFOM5YJ/"
            }
          ]
        }
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "8254265b-2729-46b6-b9e3-3dfca2d5bfca",
    "assignerShortName": "mitre",
    "cveId": "CVE-2017-9106",
    "datePublished": "2020-06-18T13:08:28",
    "dateReserved": "2017-05-21T00:00:00",
    "dateUpdated": "2024-08-05T16:55:22.246Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2017-9106\",\"sourceIdentifier\":\"cve@mitre.org\",\"published\":\"2020-06-18T14:15:10.467\",\"lastModified\":\"2024-11-21T03:35:19.873\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"An issue was discovered in adns before 1.5.2. adns_rr_info mishandles a bogus *datap. The general pattern for formatting integers is to sprintf into a fixed-size buffer. This is correct if the input is in the right range; if it isn\u0027t, the buffer may be overrun (depending on the sizes of the types on the current platform). Of course the inputs ought to be right. And there are pointers in there too, so perhaps one could say that the caller ought to check these things. It may be better to require the caller to make the pointer structure right, but to have the code here be defensive about (and tolerate with an error but without crashing) out-of-range integer values. So: it should defend each of these integer conversion sites with a check for the actual permitted range, and return adns_s_invaliddata if not. The lack of this check causes the SOA sign extension bug to be a serious security problem: the sign extended SOA value is out of range, and overruns the buffer when reconverted. This is related to sign extending SOA 32-bit integer fields, and use of a signed data type.\"},{\"lang\":\"es\",\"value\":\"Se detect\u00f3 un problema en adns versiones anteriores a 1.5.2. adns_rr_info maneja inapropiadamente un *datap falso. El patr\u00f3n general para formatear enteros es sprintf en un b\u00fafer de tama\u00f1o fijo. Esto es correcto si la entrada est\u00e1 en el rango correcto; de lo contrario, el b\u00fafer puede estar desbordado (dependiendo del tama\u00f1o de los tipos en la plataforma actual). Por supuesto, las entradas deben ser correctas. Y existen indicadores all\u00ed tambi\u00e9n, as\u00ed que quiz\u00e1s se podr\u00eda decir que la persona que llama debe comprobar estas cosas. Puede ser mejor requerir que la persona que llama haga que la estructura del puntero sea correcta, pero que el c\u00f3digo aqu\u00ed sea defensivo sobre (y tolere con un error pero sin bloquear) valores enteros fuera de rango. Por lo tanto: debe defender cada uno de estos sitios de conversi\u00f3n de enteros con una comprobaci\u00f3n del rango real permitido y devolver adns_s_invaliddata si no lo hace. La falta de esta comprobaci\u00f3n hace que el error de extensi\u00f3n de signo de SOA sea un problema de seguridad grave: el valor de SOA extendido de signo est\u00e1 fuera de rango y supera el b\u00fafer cuando se reconvierte. Esto est\u00e1 relacionado con el signo que extiende los campos enteros SOA de 32 bits y el uso de un tipo de datos con signo\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":7.5,\"baseSeverity\":\"HIGH\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"NONE\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":3.9,\"impactScore\":3.6}],\"cvssMetricV2\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"2.0\",\"vectorString\":\"AV:N/AC:L/Au:N/C:N/I:N/A:P\",\"baseScore\":5.0,\"accessVector\":\"NETWORK\",\"accessComplexity\":\"LOW\",\"authentication\":\"NONE\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"PARTIAL\"},\"baseSeverity\":\"MEDIUM\",\"exploitabilityScore\":10.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-119\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:a:gnu:adns:*:*:*:*:*:*:*:*\",\"versionEndExcluding\":\"1.5.2\",\"matchCriteriaId\":\"F69A58A4-C51A-493B-A5C9-8C7471A0BFF3\"}]}]},{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:fedoraproject:fedora:31:*:*:*:*:*:*:*\",\"matchCriteriaId\":\"80F0FA5D-8D3B-4C0E-81E2-87998286AF33\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:fedoraproject:fedora:32:*:*:*:*:*:*:*\",\"matchCriteriaId\":\"36D96259-24BD-44E2-96D9-78CE1D41F956\"}]}]}],\"references\":[{\"url\":\"http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=adns.git\",\"source\":\"cve@mitre.org\",\"tags\":[\"Third Party Advisory\"]},{\"url\":\"http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=adns.git%3Ba=blob%3Bf=changelog\",\"source\":\"cve@mitre.org\"},{\"url\":\"https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/TRVHN3GGVNQWAOL3PWC5FLAV7HUESLZR/\",\"source\":\"cve@mitre.org\"},{\"url\":\"https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/UGFZ4SPV6KFQK6ZNUZFB5Y32OYFOM5YJ/\",\"source\":\"cve@mitre.org\"},{\"url\":\"https://www.chiark.greenend.org.uk/pipermail/adns-announce/2020/000004.html\",\"source\":\"cve@mitre.org\",\"tags\":[\"Release Notes\",\"Third Party Advisory\"]},{\"url\":\"http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=adns.git\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Third Party Advisory\"]},{\"url\":\"http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=adns.git%3Ba=blob%3Bf=changelog\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/TRVHN3GGVNQWAOL3PWC5FLAV7HUESLZR/\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/UGFZ4SPV6KFQK6ZNUZFB5Y32OYFOM5YJ/\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://www.chiark.greenend.org.uk/pipermail/adns-announce/2020/000004.html\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Release Notes\",\"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 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.