ghsa-5mcr-gq6c-3hq2
Vulnerability from github
Published
2021-02-08 21:17
Modified
2022-04-19 15:19
Severity ?
6.2 (Medium) - CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Summary
Local Information Disclosure Vulnerability in Netty on Unix-Like systems
Details

Impact

When netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled.

The CVSSv3.1 score of this vulnerability is calculated to be a 6.2/10

Vulnerability Details

On unix-like systems, the temporary directory is shared between all user. As such, writing to this directory using APIs that do not explicitly set the file/directory permissions can lead to information disclosure. Of note, this does not impact modern MacOS Operating Systems.

The method File.createTempFile on unix-like systems creates a random file, but, by default will create this file with the permissions -rw-r--r--. Thus, if sensitive information is written to this file, other local users can read this information.

This is the case in netty's AbstractDiskHttpData is vulnerable.

https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101

AbstractDiskHttpData is used as a part of the DefaultHttpDataFactory class which is used by HttpPostRequestDecoder / HttpPostMultiPartRequestDecoder.

You may be affected by this vulnerability your project contains the following code patterns:

java channelPipeline.addLast(new HttpPostRequestDecoder(...));

java channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...));

Patches

This has been patched in version 4.1.59.Final.

Workarounds

Specify your own java.io.tmpdir when you start the JVM or use DefaultHttpDataFactory.setBaseDir(...) to set the directory to something that is only readable by the current user.

References

Similar Vulnerabilities

Similar, but not the same.

  • JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp
  • Google Guava - https://github.com/google/guava/issues/4011
  • Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945
  • JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824

For more information

If you have any questions or comments about this advisory: * Open an issue in netty * Email us here

Original Report

Hi Netty Security Team,

I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: https://lgtm.com/query/7723301787255288599/

Netty contains three local information disclosure vulnerabilities, so far as I can tell.

One is here, where the private key for the certificate is written to a temporary file.

https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346

One is here, where the certificate is written to a temporary file.

https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371

The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable.

https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91

All of these vulnerabilities exist because File.createTempFile(String, String) will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: -rw-r--r--, thus, any other local user on that system can read the contents of that file.

Impacted OS: - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows.

Mitigation.

Moving to the Files API instead will fix this vulnerability. https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...-

This API will explicitly set the posix file permissions to something safe, by default.

I recently disclosed a similar vulnerability in JUnit 4: https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp

If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6

I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. https://github.com/netty/netty/security/advisories

This vulnerability disclosure follows Google's 90-day vulnerability disclosure policy (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first.

Cheers, Jonathan Leitschuh

Show details on source website

To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.1.59.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 4.0.0"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jboss.netty:netty"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 4.0.0"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-21290"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-378",
      "CWE-379",
      "CWE-668"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-02-08T20:07:45Z",
    "nvd_published_at": "2021-02-08T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nWhen netty\u0027s multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled.\n\nThe CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N\u0026version=3.1)\n\n### Vulnerability Details\n\nOn unix-like systems, the temporary directory is shared between all user. As such, writing to this directory using APIs that do not explicitly set the file/directory permissions can lead to information disclosure. Of note, this does not impact modern MacOS Operating Systems.\n\nThe method `File.createTempFile` on unix-like systems creates a random file, but, by default will create this file with the permissions `-rw-r--r--`. Thus, if sensitive information is written to this file, other local users can read this information.\n\nThis is the case in netty\u0027s `AbstractDiskHttpData` is vulnerable.\n\nhttps://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101\n\n`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`.\n\nYou may be affected by this vulnerability your project contains the following code patterns:\n\n```java\nchannelPipeline.addLast(new HttpPostRequestDecoder(...));\n```\n\n```java\nchannelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...));\n```\n\n### Patches\n\nThis has been patched in version `4.1.59.Final`.\n\n### Workarounds\n\nSpecify your own `java.io.tmpdir` when you start the JVM or use `DefaultHttpDataFactory.setBaseDir(...)` to set the directory to something that is only readable by the current user.\n\n### References\n\n - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html)\n - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html)\n\n### Similar Vulnerabilities\n\nSimilar, but not the same.\n\n - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp\n - Google Guava - https://github.com/google/guava/issues/4011\n - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945\n - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [netty](https://github.com/netty/netty)\n* Email us [here](mailto:netty-security@googlegroups.com)\n\n### Original Report\n\n\u003e Hi Netty Security Team,\n\u003e \n\u003e I\u0027ve been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project:\n\u003e https://lgtm.com/query/7723301787255288599/\n\u003e \n\u003e Netty contains three local information disclosure vulnerabilities, so far as I can tell.\n\u003e \n\u003e One is here, where the private key for the certificate is written to a temporary file.\n\u003e \n\u003e https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346\n\u003e \n\u003e One is here, where the certificate is written to a temporary file.\n\u003e \n\u003e https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371\n\u003e \n\u003e The final one is here, where the \u0027AbstractDiskHttpData\u0027 creates a temporary file if the getBaseDirectory() method returns null. I believe that \u0027AbstractDiskHttpData\u0027 is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable.\n\u003e \n\u003e https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91\n\u003e \n\u003e All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the \u0027java.io.tmpdir\u0027 system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file.\n\u003e \n\u003e Impacted OS:\n\u003e - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows.\n\u003e \n\u003e Mitigation.\n\u003e \n\u003e Moving to the `Files` API instead will fix this vulnerability. \n\u003e https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...-\n\u003e \n\u003e This API will explicitly set the posix file permissions to something safe, by default.\n\u003e \n\u003e I recently disclosed a similar vulnerability in JUnit 4:\n\u003e https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp\n\u003e \n\u003e If you\u0027re also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case.\n\u003e https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6\n\u003e \n\u003e I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice.\n\u003e https://github.com/netty/netty/security/advisories\n\u003e \n\u003e This vulnerability disclosure follows Google\u0027s [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I\u0027m not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first.\n\u003e \n\u003e Cheers,\n\u003e Jonathan Leitschuh",
  "id": "GHSA-5mcr-gq6c-3hq2",
  "modified": "2022-04-19T15:19:08Z",
  "published": "2021-02-08T21:17:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-5mcr-gq6c-3hq2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21290"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/commit/c735357bf29d07856ad171c6611a2e1a0e0000ec"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r7bb3cdc192e9a6f863d3ea05422f09fa1ae2b88d4663e63696ee7ef5@%3Cdev.ranger.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r9924ef9357537722b28d04c98a189750b80694a19754e5057c34ca48@%3Ccommits.pulsar.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/ra0fc2b4553dd7aaf75febb61052b7f1243ac3a180a71c01f29093013@%3Cjira.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/ra503756ced78fdc2136bd33e87cb7553028645b261b1f5c6186a121e@%3Cjira.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rb06c1e766aa45ee422e8261a8249b561784186483e8f742ea627bda4@%3Cdev.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rb51d6202ff1a773f96eaa694b7da4ad3f44922c40b3d4e1a19c2f325@%3Ccommits.pulsar.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rb592033a2462548d061a83ac9449c5ff66098751748fcd1e2d008233@%3Cissues.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rc0087125cb15b4b78e44000f841cd37fefedfda942fd7ddf3ad1b528@%3Cissues.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rc488f80094872ad925f0c73d283d4c00d32def81977438e27a3dc2bb@%3Cjira.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rcd163e421273e8dca1c71ea298dce3dd11b41d51c3a812e0394e6a5d@%3Ccommits.pulsar.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rdba4f78ac55f803893a1a2265181595e79e3aa027e2e651dfba98c18@%3Cjira.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/02/msg00016.html"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20220210-0011"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2021/dsa-4885"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com//security-alerts/cpujul2021.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuApr2021.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r0053443ce19ff125981559f8c51cf66e3ab4350f47812b8cf0733a05@%3Cdev.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r02e467123d45006a1dda20a38349e9c74c3a4b53e2e07be0939ecb3f@%3Cdev.ranger.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r0857b613604c696bf9743f0af047360baaded48b1c75cf6945a083c5@%3Cjira.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r10308b625e49d4e9491d7e079606ca0df2f0a4d828f1ad1da64ba47b@%3Cjira.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r1908a34b9cc7120e5c19968a116ddbcffea5e9deb76c2be4fa461904@%3Cdev.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r2748097ea4b774292539cf3de6e3b267fc7a88d6c8ec40f4e2e87bd4@%3Cdev.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r2936730ef0a06e724b96539bc7eacfcd3628987c16b1b99c790e7b87@%3Cissues.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r2fda4dab73097051977f2ab818f75e04fbcb15bb1003c8530eac1059@%3Cjira.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r326ec431f06eab7cb7113a7a338e59731b8d556d05258457f12bac1b@%3Cdev.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r4efed2c501681cb2e8d629da16e48d9eac429624fd4c9a8c6b8e7020@%3Cdev.tinkerpop.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r584cf871f188c406d8bd447ff4e2fd9817fca862436c064d0951a071@%3Ccommits.pulsar.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r59bac5c09f7a4179b9e2460e8f41c278aaf3b9a21cc23678eb893e41@%3Cjira.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r5bf303d7c04da78f276765da08559fdc62420f1df539b277ca31f63b@%3Cissues.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r5c701840aa2845191721e39821445e1e8c59711e71942b7796a6ec29@%3Cusers.activemq.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r5e4a540089760c8ecc2c411309d74264f1dad634ad93ad583ca16214@%3Ccommits.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r5e66e286afb5506cdfe9bbf68a323e8d09614f6d1ddc806ed0224700@%3Cjira.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r71dbb66747ff537640bb91eb0b2b24edef21ac07728097016f58b01f@%3Ccommits.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r743149dcc8db1de473e6bff0b3ddf10140a7357bc2add75f7d1fbb12@%3Cdev.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r790c2926efcd062067eb18fde2486527596d7275381cfaff2f7b3890@%3Cissues.bookkeeper.apache.org%3E"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Local Information Disclosure Vulnerability in Netty on Unix-Like systems"
}


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.