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

221–230 of 289 posts

Re: Log4Shell update: second Log4j vulnerability published

#221

Post by NavinF »

BrazzVuvuzela wrote: post #112
NavinF wrote: post #87

Earlier quoted context omitted.

> If they somehow manage to get in at least they won't be roaming around inside my home network. I mean if that’s your only concern, it’s pretty easy to run Minecraft in a docker container that’s only allowed to accept inbound connections and to make outbound connections to the internet (or more specifically to the Mojang auth server)

> to make outbound connections to the internet (or more specifically to the Mojang auth server) I believe you can forgo even that; a vanilla server jar can be configured to run in "cracked" mode by setting 'online-mode' to false in server.properties. Skins won't work though, players will have steve/alex skins. It's documented on the no-longer-official wiki here: > online-mode - Server checks connecting players agains…

Oh I didn’t know that worked on the official server binary. I remember having to use the mineshafter client and having to play on cracked servers ~12 years ago when I had no way to pay for stuff as a kid. I also tried running a cracked server at home, but banned users could find new IPs faster than I could ban them :(

I guess this is still viable if you know everyone on the server and use a server plugin to auth.

Re: Log4Shell update: second Log4j vulnerability published

#222

Post by NavinF »

contravariant wrote: post #149
NavinF wrote: post #87

Earlier quoted context omitted.

> If they somehow manage to get in at least they won't be roaming around inside my home network. I mean if that’s your only concern, it’s pretty easy to run Minecraft in a docker container that’s only allowed to accept inbound connections and to make outbound connections to the internet (or more specifically to the Mojang auth server)

Not sure I'd feel safe hosting a docker container running malicious code.

Linux namespaces have improved over the last decade. Containers are about as secure as VMs these days.

Re: Log4Shell update: second Log4j vulnerability published

#223

Post by hu3 »

lrem wrote: post #217
adambatkin wrote: post #182

Earlier quoted context omitted.

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…

But we're not talking about memory corruption bugs. We're talking about intentional features.

That was covered with eval() which is an intentional feature.

> Perl/Python/Ruby/PHP and friends all have eval()...

Re: Log4Shell update: second Log4j vulnerability published

#224

Post by jatone »

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?

a trivial false dichotomy. you can create plugin systems that do not allow modifying the runtime.

Re: Log4Shell update: second Log4j vulnerability published

#225

Post by jrochkind1 »

I just saw a fun user-agent string in my (not log4j!) logs. In case anyone thought they could buy themselves some time with a naive filter on the string "${jndi" in front of your app or something, enjoy the user-agent string beginning:

    ${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p} ...
Which I assume is a form of escaping/embedding which will work on at least some log4j's, although that's just an assumption I'm making seeing this in my logs, I'm not familiar with the details.

I could have seen myself, not really a security person, thinking a filter on `jndi` would work too...

Re: Log4Shell update: second Log4j vulnerability published

#226

Post by dylan604 »

toyg wrote: post #210
dylan604 wrote: post #93

Earlier quoted context omitted.

I knew it was definitely more than once. If it gets done at places like FB & G, then you know other smaller places are doing/have done it as well. They just didn't make the news, nor know it isn't a bad thing.

I mean, what if we have to troubleshoot an issue that is due to, say, the character encoding of such password? We need to see it, right? (yes, such an issue would likely indicate you're not handling that sort of data in the right way, but fixing that would probably take three weeks and the PM is screaming FIXITNAOO because the customer is on the phone...) (I'm not condoning this, just saying that it can look sensible…

No. Just NO NO NO. Passwords should be treated as sacrosanct. There are other ways of testing encoding. Looking at someone's password should be anathema to anyone. That's like wearing mirrors on your shoes trying to look up places one shouldn't be looking. It's just naughty to the point that any normal person would think it wrong to be doing it. Those kind of requests should actually be reported immediately. Stand up for yourself, for your fellow devs, for 'all humankind' and tell that PM making the request to pound sand (politely). If still pushed, go report them to the next rung up. "Because orders" is not a valid excuse.

Re: Log4Shell update: second Log4j vulnerability published

#227

Post by hu3 »

corpMaverick wrote: post #187

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. Contin…

> 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

Preach. As a consultant, I have been trying to implement continuous integration in a team and it has been so hard to convince project owners that delivering frequently and continuously to production behind feature flags is a net gain over accumulating "features" in dozens of branches that get outdated, poorly documented and even forgotten.

Some days the team crawls to snail pace trying to pick arbitrary branches to merge into integration branch. Then it takes days to be tested, adjusted, approved and merged into master. The process is so convoluted and cognitively loaded that it has been a major source of bugs.

They need better tests and continuous integration to become nimble.

Re: Log4Shell update: second Log4j vulnerability published

#228

Post by qalmakka »

adambatkin wrote: post #182
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…

The difference is that being pwned by a random memory corruption, while unfortunate, is an unintended feature. This on the other hand provides a deliberate, standardized and convenient way to allow anyone to download *any* arbitrary code into a running JVM. This is something that it is NEVER ok, not in any form or fashion, not even your own network unless you enable some huge debug flag, and it's WAY worse than eval().

This whole thing exists because Java has basically kept around a way of pulling off something akin to

    wget -O - someurl | sh
but with extra steps for more than 20 years. This is absolutely insane even from a '90s perspective, the whole idea is broken and it absolutely bewilders me that `com.sun.jndi.ldap.object.trustURLCodebase` was only set to false by default in 2018. This is utter rubbish; support for arbitrary URL codebases should have been canned decades ago, not 3 years ago.

The fact that JNDI can pull random code from a server like that is absolutely nonsensical trash, no matter how one spins it.

Re: Log4Shell update: second Log4j vulnerability published

#229

Post by sporkland »

watwut wrote: post #198
sporkland wrote: post #171

Earlier quoted context omitted.

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.

You mean that they are adding log4j maven dependency where there was none?

Yes

Re: Log4Shell update: second Log4j vulnerability published

#230

Post by qalmakka »

hu3 wrote: post #223
lrem wrote: post #217

Earlier quoted context omitted.

But we're not talking about memory corruption bugs. We're talking about intentional features.

That was covered with eval() which is an intentional feature. > Perl/Python/Ruby/PHP and friends all have eval()...

There's a difference between providing a way to call the interpreter and giving people a convenient way to download code and execute it. No matter how you spin it, it's basically the same as standardizing `curl | sh`.

PS: eval() is also very bad per se, and IMHO it's a dangerous feature when used outside of a REPL or a debug environment. The fact that others already have bad features or are doing dubious things doesn't give you a free pass for doing them yourself. It never does, it's like saying that committing a crime is OK as long as everyone else does the same.

Post reply on HN