From c3871569a659c7344d12c5d59b1568c34ca4d69e Mon Sep 17 00:00:00 2001 From: breadchris Date: Sun, 19 Dec 2021 01:17:08 -0500 Subject: [PATCH 1/2] update guidance to use 2.17.0 --- docs/blog/2021-12-09-log4j-zero-day.mdx | 5 ++++- ...-12-12-log4j-zero-day-mitigation-guide.mdx | 20 ++++++++++++------- 2 files changed, 17 insertions(+), 8 deletions(-) diff --git a/docs/blog/2021-12-09-log4j-zero-day.mdx b/docs/blog/2021-12-09-log4j-zero-day.mdx index 7f09e4a08..3a3bc3ffd 100644 --- a/docs/blog/2021-12-09-log4j-zero-day.mdx +++ b/docs/blog/2021-12-09-log4j-zero-day.mdx @@ -101,7 +101,9 @@ Almost all versions of log4j version 2 are affected. :::caution Limited vulnerability in `2.15.0` As of Tuesday, Dec 14, version `2.15.0` was found to still have a possible [vulnerability in some apps](https://lists.apache.org/thread/83y7dx5xvn3h5290q1twn16tltolv88f). -We recommend updating to `2.16.0` which [disables](https://github.com/apache/logging-log4j2/commit/44569090f1cf1e92c711fb96dfd18cd7dccc72ea) JNDI and [completely removes](https://github.com/apache/logging-log4j2/pull/623) `%m{lookups}`. +~We recommend updating to `2.16.0` which [disables](https://github.com/apache/logging-log4j2/commit/44569090f1cf1e92c711fb96dfd18cd7dccc72ea) JNDI and [completely removes](https://github.com/apache/logging-log4j2/pull/623) `%m{lookups}`.~ +We recommend updating to `2.17.0` which includes the fixes introduced in `2.16.0` as well as a fix for a [discovered denial +of service (DOS) attack](https://logging.apache.org/log4j/2.x/security.html). ::: ### log4j v1 @@ -296,6 +298,7 @@ methods are still prevalent. 15. Updated contact information. 16. Updated original twitter link from @P0rZ9 as the original tweet was deleted. Changed from `https://twitter.com/P0rZ9/status/1468949890571337731` to `https://web.archive.org/web/20211209230040/https://twitter.com/P0rZ9/status/1468949890571337731` 17. Added links to other blog posts. +18. Update post to include latest version 2.17.0 release. ### Editing this post diff --git a/docs/blog/2021-12-12-log4j-zero-day-mitigation-guide.mdx b/docs/blog/2021-12-12-log4j-zero-day-mitigation-guide.mdx index 170d03fcc..a97f67567 100644 --- a/docs/blog/2021-12-12-log4j-zero-day-mitigation-guide.mdx +++ b/docs/blog/2021-12-12-log4j-zero-day-mitigation-guide.mdx @@ -196,11 +196,13 @@ cd lunasec/tools/log4shell-jar-scripts ### Checking Package Version If you can check what versions of log4j2 are being used, you can check for any below the recently published -`2.16.0`. +`2.17.0`. :::caution Limited vulnerability in `2.15.0` As of Tuesday, Dec 14, version `2.15.0` was found to still have a possible [vulnerability in some apps](https://logging.apache.org/log4j/2.x/security.html). -We recommend updating to `2.16.0` which removes the message lookup feature entirely. +~We recommend updating to `2.16.0` which removes the message lookup feature entirely.~ +We recommend updating to `2.17.0` which includes the fixes introduced in `2.16.0` as well as a fix for a [discovered denial +of service (DOS) attack](https://logging.apache.org/log4j/2.x/security.html). ::: #### log4j v2 @@ -214,9 +216,9 @@ still possibly vulnerable on `2.15.0`. #### log4j v1 -Version 1 of log4j is vulnerable to other RCE attacks (like +Version 1 of log4j is vulnerable to other RCE attacks (like [CVE-2019-17571](https://www.cvedetails.com/cve/CVE-2019-17571/)), and if you're using it you need to -[migrate](https://logging.apache.org/log4j/2.x/manual/migration.html) to `2.16.0`. +[migrate](https://logging.apache.org/log4j/2.x/manual/migration.html) to `2.17.0`. ### Checking Vendor Software Versions The above scanning tool might not work for vendor's packages because of obfuscation, and in any case, you'll likely need @@ -245,9 +247,9 @@ visualization of the Log4Shell exploit. Take note of the possible solutions (sh -### Option 1: Upgrading to 2.16.0 +### Option 1: Upgrading to 2.17.0 -Apache log4j has released a version that fixes the Log4Shell vulnerability as of version `2.16.0`. This version disables JNDI by +Apache log4j has released a version that fixes the Log4Shell vulnerability as of version `2.17.0`. This version disables JNDI by default and removes the message lookup feature. **[Apache log4j Download Page](https://logging.apache.org/log4j/2.x/download.html)** @@ -259,6 +261,10 @@ Log4j version `2.15.0` which was previously thought to be secure has been found that could result in a DOS (but not RCE), users must update to `2.16.0`. ::: +:::caution Version 2.16.0 vulnerable to DOS +If you have updated Log4j to version `2.16.0`, a Denial of Service (DOS) attack is still present in [certain logging circumstances](https://logging.apache.org/log4j/2.x/security.html). +::: + ### Option 2: Enable `formatMsgNoLookups` :::warning This flag does not prevent all vulnerabilities As of Dec 14, it's been found that this flag is ineffective at stopping RCE in some situations, @@ -266,7 +272,7 @@ explained here [by log4j](https://logging.apache.org/log4j/2.x/security.html) an [CVE-2021-45046](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046). We found the CVE wording confusing and are still investigating this vulnerability. -You must update to `2.16.0` or use the JNDI patches below. +You must update to `2.17.0` or use the JNDI patches below. ::: The above release of log4j hardcodes the `formatMsgNoLookups` flag to true, ~~preventing the attack~~. If you are using log4j version `2.10.0` to version `2.14.0` and can't yet update, you can still set the flag manually. From b02cd4fc3541ab628c59d4627961d49737e7e821 Mon Sep 17 00:00:00 2001 From: Free Wortley Date: Sun, 19 Dec 2021 17:41:01 -0600 Subject: [PATCH 2/2] Update guidance across all posts --- docs/blog/2021-12-09-log4j-zero-day.mdx | 20 ++++++++++--------- ...-12-12-log4j-zero-day-mitigation-guide.mdx | 17 +++++++++------- ...og4j-zero-day-update-on-CVE-2021-45046.mdx | 15 ++++++++------ docs/blog/2021-12-15-log4shell-live-patch.mdx | 9 ++++++--- ...2021-12-17-log4j-update-increased-cvss.mdx | 9 ++++++--- docs/blog/2021-12-18-open-source-patching.mdx | 4 ++-- 6 files changed, 44 insertions(+), 30 deletions(-) diff --git a/docs/blog/2021-12-09-log4j-zero-day.mdx b/docs/blog/2021-12-09-log4j-zero-day.mdx index 3a3bc3ffd..cff58cbd2 100644 --- a/docs/blog/2021-12-09-log4j-zero-day.mdx +++ b/docs/blog/2021-12-09-log4j-zero-day.mdx @@ -3,7 +3,7 @@ title: "Log4Shell: RCE 0-day exploit found in log4j 2, a popular Java logging pa description: Given how ubiquitous log4j is, the impact of this vulnerability is quite severe. Learn how to patch it, why it's bad, and more in this post. slug: log4j-zero-day image: https://www.lunasec.io/docs/img/log4shell-logo.png -date: 2021-12-12 +date: 2021-12-19 keywords: [log4shell, log4j, log4j2, rce, java, zero-day] authors: - name: Free Wortley @@ -37,6 +37,8 @@ authors: ![Log4Shell Logo](https://www.lunasec.io/docs/img/log4shell-logo.png) +_Originally Posted @ December 9th & Last Updated @ December 19th, 3:37pm PST_ + **Fixing Log4Shell? See Our [Updated Mitigation Guide](https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide) including our automated scanning tool** @@ -57,8 +59,6 @@ This post provides resources to help you understand the vulnerability and how to -_Originally Posted @ December 9th & Last Updated @ December 14th, 10:48pm PST_ - _This blog post is also available at https://log4shell.com/_ @@ -99,22 +99,24 @@ Almost all versions of log4j version 2 are affected. `2.0-beta9 <= Apache log4j <= 2.14.1` -:::caution Limited vulnerability in `2.15.0` -As of Tuesday, Dec 14, version `2.15.0` was found to still have a possible [vulnerability in some apps](https://lists.apache.org/thread/83y7dx5xvn3h5290q1twn16tltolv88f). -~We recommend updating to `2.16.0` which [disables](https://github.com/apache/logging-log4j2/commit/44569090f1cf1e92c711fb96dfd18cd7dccc72ea) JNDI and [completely removes](https://github.com/apache/logging-log4j2/pull/623) `%m{lookups}`.~ +:::caution Limited vulnerabilities found in `2.15.0` and `2.16.0` +As of Tuesday, Dec 14, version `2.15.0` was found to still have a possible [vulnerability in some apps](https://lists.apache.org/thread/83y7dx5xvn3h5290q1twn16tltolv88f). And, a few days later, a DOS vulnerability was found in `2.16.0` too. + +~~We recommend updating to `2.16.0` which [disables](https://github.com/apache/logging-log4j2/commit/44569090f1cf1e92c711fb96dfd18cd7dccc72ea) JNDI and [completely removes](https://github.com/apache/logging-log4j2/pull/623) `%m{lookups}`.~~ (Updated: See below) + We recommend updating to `2.17.0` which includes the fixes introduced in `2.16.0` as well as a fix for a [discovered denial of service (DOS) attack](https://logging.apache.org/log4j/2.x/security.html). ::: ### log4j v1 Version 1 of log4j is vulnerable to other RCE attacks, and if you're using it you need to -[migrate](https://logging.apache.org/log4j/2.x/manual/migration.html) to `2.16.0`. +[migrate](https://logging.apache.org/log4j/2.x/manual/migration.html) to `2.17.0`. ## Permanent Mitigation **For Current Information:** We have written a comprehensive guide on [log4j mitigation strategies](https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide). -Version 2.16.0 of log4j has been released without the vulnerability. log4j-core.jar is available on Maven Central [here](https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.16.0/), with [[release notes](https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0)] and +Version `2.17.0` of log4j has been released without the RCE or DOS vulnerabilities. `log4j-core.jar` is available on Maven Central [here](https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.17.0/), with [[release notes](https://logging.apache.org/log4j/2.x/changes-report.html#a2.17.0)] and [[log4j security announcements](https://logging.apache.org/log4j/2.x/security.html)]. The release can also be downloaded from the Apache Log4j [Download](https://logging.apache.org/log4j/2.x/download.html) page. @@ -126,7 +128,7 @@ The release can also be downloaded from the Apache Log4j [Download](https://logg :::warning `formatMsgNoLookups` Does not protect against all attacks As of Tuesday, Dec 14, it's been found that this flag is ineffective at stopping certain attacks, partially explained [CVE-2021-45046](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046). -You must update to `2.16.0` or use the JNDI patches for temporary mitigation explained in [our mitigation guide](https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide/). +You must update to `2.17.0` or use the JNDI patches for temporary mitigation explained in [our mitigation guide](https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide/). ::: As per [this discussion on HackerNews](https://news.ycombinator.com/item?id=29507263): diff --git a/docs/blog/2021-12-12-log4j-zero-day-mitigation-guide.mdx b/docs/blog/2021-12-12-log4j-zero-day-mitigation-guide.mdx index a97f67567..da80cd5fa 100644 --- a/docs/blog/2021-12-12-log4j-zero-day-mitigation-guide.mdx +++ b/docs/blog/2021-12-12-log4j-zero-day-mitigation-guide.mdx @@ -2,7 +2,7 @@ title: "Guide: How To Detect and Mitigate the Log4Shell Vulnerability (CVE-2021-44228 & CVE-2021-45046)" description: If you're using log4j 2 in your infrastructure, this guide will help you understand how to check if you're impacted and show you how to quickly and securely mitigate the issue. slug: log4j-zero-day-mitigation-guide -date: 2021-12-13 +date: 2021-12-19 image: https://www.lunasec.io/docs/img/log4shell-logo.png keywords: [log4shell, log4j, log4j2, rce, java, zero-day, mitigation] authors: @@ -37,6 +37,8 @@ authors: ![Log4Shell Logo](https://www.lunasec.io/docs/img/log4shell-logo.png) +_Originally Posted @ December 12th & Last Updated @ December 19th, 3:37pm PST_ + **Also read: Our analysis of [CVE-2021-45046](https://www.lunasec.io/docs/blog/log4j-zero-day-update-on-cve-2021-45046) (a second log4j vulnerability)** A few days ago, a serious new vulnerability was identified in Apache log4j v2 and published as @@ -54,8 +56,6 @@ earlier blog post](https://www.lunasec.io/docs/blog/log4j-zero-day/). ::: -_Originally Posted @ December 12th & Last Updated @ December 14th, 10:48pm PST_ - ## Be careful what Log4Shell advice you trust online Because of the severe impact from this vulnerability, there has been a lot of discussion on the internet @@ -200,7 +200,9 @@ If you can check what versions of log4j2 are being used, you can check for any b :::caution Limited vulnerability in `2.15.0` As of Tuesday, Dec 14, version `2.15.0` was found to still have a possible [vulnerability in some apps](https://logging.apache.org/log4j/2.x/security.html). -~We recommend updating to `2.16.0` which removes the message lookup feature entirely.~ + +~~We recommend updating to `2.16.0` which removes the message lookup feature entirely.~~ (Updated, see below) + We recommend updating to `2.17.0` which includes the fixes introduced in `2.16.0` as well as a fix for a [discovered denial of service (DOS) attack](https://logging.apache.org/log4j/2.x/security.html). ::: @@ -258,7 +260,7 @@ We recommend you upgrade, if possible. For most people, this is the final and c :::caution Version 2.15.0 still may be vulnerable Log4j version `2.15.0` which was previously thought to be secure has been found to still have a [limited vulnerability](https://lists.apache.org/thread/83y7dx5xvn3h5290q1twn16tltolv88f), -that could result in a DOS (but not RCE), users must update to `2.16.0`. +that could result in a DOS (but not RCE), users must update to `>= 2.16.0`. ::: :::caution Version 2.16.0 vulnerable to DOS @@ -274,7 +276,7 @@ are still investigating this vulnerability. You must update to `2.17.0` or use the JNDI patches below. ::: -The above release of log4j hardcodes the `formatMsgNoLookups` flag to true, ~~preventing the attack~~. If you are using log4j +The above release of log4j sets the `formatMsgNoLookups` flag to true by default, ~~preventing the attack~~. If you are using log4j version `2.10.0` to version `2.14.0` and can't yet update, you can still set the flag manually. Set `formatMsgNoLookups=true` when you configure log4j by performing one of the following: @@ -401,7 +403,7 @@ _This only applies to log4j versions `>= 2.7.0`, older versions don't support it In addition to the below issues with this strategy, this mitigation may be bypassed in certain scenarios and still allows for RCE (see [our dedicated post](https://www.lunasec.io/docs/blog/log4j-zero-day-update-on-cve-2021-45046) about it), and this has been entirely [removed](https://logging.apache.org/log4j/2.x/manual/layouts.html#PatternMethod) -in log4j 2.16.0 and newer. +in log4j `2.16.0` and newer. ::: Some people online are suggesting updating your logging statements from `%m` to `%m{nolookupzz}` to mitigate this**. @@ -499,3 +501,4 @@ If you would like to contribute, or notice any errors, this post is an Open Sour 7. Added info about hot patching, and links to new releases. 8. Update info about patching strategies. 9. Added links to other blog posts. +10. Updated info about 2.16.0 CVE telling users to upgrade to 2.17.0 now diff --git a/docs/blog/2021-12-14-log4j-zero-day-update-on-CVE-2021-45046.mdx b/docs/blog/2021-12-14-log4j-zero-day-update-on-CVE-2021-45046.mdx index a34be89a8..c5d8a18b9 100644 --- a/docs/blog/2021-12-14-log4j-zero-day-update-on-CVE-2021-45046.mdx +++ b/docs/blog/2021-12-14-log4j-zero-day-update-on-CVE-2021-45046.mdx @@ -2,7 +2,7 @@ title: "Log4Shell Update: Second log4j Vulnerability Published (CVE-2021-44228 + CVE-2021-45046)" description: A quick update on the situation now that a new log4j CVE has been created and patched in 2.16.0. We've done research and these are our findings. slug: log4j-zero-day-update-on-cve-2021-45046 -date: 2021-12-14 +date: 2021-12-19 image: https://www.lunasec.io/docs/img/log4shell-logo.png keywords: [log4shell, log4j, log4j2, rce, java, zero-day, mitigation] authors: @@ -37,6 +37,8 @@ authors: ![Log4Shell Logo](https://www.lunasec.io/docs/img/log4shell-logo.png) +_Originally Posted @ December 14th & Last Updated @ December 19th, 3:37pm PST_ + **Just trying to fix this? Please read our dedicated [Mitigation Guide](https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide).** @@ -60,7 +62,7 @@ from `3.7 -> 9.0`. We found that the DOS outlined in the CVE was not actually impactful because it did not consume resources during our testing (see [below](#notes-on-the-denial-of-service-in-2.15.0)). -We could still be wrong through, so we continue to recommend that you upgrade to `2.16.0` in the event that a better +We could still be wrong through, so we continue to recommend that you upgrade to `2.17.0` in the event that a better exploit is found to abuse this attack vector. ::: @@ -69,9 +71,9 @@ exploit is found to abuse this attack vector. ## The new CVE is difficult to understand The mention of possible RCE is unfortunately missing from the published CVE. In the CVE -it only mentions a possible "Denial-of-Service" attack for versions prior to `2.15.0`. +it only mentions a possible "Denial-of-Service" attack for versions prior to `2.15.0` and `2.16.0`. -Because of these findings, we recommend that everybody using log4j immediately upgrades to `2.16.0` or later, or manually +Because of these findings, we recommend that everybody using log4j immediately upgrades to `2.17.0` or later, or manually patches their log4j classes (for details, see our [Mitigation Guide](https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide)). Please read the rest of this post for context about our research. @@ -203,7 +205,7 @@ denial of service (DOS) possible under certain circumstances. See the below scre However, in our testing we did not find this DOS to be resource consuming as it seemed that the infinite loop created by recursively resolving `${ctx:apiversion}` was identified by the program and errored out. -Log4j `2.16.0` completely mitigates this issue by `removing support for message lookup patterns and disabling JNDI functionality by default`. +Log4j `2.16.0` completely mitigates this issue by `removing support for message lookup patterns and disabling JNDI functionality by default`. (Note: Please use `2.17.0` or newer though to mitigate other security issues in `2.16.0`) ## Stay Updated @@ -242,4 +244,5 @@ If you would like to contribute, or notice any errors, this post is an Open Sour 1. Updated 12/15/21: Updated "Conditions for the Vulnerability" section from "upgrade to `2.16.0`" to "upgrade to `>= 2.15.0`", see [this GitHub issue](https://github.com/lunasec-io/lunasec/issues/316) 2. Updated 12/15/21: Updated all instances of `noFormatMsgLookup` to be the correct `formatMsgNoLookups`, see [this GitHub issue](https://github.com/lunasec-io/lunasec/issues/317) 3. Updated 12/16/21: Added links to other blog posts. -3. Updated 12/18/21: Updated note about 2.15.0 that RCE has been found. +4. Updated 12/18/21: Updated note about 2.15.0 that RCE has been found. +5. Updated 12/19/21: Updated advice about 2.16.0 to recommend 2.17.0 now. diff --git a/docs/blog/2021-12-15-log4shell-live-patch.mdx b/docs/blog/2021-12-15-log4shell-live-patch.mdx index 84242931b..063c1c7f7 100644 --- a/docs/blog/2021-12-15-log4shell-live-patch.mdx +++ b/docs/blog/2021-12-15-log4shell-live-patch.mdx @@ -2,7 +2,7 @@ title: "How to Automatically Mitigate Log4Shell via a Live Patch (CVE-2021-44228 + CVE-2021-45046)" description: By simply sending a string to your servers, you can temporarily patch the Log4Shell vulnerability. slug: log4shell-live-patch -date: 2021-12-15 +date: 2021-12-19 image: https://www.lunasec.io/docs/img/log4shell-logo.png keywords: [log4shell, log4j, log4j2, rce, java, zero-day, mitigation] authors: @@ -35,6 +35,8 @@ authors: ~ --> +_Originally Posted @ December 15th & Last Updated @ December 19th, 3:37pm PST_ + **TL;DR:** This string will temporarily fix your systems by patching them against Log4Shell, but *please* read the rest of this post before you use it! **Update:** We [posted a follow-up post](https://www.lunasec.io/docs/blog/log4shell-live-patch-technical) with a technical deep-dive @@ -187,8 +189,8 @@ with us about it. We have extensively written about [steps for mitigating Log4Shell](https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide), and we encourage you to refer to these steps as you work to address this vulnerability. We strongly urge you and -your team to work towards updating your Log4j versions to `2.16.0` as you are able to (even if you've migrated to -`2.15.0` already). +your team to work towards updating your Log4j versions to ~~2.16.0~~ `2.17.0` as you are able to even if you've migrated to +`2.15.0` or `2.16.0` already. (Update: log4j `2.16.0` has a DOS vulnerability with its own third security advisory.) If you do find yourself stuck in Dependency or Vendor hell though, you can always try to use the [Live Patch](#an-unconventional-silver-lining) @@ -231,3 +233,4 @@ If you would like to contribute, or notice any errors, this post is an Open Sour ::: 1. Added links to other blog posts. +2. Updated info to reference new 2.17.0 DOS CVE diff --git a/docs/blog/2021-12-17-log4j-update-increased-cvss.mdx b/docs/blog/2021-12-17-log4j-update-increased-cvss.mdx index 89b5930ee..a7a56ce76 100644 --- a/docs/blog/2021-12-17-log4j-update-increased-cvss.mdx +++ b/docs/blog/2021-12-17-log4j-update-increased-cvss.mdx @@ -2,7 +2,7 @@ title: "Log4Shell Update: Severity Upgraded 3.7 -> 9.0 for Second log4j Vulnerability (CVE-2021-45046)" description: The second Log4j vulnerability was upgraded from a CVSS score of 3.7x (limited DOS) to a CVSS score of 9.7 (limited RCE), and we explain the impact. slug: log4j-zero-day-severity-of-cve-2021-45046-increased -date: 2021-12-17 +date: 2021-12-19 image: https://www.lunasec.io/docs/img/log4shell-keeps-coming.png keywords: [log4shell, log4j, log4j2, rce, java, zero-day, mitigation] authors: @@ -39,6 +39,8 @@ authors: _The logo gets worse as the situation gets worse..._ +_Originally Posted @ December 17th & Last Updated @ December 19th, 3:37pm PST_ + Earlier today, the second Log4j vulnerability (CVE-2021-45046) was upgraded from a [CVSS score of 3.7](https://web.archive.org/web/20211215180723/https://logging.apache.org/log4j/2.x/security.html) (limited DOS) to a [CVSS score of 9.0](https://logging.apache.org/log4j/2.x/security.html) (limited RCE). Note: the reported limited RCE has only been proven to be exploitable on macOS at the moment. We expect, in time, that other operating systems @@ -126,8 +128,8 @@ The most impactful way to exploit this vulnerability was to have `String attacke which would result in a recursive reference in the lookup. With the reported bypass of the restrictive remote connection list, a full RCE is possible in the above code as we can access `attacker.com` now. -It is strongly recommended that you update to 2.16.0, even if you have previously updated to 2.15.0, to mitigate these -new bypasses. +It is strongly recommended that you update to ~~2.16.0~~ 2.17.0 (Updated 12/19), even if you have previously updated to 2.15.0 or 2.16.0, to mitigate these +new bypasses. (Updated 12/19 due to new DOS found in 2.16.0. Please upgrade to 2.17.0 to mitigate issues in previous versions.) ## Update: The localhost Bypass was Discovered! @@ -190,3 +192,4 @@ If you would like to contribute, or notice any errors, this post is an Open Sour ### Edits 1. Added a note that the RCE has only been provably exploitable on macOS +2. 12/19/21: Updated info about 2.17.0 release due to CVE. diff --git a/docs/blog/2021-12-18-open-source-patching.mdx b/docs/blog/2021-12-18-open-source-patching.mdx index 78b7b3003..76c5b2f02 100644 --- a/docs/blog/2021-12-18-open-source-patching.mdx +++ b/docs/blog/2021-12-18-open-source-patching.mdx @@ -129,7 +129,7 @@ CI won't run in this fork which means you will need to be careful and test local As the maintainer, it's also your responsibility to request a CVE. GitHub is a CVE Numbering Authority, meaning you can create a CVE through them. [Request a CVE](https://docs.github.com/en/code-security/security-advisories/about-github-security-advisories#cve-identification-numbers) from the Security Advisory you created above. Being a part of the process helps make sure the CVE is accurate and not confusing -and miscategorized like some of the log4j CVEs. +or mis-categorized like some log4j CVEs were. Ideally, a security person will be brought into this private process to audit the change, if you can get one. Side note: We are considering founding a non-profit to give projects this help, and if that's something you'd like to see please [let us know](https://docs.google.com/forms/d/e/1FAIpQLSd1yaB-3ob4yNnHBDzmFvrnl0VyViT234kpdcvadX-9G2M3eQ/viewform?usp=sf_link). @@ -174,7 +174,7 @@ It might not be a bad idea to link to this blog post or the resources below if y Maybe if that had happened with log4j, it would have been handled differently. ## Other resources -* Github's guide on [coordinated disclosure](https://docs.github.com/en/code-security/security-advisories/about-coordinated-disclosure-of-security-vulnerabilities) +* GitHub's guide on [coordinated disclosure](https://docs.github.com/en/code-security/security-advisories/about-coordinated-disclosure-of-security-vulnerabilities) * Google has compiled a very good but little-known [comprehensive guide](https://github.com/google/oss-vulnerability-guide) on dealing with exactly these situations. Big thank you to them for publishing this. * OpenSSF has a [Vulnerability Disclosures Working Group](https://github.com/ossf/wg-vulnerability-disclosures) that works to improve vulnerability disclosures in Open Source Software.