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

91–100 of 531 posts

Re: Log4j RCE Found

#91

Post by physicles »

jimrandomh wrote: post #64

I try to follow a rule with libraries: if a library causes more trouble than the implementation effort it would take to recreate its functionality from scratch (or rather, the portion of its funcitonality that is used in practice), then it's time to purge that library from projects and never use it again. The part of log4j functionality that gets used in practice, most of the time, is just a wrapper around printf whi…

For containers that's especially true because the best practice is just to write to stdout/stderr. This sidesteps a whole host of issues related to dealing with log files.

Re: Log4j RCE Found

#92

Post by nick__m »

nick__m wrote: post #23
xyst wrote: post #16

This should be something that static code analyzers should pick up. If a dependency log4j dependency is Just in time to ruin all of the reports project managers present to executives

the vulnerable feature is not in log4j see https://github.com/apache/logging-log4j2/pull/608#issuecomme... and you can just delete the affected class

please ignore my comment on the version, agwa is right, update the library or delete the vulnerable class.

Re: Log4j RCE Found

#93

Post by shawnz »

ianlevesque wrote: post #46
spuz wrote: post #31

Thanks for the write-up but I have a few questions. Why does log4j's .log() method attempt to parse the strings sent to it? It is the last thing I would expect it to do. Is the part in the sample code where the user's input is output back to them part of the exploit? If so how does it fit into the attack? What will the attacker see beyond the string they originally sent as input? Could you update your mitigation step…

The method that they're exploiting is akin to printf("whoops this is a format string"). The right way to handle user input in one of these is log.error("here's my user-provided input: {}", userInput) rather than log.error(userInput)

What if you are using SLF4J as a front-end to log4j, does it escape these special strings before passing them to the logging system?

Re: Log4j RCE Found

#94

Post by cesarb »

agwa wrote: post #66
nick__m wrote: post #23

Earlier quoted context omitted.

the vulnerable feature is not in log4j see https://github.com/apache/logging-log4j2/pull/608#issuecomme... and you can just delete the affected class

> the vulnerable feature is not in log4j The comment you cited is referring to the option to disable the vulnerable feature, not the vulnerable feature itself. Per https://github.com/apache/logging-log4j2/pull/608#issuecomme... even log4j 1.x is vulnerable.

What I understood from that comment is that log4j 1.x is only vulnerable if you use the JMS Appender, which is probably not the most common configuration.

Re: Log4j RCE Found

#95

Post by keyle »

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?

So if you have a null pointer exception or something similar in production, you want to send that information to a remote host or alert system to be looked at urgently.

Re: Log4j RCE Found

#96

Post by maxdamantus »

spuz wrote: post #31

Thanks for the write-up but I have a few questions. Why does log4j's .log() method attempt to parse the strings sent to it? It is the last thing I would expect it to do. Is the part in the sample code where the user's input is output back to them part of the exploit? If so how does it fit into the attack? What will the attacker see beyond the string they originally sent as input? Could you update your mitigation step…

The string that is vulnerable is actually not meant to be user input, but a formatting string.

EDIT: nevermind, the issue apparently arises outside of formatting strings—though it would have been nice if the example had demonstrated this.

The issue occurs in incorrect logging code such as:

> logger.info("Data: " + data);

But the correct way of logging the above data is:

> logger.info("Data: {}", data);

It's analogous to using something like the following in C:

> printf(data);

In the incorrect cases (log4j or C), the user input is being used as a format string, and the user can likely cause an RCE. This is an issue in C for reasons that should be obvious. Java has historically been used very reflectively, so whenever there's some expression interpreter or deserialiser involved, there's a good chance it could be RCEd with arbitrary input.

Re: Log4j RCE Found

#97

Post by oasisbob »

nostoc wrote: post #85
jimrandomh wrote: post #64

I try to follow a rule with libraries: if a library causes more trouble than the implementation effort it would take to recreate its functionality from scratch (or rather, the portion of its funcitonality that is used in practice), then it's time to purge that library from projects and never use it again. The part of log4j functionality that gets used in practice, most of the time, is just a wrapper around printf whi…

> just a wrapper around printf which adds a timestamp and a log-level That's a pretty naive view of what's needed in an enterprise logging solution. logging to files, separate logging, remote logging, log rotation, logging 3rd party code... Of course if you're simply sending lines to the terminal in a simple program you don't need log4j. But once you scale, you'd be spending 3 weeks implementing what you get for free…

Log4j configuration isn't free either. Ask anyone who has ever been woken up by an asinine log rotation bug. (The tailer broke, or the rotation didn't happen... again, etc)

Playing application log janitor is miserable. Just ship the logs and be done with it.

Re: Log4j RCE Found

#98

Post by mjr00 »

jimrandomh wrote: post #64

I try to follow a rule with libraries: if a library causes more trouble than the implementation effort it would take to recreate its functionality from scratch (or rather, the portion of its funcitonality that is used in practice), then it's time to purge that library from projects and never use it again. The part of log4j functionality that gets used in practice, most of the time, is just a wrapper around printf whi…

> The part of log4j functionality that gets used in practice, most of the time, is just a wrapper around printf which adds a timestamp and a log-level.

I... don't think this is true? When I was using it we used log rotation, log truncation, configurable output formatting that could be made consistent across the code or specialized in certain parts of the code base that required more detailed logging, masking credit card numbers and emails in log statements, and doing all of the logging async to not impact performance. And I'm sure there are features it has which I didn't mention.

Re: Log4j RCE Found

#99

Post by natanbc »

ianlevesque wrote: post #46
spuz wrote: post #31

Thanks for the write-up but I have a few questions. Why does log4j's .log() method attempt to parse the strings sent to it? It is the last thing I would expect it to do. Is the part in the sample code where the user's input is output back to them part of the exploit? If so how does it fit into the attack? What will the attacker see beyond the string they originally sent as input? Could you update your mitigation step…

The method that they're exploiting is akin to printf("whoops this is a format string"). The right way to handle user input in one of these is log.error("here's my user-provided input: {}", userInput) rather than log.error(userInput)

The RCE works with both ways, start nc (nc -lp 1234) and run this

    org.apache.logging.log4j.LogManager.getLogger("whatever").error("not safe {}", "${jndi:ldap://127.0.0.1:1234/abc}")

Re: Log4j RCE Found

#100

Post by koenigdavidmj »

maxdamantus wrote: post #96
spuz wrote: post #31

Thanks for the write-up but I have a few questions. Why does log4j's .log() method attempt to parse the strings sent to it? It is the last thing I would expect it to do. Is the part in the sample code where the user's input is output back to them part of the exploit? If so how does it fit into the attack? What will the attacker see beyond the string they originally sent as input? Could you update your mitigation step…

The string that is vulnerable is actually not meant to be user input, but a formatting string. EDIT: nevermind, the issue apparently arises outside of formatting strings—though it would have been nice if the example had demonstrated this. The issue occurs in incorrect logging code such as: > logger.info("Data: " + data); But the correct way of logging the above data is: > logger.info("Data: {}", data); It's analogous…

It was a few months ago, but if I recall correctly, there were two overrides for info (and the other equivalent methods). info(String, String...) would do {} expansion like you mentioned, but info(String) would log the string directly, not doing format expansion on it.

I'm not sure how this interacts with the RCE issue reported here.

EDIT: That's because I was thinking of Slf4j, which has additional smarts here.

Post reply on HN