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

241–250 of 289 posts

Re: Log4Shell update: second Log4j vulnerability published

#242

Post by joshstrange »

staticassertion wrote: post #110
freeqaz wrote: post #45

Earlier quoted context omitted.

That's definitely very fair! You could throw it into the constructor of your app right after you init log4j, at least. I've been surprised (and horrified) to learn that there are companies out there that _can't reboot their servers_ because they simply don't know how to bring the app back up. For them... live patching is the only options. Blows my mind, but that's reality (apparently)!

Server uptime used to be a point of pride. Now people try to shut them down as often as they can. Funny how things change.

That seems to go hand-in-hand with the "Cattle not pets" concept, which I'm a huge fan of.

Re: Log4Shell update: second Log4j vulnerability published

#243

Post by shepherdjerred »

pezzana wrote: post #240

Where can I find an explanation of the problem(s) log4j actually solves? The home page doesn't do it. The wikipedia article doesn't do it. I remember when it first came out and couldn't think of a single use for it that couldn't be addressed in a cleaner way.

It solves logging

Re: Log4Shell update: second Log4j vulnerability published

#244

Post by maherbeg »

est wrote: post #231
thomond wrote: post #176

Earlier quoted context omitted.

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

> How many end users of a logging framework would even need JNDI functionality Serious question: Suppose you need to replace user ids with user names in your Java program logs, instead of writing LDAP lookups around every log line everywhere, you have to put it in some module no? How about wrap the logging framework?

This should be done as a middleware or plugin into the library that is opt in rather than built in as a default.

Re: Log4Shell update: second Log4j vulnerability published

#245

Post by kgeist »

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.

I think it's a perfectly OK idea, as long as you control the servers you are trying to access via this feature. The problem is about not sanitizing user inputs. You can achieve the same by forking a process whose file path is controlled by user input. Does it mean allowing a program to fork processes is also insane?

Re: Log4Shell update: second Log4j vulnerability published

#246

Post by baq »

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 is no eval_from_url(), though.

Re: Log4Shell update: second Log4j vulnerability published

#247

Post by jancsika »

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.

Thanks, I'll have a look.

Also, good call on your PS. :)

Re: Log4Shell update: second Log4j vulnerability published

#248

Post by awestroke »

est wrote: post #231
thomond wrote: post #176

Earlier quoted context omitted.

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

> How many end users of a logging framework would even need JNDI functionality Serious question: Suppose you need to replace user ids with user names in your Java program logs, instead of writing LDAP lookups around every log line everywhere, you have to put it in some module no? How about wrap the logging framework?

Why would you do that? That sounds like a terrible idea, and a bad way to spend your limited development resources

Re: Log4Shell update: second Log4j vulnerability published

#249

Post by HowTheStoryEnds »

plafl wrote: post #106
freeqaz wrote: post #45

Earlier quoted context omitted.

That's definitely very fair! You could throw it into the constructor of your app right after you init log4j, at least. I've been surprised (and horrified) to learn that there are companies out there that _can't reboot their servers_ because they simply don't know how to bring the app back up. For them... live patching is the only options. Blows my mind, but that's reality (apparently)!

> _can't reboot their servers_ because they simply don't know how to bring the app back up A hundred years later IT priests will demand human sacrifices to appease the server gods

So firms will need Ceremoniously Executed Offerings, eh?
Post reply on HN