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

191–200 of 209 posts

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

#191

Post by foobiekr »

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…

Suppose that even if it needs this for some kind of log transformation pipeline, there's still absolutely no reason for the jvm process in which this code is running to be able to reach out to some random internet location. Do people just not put strict segmentation in place? If so, for the love of god, why? It's not that hard and it is a very useful baseline.

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

#192

Post by foobiekr »

throwaway894345 wrote: post #48
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…

Personally I'd like to see more runtimes with some concept of capabilities. As a user, I'd like to be able to say "this package cannot make outbound calls" rather than doing so at the program or host grain via layer 3 or layer 7 firewall rules. I think maybe Deno allows this, and I wouldn't be surprised if JVM or .Net did as well. Failing that, it would be interesting to see this implemented as a linter--low level I/…

You should do it on the network _anyway_. You want multiple layers because you often find that any given layer was not as robust as you assumed.

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

#193

Post by foobiekr »

saberdancer wrote: post #126

Am I understanding this correctly. You are vulnerable if you log user input, for example especially if it is on a public facing API.

You should never be logging user input non-escaped anyway. At the very least, that creates a hazard where someone might be fooled as to the correct behavior/false-internal-systems-corroboration by logging something misleading that masquerades as a legitimate log message. It is a _huge_ hazard.

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

#194

Post by ineedasername »

benhoyt wrote: post #171
ineedasername wrote: post #104

Earlier quoted context omitted.

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

> sanitize their inputs. For anyone confused about why "sanitizing your inputs" isn't the right approach, please read (shameless self-promotion, but I think the concept is important): https://benhoyt.com/writings/dont-sanitize-do-escape/

I've pretty much always taken 'sanitize' as a catch-all for all of the things you need to do.

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

#195

Post by mjr00 »

svieira wrote: post #153
mjr00 wrote: post #52

Earlier quoted context omitted.

> I spent some time looking over the source code and cannot fathom why something that logs information would need to become this complicated. That's easy: because software development is complicated. If you look at the ticket where this was added[1], it seems like a reasonable request for something a very featureful logging library might do. Other logging frameworks[2] already supported this feature. It's easy to arm…

Yet the exact same kind of feature for Logback requires _explicit opt-in_ on the part of the application developer, via a system property (`logback.ContextSelector=JNDI`) that _must be set before Logback is first instantiated_. If you want custom behavior then you, the application developer must write extra configuration or even code in order to wire Logback into your system correctly. Logback doesn't attempt to make…

Oh yeah don't get me wrong, the implementation wasn't great. It should have been opt-in at a minimum, and in some kind of separate extension ideally. But there's been so much incredulity in these comment sections about the log4j issue, as if it were totally obvious that the feature was inherently bad and should have never been in an enterprise logging framework, which I don't think is true.

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

#196

Post by [deleted] »

foobiekr wrote: post #192
throwaway894345 wrote: post #48

Earlier quoted context omitted.

Personally I'd like to see more runtimes with some concept of capabilities. As a user, I'd like to be able to say "this package cannot make outbound calls" rather than doing so at the program or host grain via layer 3 or layer 7 firewall rules. I think maybe Deno allows this, and I wouldn't be surprised if JVM or .Net did as well. Failing that, it would be interesting to see this implemented as a linter--low level I/…

You should do it on the network _anyway_. You want multiple layers because you often find that any given layer was not as robust as you assumed.

[deleted]

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

#197

Post by throwaway894345 »

foobiekr wrote: post #192
throwaway894345 wrote: post #48

Earlier quoted context omitted.

Personally I'd like to see more runtimes with some concept of capabilities. As a user, I'd like to be able to say "this package cannot make outbound calls" rather than doing so at the program or host grain via layer 3 or layer 7 firewall rules. I think maybe Deno allows this, and I wouldn't be surprised if JVM or .Net did as well. Failing that, it would be interesting to see this implemented as a linter--low level I/…

You should do it on the network _anyway_. You want multiple layers because you often find that any given layer was not as robust as you assumed.

This doesn’t work. I often want my app to be able to talk over the network, but I want to restrict my logging library from making network calls. You can’t do this at layer 7 much less layer 3. But firewalls at those layers still obviously serve a purpose, just not this purpose.

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

#198

Post by benhoyt »

ineedasername wrote: post #194
benhoyt wrote: post #171

Earlier quoted context omitted.

> sanitize their inputs. For anyone confused about why "sanitizing your inputs" isn't the right approach, please read (shameless self-promotion, but I think the concept is important): https://benhoyt.com/writings/dont-sanitize-do-escape/

I've pretty much always taken 'sanitize' as a catch-all for all of the things you need to do.

Fair enough on that part. But it's the "their inputs" part that's just as problematic: whatever massaging you do to your "inputs", they'll always be unsafe in some contexts. You need to encode/escape your output.

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

#199

Post by detaro »

throwaway_JiY4E wrote: post #64
detaro wrote: post #56

Earlier quoted context omitted.

As I understand it that prevents the RCE, but not other variants like leaking environment variables.

> other variants like leaking environment variables. I'll google/search more about these. I assume if we say RCE is a 10 for risk, then maybe others are 5 or 3?

CORRECTION: apparently latest Java is also vulnerable: https://twitter.com/_MG_/status/1470452714203086851

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

#200

Post by fulafel »

tfehring wrote: post #144
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 e…

Only if you send just as much untrusted input there as to your DIY logging. If it's a transitive dependency that's unused or that's only used for some logging happening on calls to that library, the risk is lower.
Post reply on HN