<story><title>Log4j: The pain just keeps going</title><url>https://thenewstack.io/log4j-the-pain-just-keeps-going-and-going/</url></story><parent_chain><item><author>jacobyoder</author><text>Had to deal with some automated scan tool telling a client &amp;quot;you have log4j - you&amp;#x27;re vulnerable!&amp;quot; when... we didn&amp;#x27;t.  A project was including a dependency on SLF4J and &lt;i&gt;that&lt;/i&gt; project pulled in slf4j-log4j (IIRC).  But it was not configured, wasn&amp;#x27;t compiled in to the final jar, and ... even it was, it was &lt;i&gt;very old&lt;/i&gt; log4j (1.1 or 1.2 IIRC?).  The vulnerability didn&amp;#x27;t affect that older version.&lt;p&gt;We had to spend a week back and forth with&lt;p&gt;&amp;quot;no, we&amp;#x27;re not vulnerable&amp;quot;.&lt;p&gt;&amp;quot;But we see log4j is right there in the a file in the directory&amp;quot;.&lt;p&gt;&amp;quot;No, it&amp;#x27;s not vulnerable and it&amp;#x27;s not being used and we can&amp;#x27;t reasonably fork the entire dependency just to remove that one sub-dependency from our project&amp;#x27;s dependency&amp;quot;&lt;p&gt;&amp;quot;But we see log4j is right there in the a file in the directory&amp;quot;.&lt;p&gt;Also, there was no budget to do any sort of rewrite&amp;#x2F;refactor&amp;#x2F;etc anyway.</text></item></parent_chain><comment><author>dspillett</author><text>&lt;i&gt;&amp;gt; We had to spend a week back and forth with&lt;/i&gt;&lt;p&gt;We&amp;#x27;ve had similar out of a pen test that noted we were using nginx for some of our internal dashboards&amp;#x2F;tools and the version running (1.18 IIRC) was officially EOLed upstream so a high security issue.&lt;p&gt;They initially wouldn&amp;#x27;t listen to the argument that we use stable&amp;#x2F;LTS Debian&amp;#x2F;Ubuntu release only, and those hold functionality stable (which is one of the key reasons to use them) and backport security updates where relevant. We pointed them at the package changelogs and they were convinced that there was still a vulnerability not patched but for some reason didn&amp;#x27;t want to tell us which, when we finally got that out of them it turned out to be one that was introduced in a later version so was never relevant in the first place for the one the stable repositories included.&lt;p&gt;You would think a penetration testing company would have a clue about something so common…</text></comment>
<story><title>Log4j: The pain just keeps going</title><url>https://thenewstack.io/log4j-the-pain-just-keeps-going-and-going/</url></story><parent_chain><item><author>jacobyoder</author><text>Had to deal with some automated scan tool telling a client &amp;quot;you have log4j - you&amp;#x27;re vulnerable!&amp;quot; when... we didn&amp;#x27;t.  A project was including a dependency on SLF4J and &lt;i&gt;that&lt;/i&gt; project pulled in slf4j-log4j (IIRC).  But it was not configured, wasn&amp;#x27;t compiled in to the final jar, and ... even it was, it was &lt;i&gt;very old&lt;/i&gt; log4j (1.1 or 1.2 IIRC?).  The vulnerability didn&amp;#x27;t affect that older version.&lt;p&gt;We had to spend a week back and forth with&lt;p&gt;&amp;quot;no, we&amp;#x27;re not vulnerable&amp;quot;.&lt;p&gt;&amp;quot;But we see log4j is right there in the a file in the directory&amp;quot;.&lt;p&gt;&amp;quot;No, it&amp;#x27;s not vulnerable and it&amp;#x27;s not being used and we can&amp;#x27;t reasonably fork the entire dependency just to remove that one sub-dependency from our project&amp;#x27;s dependency&amp;quot;&lt;p&gt;&amp;quot;But we see log4j is right there in the a file in the directory&amp;quot;.&lt;p&gt;Also, there was no budget to do any sort of rewrite&amp;#x2F;refactor&amp;#x2F;etc anyway.</text></item></parent_chain><comment><author>Nursie</author><text>Been in similar situations, it is not fun.&lt;p&gt;&amp;quot;You have a vulnerable version of netty&amp;quot;&lt;p&gt;&amp;quot;No, we don&amp;#x27;t, that&amp;#x27;s a false positive&amp;quot;&lt;p&gt;&amp;quot;No see, the tool says you need netty 4.x and that&amp;#x27;s version 1.x, you need to update&amp;quot;&lt;p&gt;&amp;quot;OK, but the tool is wrong, it&amp;#x27;s just picking up anything with &amp;#x27;netty&amp;#x27; in the name, and that component is a wrapper around netty for some other thing, it only goes up to 1.8&amp;quot;&lt;p&gt;&amp;quot;You have to update it to 4.x, this is a vulnerability&amp;quot;&lt;p&gt;&amp;quot;Do you understand this isn&amp;#x27;t part of the thing you&amp;#x27;re concerned about&amp;quot;&lt;p&gt;&amp;quot;I am only concerned about shipping a product without vulnerabilities&amp;quot;&lt;p&gt;&amp;quot;Well this isn&amp;#x27;t one, because it&amp;#x27;s a false positive, here&amp;#x27;s the CVE, here&amp;#x27;s what it applies to, here&amp;#x27;s the link to this package on maven central, it&amp;#x27;s not part of netty, back off&amp;quot;&lt;p&gt;&amp;quot;But it&amp;#x27;s insecure, the tool says so&amp;quot;&lt;p&gt;We went round and round for about 3 hours until I told the guy (an infosec &amp;#x27;pro&amp;#x27;) to leave me alone until he&amp;#x27;d figured out how to do his job... he came back to me the next morning for another 3 hour slack argument along the exact same lines at which point I told him to leave me alone permanently and communicate through management if he had anything to say. I&amp;#x27;m not massively impressed with infosec as a profession after a few similar encounters.</text></comment>