natas_hw
/
slf4j
mirror of https://github.com/qos-ch/slf4j
0
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

doc fixes 

Signed-off-by: Ceki Gulcu <ceki@qos.ch>
This commit is contained in:
Ceki Gulcu 2021-12-14 17:17:33 +01:00
parent 53a9833a3c
commit 2a9bcb15e0
3 changed files with 99 additions and 70 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

162
slf4j-site/src/site/pages/log4shell.html
View File

@ -32,7 +32,7 @@
<h3>Preamble</h3>
<p>The JNDI/LDAP/RMI/X serialization rabbit hole goes deep and
<p>The JNDI/LDAP/RMI/X serialization rabbit hole runs deep and
leads to much uncertainty. <b>Thus, the contents of this page
are the result of our current knowledge and are provided AS IS
without warranty of any kind.</b></p>
@ -69,7 +69,7 @@
CVE-2021-44228. </p>
<p>Given that log4j version 1.x is still very widely deployed,
perhaps 10 times more than log4j 2.x, we have been receiving a
perhaps 10 times more widely than log4j 2.x, we have been receiving a
steady stream of questions regarding the vulnerability of log4j
version 1.x.
</p>
@ -80,12 +80,46 @@
<p>However, log4j 1.x comes with <code>JMSAppender</code> which
will perform a JNDI lookup if enabled in log4j's configuration
file, i.e. <em>log4j.properties</em> or
<em>log4j.xml</em>. Thus, an attacker who has write access to an
application's log4j configuration file can perform an RCE attack
whenever log4j 1.x reads a corrupt/malicious configuration
file. More on this <a href="#concreteMeasures"> below</a>.</p>
file, i.e. <em>log4j.properties</em> or <em>log4j.xml</em>.</p>
<p>An attacker who ALREADY has write access the log4j
configuration file will need to add <code>JMSAppender</code>
into the configuration poisoned with malicious connection
parameters. Note that prior legitimate usage of
<code>JMSAppender</code> is irrelevant to the ability of the
attacker to mount a successful attack. </p>
<p>Also note that poisoning the configuration file is not
enough. The attacker also needs to force log4j to reload its
configuration file with the poisoned parameters. Given that
log4j 1.x does not offer automatic reloading, the poisoned
configuratin file will typically only become effectve at
application restart.</p>
<p>Nevertheless, while not easy, such an attack is
feasible. Thus it makes sense to make job of the attacker harder
by removing <code>JMSAppender</code> altogether from
<em>log4j-1.2.17.jar</em>.</p>
<p>In the absence of a new log4j 1.x release, you can remove
<code>JMSAppender</code> from the <em>log4j-1.2.17.jar</em>
artifact yourself. Here is the command:</p>
<pre> zip -d log4j-1.2.17.jar org/apache/log4j/net/JMSAppender.class</pre>
<p>If you do not have access to 'zip', you can also use the
'jar' command.</p>
<pre> #assuming log4j-1.2.17.jar exists in current directory
mkdir tmp
cd tmp
jar xvf ../log4j-1.2.17.jar
rm org/apache/log4j/net/JMSAppender.class
jar cvf ../log4j-1.2.17-patched.jar .</pre>
<p>It goes without saying that once <em>log4j-1.2.17.jar</em> is
patched, you would need to deploy it.</p>
<h3>How about the SLF4J API?</h3>
<p>The SLF4J API is just an API which lets message data go
@ -93,93 +127,87 @@
mitigate the vulnerability.
</p>
<p>However, as mentioned previously, log4j 1.x is safe with
respect to CVE-2021-44228. Thus, if your SLF4J provider/binding
is <em>slf4j-logj12.jar</em>, you are safe regarding
<p>However, as mentioned already, log4j 1.x is safe with respect
to CVE-2021-44228. Thus, if your SLF4J provider/binding is
<em>slf4j-logj12.jar</em>, you are safe regarding
CVE-2021-44228.</p>
<p>If you are using <em>log4j-over-slf4j.jar</em> with SLF4J
API, you are safe unless the underlying implementation is log4j
2.x.</p>
<p>If you are using <em>log4j-over-slf4j.jar</em> in conjections
with the SLF4J API, you are safe unless the underlying
implementation is log4j 2.x.</p>
<h3>Does a similar vulnerability exist in logback?</h3>
<p>Logback does <span class="big green">NOT</span> offer a
lookup mechanism at the message level. Thus, it is deemed safe
with respect to CVE-2021-44228. However, we are still looking at
other possible vulnerabilities of <a span="big green">lesser</a>
severity. Indeed, the JNDI/RMI/LDAP serialization
vulnerabilities are a true minefield. </p>
with respect to CVE-2021-44228.</p>
<h3 class="doAnchor" name="concreteMeasures">Concrete protective
<p>However, logback may make JNDI calls from within its
configuration file. This was <a
href="https://github.com/cn-panda/logbackRceDemo">recently
reported</a> as a vulnerability of <span class="big
green">lesser</span> severity. In response, we have released
logback version 1.2.8. Please upgrade.
</p>
<p>Note that the vulnerability affecting logback requires write
access to logback's configuration file as a prerequisite. To
escalate to a succesful Remote Code Execution attack, ALL of the
following conditions have to be met:
</p>
<ol>
<li>attacker has write access to logback.xml</li>
<li>use of logback version older than 1.2.8</li>
<li>loading of poisoned configuration data, which implies
application restart or scan="true" set prior to attack</li>
</ol>
<p>As a belt-and-suspenders type of precaution, in addition to
upgrading to logback version 1.2.8, we also recommend users to
deploy their logback configuration files as read-only.</p>
<h3 class="doAnchor" name="concreteMeasures">Additional protective
measure: write protect log4j{1,2}/logback configuration
files</h3>
<p>While there are obviously differences between JNDI/LDAP/RMI
serialization attacks, from an abstract point of view, they are
all related to serialization, the gift that never seems to stop
giving.</p>
all related to serialization, the gift that keeps giving.</p>
<p>At this point, we hope that you appreciate the distinction
between serialization attacks where the injection of malicious
input is performed at the level of 1) log message data 2)
configuration file. The point of injection matters, a lot. If
you understand the difference, please read on.</p>
between serialization attacks where malicious input is injected
via "log message data" versus a "configuration file". The point of
injection matters a lot. The former attack point requires no
privilege whereas the latter requires significant prior
privilege. If you understand the difference, please read on.</p>
<p>While log4j 1.x is old, it is still very extensible. So are
logback and log4j 2.x. </p>
<p>What if there exist other vulnerable extension points, in any
of the aforementioned logging frameworks, that we do not know
about? Do you think you can enumerate these weak points by
searching a CVE database?</p>
<p></p>
<p>Trying to harden <code>JMSAppender</code> in log4j 1.x or
some other component in log4j 2.x or logback against
serialization injection seems like a half-measure. If you are
fond of analogies, it is a bit like trying to empty a bathtub
with a leaky faucet armed only with a spoon.
</p>
serialization injections (via configuration files) will be a
long and ardous task. Moreover, we think you should err on the
side of caution by assuming that there will remain hidden
vulnerabilities.</p>
<p class="highlight">We recommend that you err on the side of
caution by deploying configuration files with read-only
permissions.</p>
<p>Therefore, in addition to hardening KNOWN vulnerable
components in aforementioned frameworks, we also recommend that
configuration files be protected against write access. In
Unix-speak they should be read-only for all users, including the
components, we also recommend that configuration files be
protected against write access. In Unix-speak they should have
read-only permissions for all users, including the
<code>owner</code>. If possible, they should also be monitored
against changes and unauthorized manipulation.</p>
<p>If you have read this far, you might also get an "Aha but
wait!" moment related to serialization attacks but having
nothing to do with logging.</p>
<h3>Is there a bigger lesson?</h3>
<p>CVE-2021-44228 involves a cascade of failures in various
components, of which only one is actually located in log4j
2.x. Indeed, it takes only a moment of inattention to
unwittingly create a vulnerability. However, vulnerabilities may
arise even when you follow best practices.
</p>
<p>Thus, while keeping up with the latest patches is a good
practice, it is probably just as important to invest resources
so that your organization is capable of understanding the actual
root causes of vulnerabilities and avoid them in the first
place. </p>
<p>Another question is the reaction speed. Once a vulnerability
is detected, can your organization fix a vulnerability quickly?
On this front, log4j 2.x developers deserve credit for their
quick response.
</p>
<h3>Conclusion</h3>
<p>CVE-2021-44228 became public knowledge in 2021-12-10, about
48 hours ago. It raises a number of very tough questions which
are not necessarily related to logging. As mentioned at the top
of this page, the JNDI serialization rabbit hole goes deep and
leads to much uncertainty. We are still investigating.</p>
<h3>Further reading</h3>

3
slf4j-site/src/site/pages/mailing-lists.html
View File

@ -11,7 +11,8 @@
<script type="text/javascript">prefix='';</script>
<script type="text/javascript" src="js/jquery-min.js"></script>
<div id="content">
<div id="container">
<script src="templates/header.js" type="text/javascript"></script>
<div id="left">
<script src="templates/left.js" type="text/javascript"></script>

4
slf4j-site/src/site/pages/templates/left.js
View File

@ -14,7 +14,7 @@ document.write(' <a href="https://github.com/qos-ch/slf4j">Source Repository<
document.write(' <a href="http://www.qos.ch/shop/products/professionalSupport">Support offerings</a>');
document.write(' <p class="menu_header">Native implementations</p>');
document.write(' <a href="http://logback.qos.ch/">Logback</a>');
document.write(' <a href="https://logback.qos.ch/">Logback</a>');
document.write(' <p class="menu_header">Wrapped implementations</p>');
document.write(' <a href="api/org/slf4j/impl/JDK14LoggerAdapter.html">JDK14</a>');
@ -29,7 +29,7 @@ document.write('</div>');
document.write('<p>&nbsp;</p>');
document.write('<div class="pub">');
document.write(' <a href="http://twitter.com/qos_ch" style="">');
document.write(' <a href="https://twitter.com/qos_ch" style="">');
document.write(' <img alt="Follow @qos_ch" src="images/follow_us.png" />');
document.write(' </a>');
document.write('</div>');