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

Log4j RCE Found

lunasec.io

Post reply on HN
Print view View original

171–180 of 531 posts

Re: Log4j RCE Found

#171

Post by arpa »

shepherdjerred wrote: post #124
TheDong wrote: post #116

Earlier quoted context omitted.

> Terminals are run as root all the time Is it really common to run terminals as root? I can't remember the last time I did. Sure, I open a terminal as my user, and then run 'sudo bash' to get a shell as root, but the terminal is still running as my user. Were you meaning something else?

I did a lot when I younger and didn't realize that it was a bad practice.

I've been on Linux since 2000s and still maintain the view that real men log in as root on tty1. It's ironman mode, and pure joy of *nix as it was meant to be experienced. You filthy casual. /s

Re: Log4j RCE Found

#172

Post by fomine3 »

garydgregory wrote: post #43
plasma wrote: post #30

Earlier quoted context omitted.

I see a GitHub Advisory being made at https://github.com/advisories/GHSA-jfh8-c2jp-5v3q

The CVE is being crafted as I write this...

It seems that CVE had already created at 11/26. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4422...

Re: Log4j RCE Found

#173

Post by wielebny »

wielebny wrote: post #145

This is exploitable in applications that use Elastic Stack with logstash as a log processor. I've just been able to reproduce it in an Magento ecommerce with payload inserted into payments details.

Worth noting: possible only because log line was malformed and logstash complained about it through log4j.

Re: Log4j RCE Found

#174

Post by znep »

IiydAbITMvJkqKf wrote: post #165
janstice wrote: post #158

From a quick look at the lunasec page, it looks we can mitigate by blocking outbound LDAP traffic to unknown destinations?

If you want to go down the route, you should check if log4j allows a port to be specified in the LDAP URI. If it does, firewalling one port won't do anything.

Yes, you can specify a port.

Re: Log4j RCE Found

#175

Post by brabel »

lewisjoe wrote: post #163

To folks wondering what the issue is about, I'll give a short summary that I myself needed. Typically a logging library has one job to do: swallow the string as if it's some black box and spit it elsewhere as per provided configurations. Log4j though, doesn't treat strings as black boxes. It inspects its contents and checks if it contains any "variables" that need to be resolved before spitting out. Now there's a bun…

These "special" strings that Log4j parse must be in the formatting string though, right?

External Strings should normally be logged as parameters, not included in the format String. For example:

    // this is ok
    log.debug("user-agent={}", userAgent);

    // this is bad
    log.debug("user-agent=" + userAgent);
Does this vulnerability still work on the first case?

EDIT: the answer is yes, just tried it myself.

Re: Log4j RCE Found

#176

Post by erk__ »

brabel wrote: post #175
lewisjoe wrote: post #163

To folks wondering what the issue is about, I'll give a short summary that I myself needed. Typically a logging library has one job to do: swallow the string as if it's some black box and spit it elsewhere as per provided configurations. Log4j though, doesn't treat strings as black boxes. It inspects its contents and checks if it contains any "variables" that need to be resolved before spitting out. Now there's a bun…

These "special" strings that Log4j parse must be in the formatting string though, right? External Strings should normally be logged as parameters, not included in the format String. For example: // this is ok log.debug("user-agent={}", userAgent); // this is bad log.debug("user-agent=" + userAgent); Does this vulnerability still work on the first case? EDIT: the answer is yes, just tried it myself.

According to a comment here it does https://news.ycombinator.com/item?id=29506397

Re: Log4j RCE Found

#177

Post by teitoklien »

shepherdjerred wrote: post #147
asddubs wrote: post #131

Earlier quoted context omitted.

Seems like you're disagreeing on the basis of personal development rather than whether it makes sense for any given project. I think at that point it depends on whether you're primarily coding to learn or to make software

By the same token why would you roll your own instead of using a tried and true library that any experienced Java developer already knows?

You’re practically right, But if your team isn't constantly changing then running your custom solution for at-least more simpler things like logging is better.

Because otherwise you have to depend on skills of a third party library maintainer you have no communication with or contract agreement with, to protect his/her codebase from getting security backdoors, which other malicious actors will constantly try to inject it with, if the library is known to be used by various large enterprises.

Coding with third party libraries is about trust, for simpler functions and packages its usually worth it long term to code it in-house. It’s easier to maintain, only comes with features you need and you’re always aware of what capabilities your code has.

I’m everyday impressed how relatively less npm with node, etc get hacked, considering they use additional third-party libraries for 4 liner functions too.

Re: Log4j RCE Found

#178

Post by jsavin »

janstice wrote: post #158

From a quick look at the lunasec page, it looks we can mitigate by blocking outbound LDAP traffic to unknown destinations?

The vulnerability affects any process with network-facing endpoints that log user-input data. It's not LDAP-specific.

Re: Log4j RCE Found

#179

Post by cjcampbell »

garydgregory wrote: post #42
Fabricio20 wrote: post #6

Earlier quoted context omitted.

Yes, more specifically after Java 8u191 you need to flag the client with: -Dcom.sun.jndi.ldap.object.trustURLCodebase=true -Dcom.sun.jndi.rmi.object.trustURLCodebase=true While RCE is not possible without these flags, you will still get pingback, in minecraft's example, allowing you to get the IP of everyone connected.

Oracle says this is in 8u121, not 8u191: https://www.oracle.com/java/technologies/javase/8u121-relnot...

8u121 seems to address the RMI vector but not LDAP (per https://www.veracode.com/blog/research/exploiting-jndi-injec...).

Re: Log4j RCE Found

#180

Post by numpad0 »

testplzignore wrote: post #20

I don't get what the point of this feature even is. What is a legitimate reason for a logging library to make network requests based on the contents of what is being logged? And is this enabled out-of-the-box with log4j2?

I think this hilarious surprise from "network is the computer" principle and "it just so happens to go through xyz" transparency is just awesome.
Post reply on HN