cve-2023-42503
Vulnerability from cvelistv5
Published
2023-09-14 07:45
Modified
2025-02-13 17:09
Severity ?
Summary
Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. Users are recommended to upgrade to version 1.24.0, which fixes the issue. A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. [1]: https://issues.apache.org/jira/browse/COMPRESS-612 [2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 [3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html [4]: https://bugs.openjdk.org/browse/JDK-6560193 [5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted.
References
security@apache.orghttps://lists.apache.org/thread/5xwcyr600mn074vgxq92tjssrchmc93cIssue Tracking, Mailing List, URL Repurposed
security@apache.orghttps://security.netapp.com/advisory/ntap-20231020-0003/Third Party Advisory
af854a3a-2127-422b-91ae-364da2661108https://lists.apache.org/thread/5xwcyr600mn074vgxq92tjssrchmc93cIssue Tracking, Mailing List, URL Repurposed
af854a3a-2127-422b-91ae-364da2661108https://security.netapp.com/advisory/ntap-20231020-0003/Third Party Advisory
Impacted products
Vendor Product Version
Apache Software Foundation Apache Commons Compress Version: 1.22
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
   containers: {
      adp: [
         {
            providerMetadata: {
               dateUpdated: "2024-08-02T19:23:39.663Z",
               orgId: "af854a3a-2127-422b-91ae-364da2661108",
               shortName: "CVE",
            },
            references: [
               {
                  tags: [
                     "vendor-advisory",
                     "x_transferred",
                  ],
                  url: "https://lists.apache.org/thread/5xwcyr600mn074vgxq92tjssrchmc93c",
               },
               {
                  tags: [
                     "x_transferred",
                  ],
                  url: "https://security.netapp.com/advisory/ntap-20231020-0003/",
               },
            ],
            title: "CVE Program Container",
         },
      ],
      cna: {
         affected: [
            {
               collectionURL: "https://repo.maven.apache.org/maven2/",
               defaultStatus: "unaffected",
               packageName: "org.apache.commons:commons-compress",
               product: "Apache Commons Compress",
               vendor: "Apache Software Foundation",
               versions: [
                  {
                     lessThan: "1.24.0",
                     status: "affected",
                     version: "1.22",
                     versionType: "maven",
                  },
               ],
            },
         ],
         credits: [
            {
               lang: "en",
               type: "reporter",
               value: "Yakov Shafranovich, Amazon Web Services",
            },
         ],
         descriptions: [
            {
               lang: "en",
               supportingMedia: [
                  {
                     base64: false,
                     type: "text/html",
                     value: "Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.<p>This issue affects Apache Commons Compress:&nbsp;from 1.22 before 1.24.0.</p><p>Users are recommended to upgrade to version 1.24.0, which fixes the issue.</p><span style=\"background-color: rgb(255, 255, 255);\">A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption.</span><br><br><span style=\"background-color: rgb(255, 255, 255);\">In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values.</span><br><br><span style=\"background-color: rgb(255, 255, 255);\">Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5].</span><br><br><span style=\"background-color: rgb(255, 255, 255);\">[1]: </span><a target=\"_blank\" rel=\"nofollow\" href=\"https://issues.apache.org/jira/browse/COMPRESS-612\">https://issues.apache.org/jira/browse/COMPRESS-612</a><br><span style=\"background-color: rgb(255, 255, 255);\">[2]: </span><a target=\"_blank\" rel=\"nofollow\" href=\"https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05\">https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05</a><br><span style=\"background-color: rgb(255, 255, 255);\">[3]: </span><a target=\"_blank\" rel=\"nofollow\" href=\"https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html\">https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html</a><br><span style=\"background-color: rgb(255, 255, 255);\">[4]: </span><a target=\"_blank\" rel=\"nofollow\" href=\"https://bugs.openjdk.org/browse/JDK-6560193\">https://bugs.openjdk.org/browse/JDK-6560193</a><br><span style=\"background-color: rgb(255, 255, 255);\">[5]: </span><a target=\"_blank\" rel=\"nofollow\" href=\"https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098\">https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098</a><br><br><span style=\"background-color: rgb(255, 255, 255);\">Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted.</span><br><br>",
                  },
               ],
               value: "Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0.\n\nUsers are recommended to upgrade to version 1.24.0, which fixes the issue.\n\nA third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption.\n\nIn version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values.\n\nParsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5].\n\n[1]:  https://issues.apache.org/jira/browse/COMPRESS-612 \n[2]:  https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 \n[3]:  https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html \n[4]:  https://bugs.openjdk.org/browse/JDK-6560193 \n[5]:  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 \n\nOnly applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted.",
            },
         ],
         metrics: [
            {
               other: {
                  content: {
                     text: "moderate",
                  },
                  type: "Textual description of severity",
               },
            },
         ],
         problemTypes: [
            {
               descriptions: [
                  {
                     cweId: "CWE-20",
                     description: "CWE-20 Improper Input Validation",
                     lang: "en",
                     type: "CWE",
                  },
               ],
            },
            {
               descriptions: [
                  {
                     cweId: "CWE-400",
                     description: "CWE-400 Uncontrolled Resource Consumption",
                     lang: "en",
                     type: "CWE",
                  },
               ],
            },
         ],
         providerMetadata: {
            dateUpdated: "2023-10-20T14:06:29.113Z",
            orgId: "f0158376-9dc2-43b6-827c-5f631a4d8d09",
            shortName: "apache",
         },
         references: [
            {
               tags: [
                  "vendor-advisory",
               ],
               url: "https://lists.apache.org/thread/5xwcyr600mn074vgxq92tjssrchmc93c",
            },
            {
               url: "https://security.netapp.com/advisory/ntap-20231020-0003/",
            },
         ],
         source: {
            discovery: "EXTERNAL",
         },
         title: "Apache Commons Compress: Denial of service via CPU consumption for malformed TAR file",
         x_generator: {
            engine: "Vulnogram 0.1.0-dev",
         },
      },
   },
   cveMetadata: {
      assignerOrgId: "f0158376-9dc2-43b6-827c-5f631a4d8d09",
      assignerShortName: "apache",
      cveId: "CVE-2023-42503",
      datePublished: "2023-09-14T07:45:14.520Z",
      dateReserved: "2023-09-11T11:59:40.623Z",
      dateUpdated: "2025-02-13T17:09:24.584Z",
      state: "PUBLISHED",
   },
   dataType: "CVE_RECORD",
   dataVersion: "5.1",
   "vulnerability-lookup:meta": {
      nvd: "{\"cve\":{\"id\":\"CVE-2023-42503\",\"sourceIdentifier\":\"security@apache.org\",\"published\":\"2023-09-14T08:15:08.057\",\"lastModified\":\"2025-02-13T17:17:08.720\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0.\\n\\nUsers are recommended to upgrade to version 1.24.0, which fixes the issue.\\n\\nA third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption.\\n\\nIn version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values.\\n\\nParsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5].\\n\\n[1]:  https://issues.apache.org/jira/browse/COMPRESS-612 \\n[2]:  https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 \\n[3]:  https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html \\n[4]:  https://bugs.openjdk.org/browse/JDK-6560193 \\n[5]:  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 \\n\\nOnly applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted.\"},{\"lang\":\"es\",\"value\":\"\\\"Vulnerabilidad de Validación de Entrada Incorrecta, Consumo de Recursos Incontrolado en Apache Commons Compress en el análisis TAR. Este problema afecta a Apache Commons Compress: desde 1.22 antes de 1.24.0. Se recomienda a los usuarios actualizar a la versión 1.24.0, que soluciona el problema. Un tercero puede crear un archivo TAR malformado manipulando los encabezados de los tiempos de modificación del archivo, que cuando se analizan con Apache Commons Compress, causarán un problema de denegación de servicio debido al consumo de CPU. En la versión 1.22 de Apache Commons Compress, se soportan tiempos de modificación de archivos con mayor precisión (problema # COMPRESS-612 [1]). El formato de los encabezados extendidos de PAX que contienen estos datos consta de dos números separados por un punto [2], que indica segundos y precisión de subsegundos (por ejemplo, “1647221103.5998539”). Los campos afectados son \\\"\\\"atime\\\"\\\", \\\"\\\"ctime\\\"\\\", \\\"\\\"mtime\\\"\\\" y \\\"\\\"LIBARCHIVE.creationtime\\\"\\\". No se realiza ninguna validación de entrada antes del análisis de los valores del encabezado. El análisis de estos números utiliza la clase BigDecimal [3] del JDK, que tiene un problema de complejidad algorítmica conocido públicamente al realizar operaciones con números grandes, lo que provoca denegación de servicio (consulte el problema # JDK-6560193 [4]). Un tercero puede manipular los encabezados de tiempo de un archivo TAR colocando un número con una fracción muy larga (300.000 dígitos) o un número con notación de exponente (como \\\"\\\"9e9999999\\\"\\\") dentro de un encabezado de tiempo de modificación del archivo y el análisis de los archivos. con estos encabezados llevará horas en lugar de segundos, lo que provocará una denegación de servicio por agotamiento de los recursos de la CPU. Este problema es similar a CVE-2012-2098 [5]. \\n[1]: https://issues.apache.org/jira/browse/COMPRESS-612 \\n[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 \\n[3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html \\n[4]: ??https://bugs.openjdk.org/browse/JDK-6560193 \\n[5]: https: //cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098\\nSolo se ven afectadas las aplicaciones que utilizan la clase CompressorStreamFactory (con detección automática de tipos de archivos), TarArchiveInputStream y TarFile para analizar archivos TAR. Dado que este código se introdujo en la versión 1.22, solo esa versión y las versiones posteriores se ven afectadas.\\\"\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H\",\"baseScore\":5.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"NONE\",\"userInteraction\":\"REQUIRED\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":3.6}]},\"weaknesses\":[{\"source\":\"security@apache.org\",\"type\":\"Secondary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-20\"},{\"lang\":\"en\",\"value\":\"CWE-400\"}]},{\"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:apache:commons_compress:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"1.22\",\"versionEndExcluding\":\"1.24.0\",\"matchCriteriaId\":\"F05475BE-7994-4CCC-A70C-FCBE832D886A\"}]}]}],\"references\":[{\"url\":\"https://lists.apache.org/thread/5xwcyr600mn074vgxq92tjssrchmc93c\",\"source\":\"security@apache.org\",\"tags\":[\"Issue Tracking\",\"Mailing List\",\"URL Repurposed\"]},{\"url\":\"https://security.netapp.com/advisory/ntap-20231020-0003/\",\"source\":\"security@apache.org\",\"tags\":[\"Third Party Advisory\"]},{\"url\":\"https://lists.apache.org/thread/5xwcyr600mn074vgxq92tjssrchmc93c\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Issue Tracking\",\"Mailing List\",\"URL Repurposed\"]},{\"url\":\"https://security.netapp.com/advisory/ntap-20231020-0003/\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Third Party Advisory\"]}]}}",
   },
}


Log in or create an account to share your comment.

Security Advisory comment format.

This schema specifies the format of a comment related to a security advisory.

UUIDv4 of the comment
UUIDv4 of the Vulnerability-Lookup instance
When the comment was created originally
When the comment was last updated
Title of the comment
Description of the comment
The identifier of the vulnerability (CVE ID, GHSA-ID, PYSEC ID, etc.).



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.