Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Log4j 2.15.0 – Previously suggested mitigations may not be enough

isc.sans.edu

Post reply on HN
Print view View original

11–20 of 103 posts

Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough

#11

Post by mol4711 »

unbanned wrote: post #5
_old_dude_ wrote: post #4

Earlier quoted context omitted.

More realistically, this code is 20 years old, several generations of maintainers worked on it, accumulating patches over patches over patches and nobody wanted to be the guy that say No / we should remove that feature. You can see the discussions on HN about Gnome removing features as a good example about how hard it is.

No it isn't 20yo. This feature is about 5

This JNDI "feature" is 8 years old. It was merged in 2013 from what I have seen, and has been defended by some as an "useful" feature. It has been known since at least BlackHat 2016 presentation that this is an incredibly dangerous and stupid thing to keep.

cricket noises nobody reacted until now when minecraft servers got hacked.

Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough

#12

Post by oblio »

stickfigure wrote: post #8

I must confess to feeling that the reach of this CVE is a bit oversold. Yes, it's a terrible RCE and a major catastrophe for anyone using log4j. But log4j hasn't been the popular choice for logging implementations in a long time. Libraries typically use facades like slf4j or commons-logging, so the risk of pulling in an active log4j implementation transitively is pretty small. Your application/appserver either logs w…

He he, an optimist.

log4j is in widespread use, directly or indirectly.

Most people don't give a crap about the exact Java logging library, the only places that actually care are those that bike shed, since functionally Java logging stuff is generally quite robust and full featured.

The worst part about my previous phrase is that the places that don't care about the Java logging library frequently don't do security audits, so prepare for a ton of exploits and data leaks in the following months and years.

Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough

#13

Post by theevilsharpie »

stickfigure wrote: post #8

I must confess to feeling that the reach of this CVE is a bit oversold. Yes, it's a terrible RCE and a major catastrophe for anyone using log4j. But log4j hasn't been the popular choice for logging implementations in a long time. Libraries typically use facades like slf4j or commons-logging, so the risk of pulling in an active log4j implementation transitively is pretty small. Your application/appserver either logs w…

> You shouldn't need to pour over code to figure it out.

It's not just your code that is vulnerable.

Our in-house software doesn't use log4j, but a number of third-party components we use do and needed to be patched.

Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough

#14

Post by js8 »

mol4711 wrote: post #11
unbanned wrote: post #5

Earlier quoted context omitted.

No it isn't 20yo. This feature is about 5

This JNDI "feature" is 8 years old. It was merged in 2013 from what I have seen, and has been defended by some as an "useful" feature. It has been known since at least BlackHat 2016 presentation that this is an incredibly dangerous and stupid thing to keep. cricket noises nobody reacted until now when minecraft servers got hacked.

> nobody reacted until now when minecraft servers got hacked

That shows which part of the IT industry is really needed.. :-)

Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough

#15

Post by smarx007 »

stickfigure wrote: post #8

I must confess to feeling that the reach of this CVE is a bit oversold. Yes, it's a terrible RCE and a major catastrophe for anyone using log4j. But log4j hasn't been the popular choice for logging implementations in a long time. Libraries typically use facades like slf4j or commons-logging, so the risk of pulling in an active log4j implementation transitively is pretty small. Your application/appserver either logs w…

For the record, both SLF4J and commons-logging as logging frontends allow log4j to be used as a logging backend.

Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough

#16

Post by alenmilk »

stickfigure wrote: post #8

I must confess to feeling that the reach of this CVE is a bit oversold. Yes, it's a terrible RCE and a major catastrophe for anyone using log4j. But log4j hasn't been the popular choice for logging implementations in a long time. Libraries typically use facades like slf4j or commons-logging, so the risk of pulling in an active log4j implementation transitively is pretty small. Your application/appserver either logs w…

I have ported a Spring Boot application from log4j to logback and it was pretty easy since we used slf4j. The code was the same, the only thing I had to do is to convert the logging configuration. The features mapped one to one and it to some fidgeting to make it work, but all in all it was pretty straight forward. Would recommend.

Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough

#17

Post by alexbakker »

stickfigure wrote: post #8

I must confess to feeling that the reach of this CVE is a bit oversold. Yes, it's a terrible RCE and a major catastrophe for anyone using log4j. But log4j hasn't been the popular choice for logging implementations in a long time. Libraries typically use facades like slf4j or commons-logging, so the risk of pulling in an active log4j implementation transitively is pretty small. Your application/appserver either logs w…

I can't say I'm feeling the same. Still lots of people testing over at https://log4shell.tools almost a week after this vulnerability became widely known. Plenty of people still discovering they're vulnerable as well. I think it's likely that these are just the people who know they're using log4j. If you're running a black box product from some vendor you'll have no clue you're vulnerable until it's too late.

Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough

#18

Post by raesene9 »

stickfigure wrote: post #8

I must confess to feeling that the reach of this CVE is a bit oversold. Yes, it's a terrible RCE and a major catastrophe for anyone using log4j. But log4j hasn't been the popular choice for logging implementations in a long time. Libraries typically use facades like slf4j or commons-logging, so the risk of pulling in an active log4j implementation transitively is pretty small. Your application/appserver either logs w…

The major risk here probably isn't in-house developed code but versions of log4j used in a vast array of packaged software and systems.

https://github.com/cisagov/log4j-affected-db <-- that's a (probably incomplete) list of possibly affected vendors and applications, and in many cases the vendor can't even say yet whether they're vulnerable.

Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough

#20

Post by zootm »

stickfigure wrote: post #8

I must confess to feeling that the reach of this CVE is a bit oversold. Yes, it's a terrible RCE and a major catastrophe for anyone using log4j. But log4j hasn't been the popular choice for logging implementations in a long time. Libraries typically use facades like slf4j or commons-logging, so the risk of pulling in an active log4j implementation transitively is pretty small. Your application/appserver either logs w…

Using logging facades means that libraries don't need to update -- which is great -- but libraries were never directly vulnerable anyway. log4j is, to my knowledge, still by far the most common actual implementation of logging in the Java ecosystem. The assertion that it's not popular for logging only holds if you assume that logging facades are logging implementations, which they are not.

My completely-unverified guess would be that there are more people immune to this issue because they never migrated past log4j 1.x than there are who are immune because they picked up Logback or something similar.

> You shouldn't need to pour over code to figure it out.

This is true but as sibling comments have pointed out, a lot of other software you might be deploying without having written or configured the logging for are written in Java.

Post reply on HN