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

101–110 of 531 posts

Re: Log4j RCE Found

#101

Post by shepherdjerred »

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…

I disagree strongly with this.

You're better off learning the de-facto libraries of your language. Your employer, or any production application you're going to work on is probably going to use one of these libraries.

I learned the most common Java libraries when writing personal projects -- Lombok, log4j, Guava, Gson, Jackson, Netty, etc.

I had a significantly gentler learning curve at my first job. We used these common libraries, so I had a very easy time when I had to edit log filtering or fix log rotations of our applications.

Re: Log4j RCE Found

#102

Post by [deleted] »

agwa wrote: post #68
pqyzwbq wrote: post #65

Do anyone know if I depends on the following 2: - org.apache.logging.log4j:log4j-api - org.apache.logging.log4j:log4j-to-slf4j But without dependency on - org.apache.logging.log4j:log4j-core in this situation, is this safe from this RCE? Thanks. Edit, This may affect both log4j 2.x and log4j 1.x (see comments bellow, thanks.)

> By the way. This only affect log4j 2.x ( https://github.com/apache/logging-log4j2 ). the log4j 1.x ( https://github.com/apache/log4j ) is not affected. That's not what https://github.com/apache/logging-log4j2/pull/608#issuecomme... says

[deleted]

Re: Log4j RCE Found

#103

Post by dsrw »

dylan604 wrote: post #54
a-dub wrote: post #50

so the question is, is it safe to log unsanitized inputs? i've argued no given the complexity of today's logging pipelines and caught a lot of flak for it in the past... now i feel vindicated.

Why would you ever trust user provided input? Like seriously, ever? I don't trust my own input. I tend to copy&paste, and I've messed up from pasting something that was previously in the clipboard because I didn't actually hit the right keyboard shortcut when I was copying the data I thought I was. I wasn't even attempting to be malicious, but I accidentally tried a SQL Inject attack on myself because of it. DON'T EV…

I agree, but certain operations need to safely accept untrusted input if I'm going to handle input at all. Running a regex on user input doesn't mean I trust the input. It means I trust my regex engine. I should be able to trust my logger the same way.

Re: Log4j RCE Found

#104

Post by freeqaz »

dang wrote: post #79
freeqaz wrote: post #26

Here's a write up on the exploit and how to patch it. We just wrote this up and posted it a few minutes ago (before this was even on HN, lol). https://www.lunasec.io/docs/blog/log4j-zero-day/

Ok, I think we can change the URL to that from the submitted URL ( https://github.com/apache/logging-log4j2/pull/608 ), which doesn't provide much (any?) context for understanding what's being fixed there.

Thanks, dang!

Re: Log4j RCE Found

#105

Post by a-dub »

a-dub wrote: post #89
peterkelly wrote: post #82

Earlier quoted context omitted.

In a properly designed system, it should be perfectly safe. The problems come from how the log input is processed. If all you're doing is appending it to a file or adding a row to a database table, that should be no problem. In the database case it's no different to adding any other record supplied by the user. In the case of a file, consideration has to be given about what assumptions other tools that process that f…

imagine you're using stackdriver: how many thousands or millions of lines of code will those log messages touch before they're rendered in browser for someone with sysadmin privileges? how many libraries are just in the web front end they're using?

moreover imagine debugging at any point in that pipeline. i've seen approaches where it's just sanitized at render... what happens when a dev dumps the database, hits it with a cli tool or peeks a queue?

Re: Log4j RCE Found

#106

Post by maxdamantus »

koenigdavidmj wrote: post #100
maxdamantus wrote: post #96

Earlier quoted context omitted.

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.

I'm not aware of that feature, but I guess it would mitigate this issue, since the problematic code:

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

would effectively turn into something safe:

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

And the issue would only arise if someone mixes the two patterns:

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

Overall, I don't like the sound of that feature, since it blurs the line between correct and incorrect use of the logging API. The first argument should always be a constant formatting string.

Re: Log4j RCE Found

#107

Post by natanbc »

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…

I posted this in reply to a sibling comment, but the "correct" way is still vulnerable

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

#108

Post by nightpool »

freeqaz wrote: post #26

Here's a write up on the exploit and how to patch it. We just wrote this up and posted it a few minutes ago (before this was even on HN, lol). https://www.lunasec.io/docs/blog/log4j-zero-day/

Note that the formatMsgNoLookups workaround only applies to recent versions of the log4j library, while it's still unclear how far back this bug may stretch. Other options for patching are detailed in the thread: https://github.com/apache/logging-log4j2/pull/608#issuecomme... mentions that just removing the class providing the vulnerable behavior works well, and https://github.com/Glavo/log4j-patch is a JAR that you can add to your classpath to simply override the same class.

See https://github.com/apache/logging-log4j2/pull/608#issuecomme... for more details.

Re: Log4j RCE Found

#109

Post by tmd83 »

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.

Does that mean it's only vulnerable if JMSAppender is used otherwise not? Which should at least be a rarer use case.

Re: Log4j RCE Found

#110

Post by hawk_ »

jrockway wrote: post #76

So a lot of people sound mad that the logging library is parsing the inputs, and maybe they should be, but the truly paranoid should also be aware that your terminal also parses every byte given to it (to find in-band signalling for colors, window titles, where the cursor should be, etc.). This means that if a malicious user can control log lines, they can also hide stuff if you're looking at the logs in a terminal.…

While that's an interesting vector for attack, is it realistically an issue? Terminals are run as root all the time. I would guess any mainstream ones are well reviewed to not have such exploits work. Are you aware of any actual attacks exploiting terminal parsing in the wild?
Post reply on HN