Log in
Register
Cyber Forum
More options
Toggle width
Share this page
Share this page
Share
Share
Cyber Forum
Log in
Register
More options
Toggle width
Share this page
Share this page
Share
Share
Menu
Install the app
Install
Home
CyberWeekly Podcast
Breaking News! Podcast
Cyber Risk Rating
Forums
New posts
Forum list
Trending
Leaderboards
News Feeds
Resources
Latest reviews
Sophos X-Ops Intelix
Threat Reports
Members
Current visitors
My.CompTIA
Help Documents
Preference Center
Forums
Security
Active Exploits Discussion/Recommendations
Log4j Vulnerability Information
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="Jonathan Braley" data-source="post: 2515" data-attributes="member: 77"><p><strong>All Log4j Logback Bugs We Know So Far and Why You MUST Ditch 2.15</strong></p><p><strong></strong></p><p><strong>[URL unfurl="true"]https://www.bleepingcomputer.com/news/security/all-log4j-logback-bugs-we-know-so-far-and-why-you-must-ditch-215/[/URL]</strong></p><p><strong></strong></p><p><strong><a href="https://nvd.nist.gov/vuln/detail/CVE-2021-44228" target="_blank">CVE-2021-44228</a> [Critical]</strong>: The original 'Log4Shell' or 'logjam' vulnerability is an <a href="https://cwe.mitre.org/data/definitions/502.html" target="_blank">untrusted deserialization</a> flaw. Rated critical in severity, this one scores a 10 on the <a href="https://www.first.org/cvss/" target="_blank">CVSS</a> scale and grants remote code execution (RCE) abilities to unauthenticated attackers, allowing complete system takeover.</p><p></p><p>Reported by Chen Zhaojun of Alibaba Cloud Security Team to Apache on November 24th, CVE-2021-44228 impacts the default configurations of multiple Apache frameworks, including Apache Struts2, Apache Solr, Apache Druid, Apache Flink, and others.</p><p></p><p>Being the most dangerous of them all, this vulnerability lurks in the <a href="https://search.maven.org/artifact/org.apache.logging.log4j/log4j-core" target="_blank">log4j-core</a> component, limited to 2.x versions: from 2.0-beta9 up to and including 2.14.1. A fix for Log4Shell was rolled out in version 2.15.0 but deemed incomplete (keep reading).</p><p></p><p>--</p><p></p><p><a href="https://nvd.nist.gov/vuln/detail/CVE-2021-45046" target="_blank"><strong>CVE-2021-45046</strong></a> [<strong>Critical</strong>, previously Low]: Rated low in severity, this one is a Denial of Service (DoS) flaw scoring a mere 3.7. The flaw arose as a result of an incomplete fix that went into 2.15.0 for CVE-2021-44228. While the fix applied to 2.15.0 did largely resolve the flaw, that wasn't quite the case for certain non-default configurations.</p><p></p><p>Log4j 2.15.0 makes "a best-effort attempt" to restrict JNDI LDAP lookups to <em>localhost</em> by default. But, attackers who have control over the Thread Context Map (MDC) input data can craft malicious payloads via the JNDI Lookup patterns to cause DoS attacsk. This applies to non-default configurations in which a non-default Pattern Layout using either a Context Lookup, e.g. $${ctx:loginId}, or a Thread Context Map pattern (%X, %mdc, or %MDC).</p><p></p><p>"Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default," states the NVD advisory. For those on 2.12.1 branch, a fix was backported into 2.12.2.</p><p></p><p>--</p><p></p><p><a href="https://nvd.nist.gov/vuln/detail/CVE-2021-4104" target="_blank"><strong>CVE-2021-4104</strong></a> <strong>[High]</strong>: Did we say Log4j 2.x versions were vulnerable? What about Log4j 1.x?</p><p></p><p>While previously thought to be safe, Log4Shell found a way to lurk in the older Log4j too. Essentially, non-default configuration of Log4j 1.x instances using the <em>JMSAppender </em>class also become susceptible to the untrusted deserialization flaw.</p><p></p><p>Although a less severe variant of CVE-2021-44228, nonetheless, this CVE impacts all versions of the <a href="https://search.maven.org/artifact/log4j/log4j" target="_blank">log4j:log4j</a> and <a href="https://mvnrepository.com/artifact/org.apache.log4j/log4j" target="_blank">org.apache.log4j:log4j</a> components for which only 1.x releases exist. Because these are <a href="https://logging.apache.org/log4j/1.2/" target="_blank">end-of-life</a> versions, a fix for 1.x branch does not exist anywhere, and one should upgrade to <em>log4j-core</em> 2.16.0.</p><p></p><p>--</p><p></p><p><strong><a href="https://nvd.nist.gov/vuln/detail/CVE-2021-42550" target="_blank">CVE-2021-42550</a> [Moderate]:</strong> This is a vulnerability in the Logback logging framework. A successor to the Log4j 1.x library, Logback claims to pick up "where log4j 1.x leaves off."</p><p></p><p>Up until last week, Logback also <a href="https://archive.md/QkzIy" target="_blank">bragged</a> that being "unrelated to log4j 2.x, [logback] does not share its vulnerabilities."</p><p></p><p>That assumption quickly faded when CVE-2021-4104 was discovered to impact Log4j 1.x as well, and the possibility of potential impact to Logback was <a href="https://jira.qos.ch/browse/LOGBACK-1591" target="_blank">assessed</a>. Newer Logback versions, 1.3.0-alpha11 and 1.2.9 addressing this less severe vulnerability have now been <a href="https://search.maven.org/artifact/ch.qos.logback/logback-classic" target="_blank">released</a>.</p><p></p><p>--</p><p></p><p>BleepingComputer came across multiple security researchers claiming that it is possible to achieve full-on RCE, even with 2.15.0.</p><p></p><p>"The worst possible scenario resulting from Log4j 2.15.0 is yet to be fully determined, but suffice to say, it doesn't seem like it's just limited to DoS."</p><p></p><p>"As the situation continues to evolve, organizations and developers are encouraged to upgrade to version 2.16.0, and to continue to monitor Apache's Log4j advisory page for updates."</p><p></p><p>"The action required by defenders is clear cut in all cases: moving to 2.16.0 where jndi is disabled by default is the safest course of action, and is the approach we're recommending for our customers."</p></blockquote><p></p>
[QUOTE="Jonathan Braley, post: 2515, member: 77"] [B]All Log4j Logback Bugs We Know So Far and Why You MUST Ditch 2.15 [URL unfurl="true"]https://www.bleepingcomputer.com/news/security/all-log4j-logback-bugs-we-know-so-far-and-why-you-must-ditch-215/[/URL] [URL='https://nvd.nist.gov/vuln/detail/CVE-2021-44228']CVE-2021-44228[/URL] [Critical][/B]: The original 'Log4Shell' or 'logjam' vulnerability is an [URL='https://cwe.mitre.org/data/definitions/502.html']untrusted deserialization[/URL] flaw. Rated critical in severity, this one scores a 10 on the [URL='https://www.first.org/cvss/']CVSS[/URL] scale and grants remote code execution (RCE) abilities to unauthenticated attackers, allowing complete system takeover. Reported by Chen Zhaojun of Alibaba Cloud Security Team to Apache on November 24th, CVE-2021-44228 impacts the default configurations of multiple Apache frameworks, including Apache Struts2, Apache Solr, Apache Druid, Apache Flink, and others. Being the most dangerous of them all, this vulnerability lurks in the [URL='https://search.maven.org/artifact/org.apache.logging.log4j/log4j-core']log4j-core[/URL] component, limited to 2.x versions: from 2.0-beta9 up to and including 2.14.1. A fix for Log4Shell was rolled out in version 2.15.0 but deemed incomplete (keep reading). -- [URL='https://nvd.nist.gov/vuln/detail/CVE-2021-45046'][B]CVE-2021-45046[/B][/URL] [[B]Critical[/B], previously Low]: Rated low in severity, this one is a Denial of Service (DoS) flaw scoring a mere 3.7. The flaw arose as a result of an incomplete fix that went into 2.15.0 for CVE-2021-44228. While the fix applied to 2.15.0 did largely resolve the flaw, that wasn't quite the case for certain non-default configurations. Log4j 2.15.0 makes "a best-effort attempt" to restrict JNDI LDAP lookups to [I]localhost[/I] by default. But, attackers who have control over the Thread Context Map (MDC) input data can craft malicious payloads via the JNDI Lookup patterns to cause DoS attacsk. This applies to non-default configurations in which a non-default Pattern Layout using either a Context Lookup, e.g. $${ctx:loginId}, or a Thread Context Map pattern (%X, %mdc, or %MDC). "Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default," states the NVD advisory. For those on 2.12.1 branch, a fix was backported into 2.12.2. -- [URL='https://nvd.nist.gov/vuln/detail/CVE-2021-4104'][B]CVE-2021-4104[/B][/URL] [B][High][/B]: Did we say Log4j 2.x versions were vulnerable? What about Log4j 1.x? While previously thought to be safe, Log4Shell found a way to lurk in the older Log4j too. Essentially, non-default configuration of Log4j 1.x instances using the [I]JMSAppender [/I]class also become susceptible to the untrusted deserialization flaw. Although a less severe variant of CVE-2021-44228, nonetheless, this CVE impacts all versions of the [URL='https://search.maven.org/artifact/log4j/log4j']log4j:log4j[/URL] and [URL='https://mvnrepository.com/artifact/org.apache.log4j/log4j']org.apache.log4j:log4j[/URL] components for which only 1.x releases exist. Because these are [URL='https://logging.apache.org/log4j/1.2/']end-of-life[/URL] versions, a fix for 1.x branch does not exist anywhere, and one should upgrade to [I]log4j-core[/I] 2.16.0. -- [B][URL='https://nvd.nist.gov/vuln/detail/CVE-2021-42550']CVE-2021-42550[/URL] [Moderate]:[/B] This is a vulnerability in the Logback logging framework. A successor to the Log4j 1.x library, Logback claims to pick up "where log4j 1.x leaves off." Up until last week, Logback also [URL='https://archive.md/QkzIy']bragged[/URL] that being "unrelated to log4j 2.x, [logback] does not share its vulnerabilities." That assumption quickly faded when CVE-2021-4104 was discovered to impact Log4j 1.x as well, and the possibility of potential impact to Logback was [URL='https://jira.qos.ch/browse/LOGBACK-1591']assessed[/URL]. Newer Logback versions, 1.3.0-alpha11 and 1.2.9 addressing this less severe vulnerability have now been [URL='https://search.maven.org/artifact/ch.qos.logback/logback-classic']released[/URL]. -- BleepingComputer came across multiple security researchers claiming that it is possible to achieve full-on RCE, even with 2.15.0. "The worst possible scenario resulting from Log4j 2.15.0 is yet to be fully determined, but suffice to say, it doesn't seem like it's just limited to DoS." "As the situation continues to evolve, organizations and developers are encouraged to upgrade to version 2.16.0, and to continue to monitor Apache's Log4j advisory page for updates." "The action required by defenders is clear cut in all cases: moving to 2.16.0 where jndi is disabled by default is the safest course of action, and is the approach we're recommending for our customers." [/QUOTE]
Name
Verification
Post reply
Forums
Security
Active Exploits Discussion/Recommendations
Log4j Vulnerability Information
Top
Bottom
Home
Forums
Threat Reports
My.CompTIA
Menu