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

Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

techsolvency.com

Post reply on HN
Print view View original

111–120 of 209 posts

Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

#111

Post by matwood »

winternett wrote: post #11
mateuszf wrote: post #5

Earlier quoted context omitted.

Yeah - for example to determine if log4j is used in a maven project one would have to run "mvn dependency:tree | grep log4j". Which I did today for our 60 microservices. And also for projects deployed as war files - container server libraries also have to be checked.

Also found this link today - https://support.lucidworks.com/hc/en-us/articles/44156492440... I'm glad I couldn't get SOLR to work on indexing PDFs for a client project last year and I chose an alternate solution after reading it today...

I mitigated our SOLR install over the weekend. Best I could tell it wasn't logging queries by default so I couldn't get it to trigger. Adding an extra JVM arg to the opt list is a pretty standard SOLR thing to do, so I already have automated ways to update and push out configuration changes.

Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

#112

Post by rodgerd »

ThinkBeat wrote: post #19

Ideally, log4j should not have the ability to make "outgoing calls" right? It has been years since I used it but I can't remember a valid reason why it should be allowed to do so. Since it is running inside the stack it may not be easy to enforce it. If the "client" log4j does it before even logging that is a bother. It seems like having a "central" "syslog" logging server. Traffic goes from the stack -> logging serv…

> Ideally, log4j should not have the ability to make "outgoing calls" right?

If it's in the application execution context, it will have the same abilities.

If your middleware needs to make calls to third-parties, and it uses log4j, the log4j code has the same rights as the middleware app.

If you're using a registry like Nexus, and it uses log4j, then it also has the ability to make calls to Maven repos, pypi repos, and anything else that Nexus can reach.

And so on and so forth.

Essentially you're expecting there to be privilege separation, where there is none.

Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

#113

Post by rot25 »

ridaj wrote: post #62

I'm curious about the disclosure of this vulnerability and why it seems that no prior notice appears to have been given by the researcher who published it. Is it because it was already being exploited in the wild?

Vulnerability researcher here. This vulnerability was patch-gapped before it was disclosed.

When the patch went out 9 days ago [1], many vulnerability researchers were able to look at it and identify the root cause within minutes. Exploits started going out over a week ago before it was publicly disclosed and the CVE was released. Good security orgs that can hire skilled vulnerability researchers started patching on December 6th/7th/8th. All the chaos started on December 9th when people started leaking the poc on twitter.

The same thing happens to google chrome when they release a patch for a security vulnerability. Very skilled researchers can produce a POC and exploit given the patch alone [2]

[1] https://github.com/apache/logging-log4j2/commit/d82b47c

[2] https://blog.exodusintel.com/2019/09/09/patch-gapping-chrome...

Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

#114

Post by mro_name »

bob1029 wrote: post #66

I have taken some flak over the years for rolling my own basics like logging, telemetry, tracing, authentication, session management, etc... Incidents like this remind me that it is sometimes OK to ignore those who constantly order you to "vendor it out" over some notion of principled development excellence wherein one never reinvents a single hypothetical wheel. Arguably, writing text to a log file on disk is a simp…

you're advocating diversity against monoculture. Only nature has muse enough for such.

Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

#115

Post by mypalmike »

ineedasername wrote: post #104
hpoe wrote: post #70

Earlier quoted context omitted.

Given many of the engineers i have worked with and much more importantly the PMs and Managers that work over them, I would expect vulnerabilities like this to proliferate all over the place if people were to roll their own logging and telematry and especially authentication. I mean SQL injection is such an easy known mitigation yet is still on the OWASP top 10 even after so many years.

Yes, people still forget to ; delete from comments where id = 29544262 */-- sanitize their inputs. ...still there?

The humor here is that sanitizing inputs is not the proper mitigation.

Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

#116

Post by mro_name »

hpoe wrote: post #70
bob1029 wrote: post #66

I have taken some flak over the years for rolling my own basics like logging, telemetry, tracing, authentication, session management, etc... Incidents like this remind me that it is sometimes OK to ignore those who constantly order you to "vendor it out" over some notion of principled development excellence wherein one never reinvents a single hypothetical wheel. Arguably, writing text to a log file on disk is a simp…

Given many of the engineers i have worked with and much more importantly the PMs and Managers that work over them, I would expect vulnerabilities like this to proliferate all over the place if people were to roll their own logging and telematry and especially authentication. I mean SQL injection is such an easy known mitigation yet is still on the OWASP top 10 even after so many years.

it's all about system boundaries. Would you have arbitrary racoons in your closet?

Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

#117

Post by jl6 »

bob1029 wrote: post #66

I have taken some flak over the years for rolling my own basics like logging, telemetry, tracing, authentication, session management, etc... Incidents like this remind me that it is sometimes OK to ignore those who constantly order you to "vendor it out" over some notion of principled development excellence wherein one never reinvents a single hypothetical wheel. Arguably, writing text to a log file on disk is a simp…

Well it sure does suck to find out that you have a RCE vulnerability in your application thanks to a dependency, but I’m not sure that means it was wrong to decide to use Log4j based on the information available at the time. Having to rewrite a bunch of library code in-house is a significant burden, without a guarantee you’ll get it any more right than the Log4j developers did.

I don’t think this event is sufficiently bad to overturn the principle that code reuse is a good thing.

The better lesson is to learn how to contain the behaviour of your dependencies so you don’t end up with ridiculous situations like backend database servers being permitted to make JNDI calls to the public internet.

Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

#118

Post by mro_name »

mypalmike wrote: post #115
ineedasername wrote: post #104

Earlier quoted context omitted.

Yes, people still forget to ; delete from comments where id = 29544262 */-- sanitize their inputs. ...still there?

The humor here is that sanitizing inputs is not the proper mitigation.

but? It think it's far deeper than mitigation, it's the solution.

Edit: I apologize for getting 'sanitation' wrong. Don't do it.

Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

#119

Post by ridaj »

rot25 wrote: post #113
ridaj wrote: post #62

I'm curious about the disclosure of this vulnerability and why it seems that no prior notice appears to have been given by the researcher who published it. Is it because it was already being exploited in the wild?

Vulnerability researcher here. This vulnerability was patch-gapped before it was disclosed. When the patch went out 9 days ago [1], many vulnerability researchers were able to look at it and identify the root cause within minutes. Exploits started going out over a week ago before it was publicly disclosed and the CVE was released. Good security orgs that can hire skilled vulnerability researchers started patching on…

Thanks, that explains things. I guess I was confused by it being called here and there a "zero-day" - if it's the patch that triggered exploitation, then at least it was already fixed at head by the time it got exploited.

Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

#120

Post by layer8 »

staticassertion wrote: post #98
layer8 wrote: post #86

Earlier quoted context omitted.

Not really, because log4j now restricts JNDI-LDAP queries to localhost by default, or to an explicitly configured list of hosts. An attacker would have to have access to the application configuration or start script.

No, you are still vulnerable, even with just what we know today and we're still finding more ways to break this library. 1. Attackers can still load code in your class path. 2. Attackers can steal environment variables, VM information, system information, etc. 3. The issue isn't specific to LDAP in any way, that was just a particularly brutal way to exploit this vulnerability. There are other ways to achieve RCE. We…

As far as log4j is concerned, the substitutions ("lookups" — this includes your #2) are now disabled by default, and can only be enabled by an attacker if he already has access to the application. I’m not sure what you’re referring to in #1 and #3, given that fix.
Post reply on HN