Re: Log4Shell approaches

[Jörn Dreyer via Tech-talk <tech-talk at aps.anl.gov>]

Hi,

as far as I figured out, some of the widely used tools like css/phoebus use 
slf4j which in turn uses log4j but in an vulnerable version, so here are 
actions necesarry.

In addition the archiver appliance uses Apache Tomcat which used log4j in an 
vulnerable version. So an update to the latest version is also necesarry.

 For my part I implemented a fix for log4j not to resolve links in the 
logstring, but this is not the final solution. 

Cheers,

Jörn

Am Dienstag, 14. Dezember 2021, 07:42:16 CET schrieb Matt Clarke via Tech-
talk:
> Hi.
> 
> As far as I understand, the security issue has been fixed so updating should
> be sufficient.
 
> From the Logback page: “Fortunately, logback is unrelated to log4j 2.x and
> does not share its vulnerabilities.”
>  If I was cynical I might read that as
> “it probably has its own unique vulnerabilities which haven’t been found
> yet” ;) 
> Ultimately, like a lot of OSS, both projects seem to be maintained by a
> handful of core developers.
 
> Cheers,
> 
> Matt
> 
> 
> From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of "Shankar,
> Murali via Tech-talk" <tech-talk at aps.anl.gov>
 Reply-To: "Shankar, Murali"
> <mshankar at slac.stanford.edu>
> Date: Monday, 13 December 2021 at 18:58
> To: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
> Subject: Log4Shell approaches
> 
> We were wondering if others had any recommendations on this. That is, should
> we continue using/migrating to log4j2 ( and hope the security issues are
> fixed ) or should we consider alternatives like logback etc. Any thoughts
> are appreciated.
 
> Regards,
> Murali
>