Can't to see how much Equifax data gets leaked:)
Log4j RCE Found
381–390 of 531 posts
Re: Log4j RCE Found
#382I've been thinking about this since I saw it here on HN yesterday, and I can't help but entertain the idea that this might end up being 'the worst software security flaw ever'.
Re: Log4j RCE Found
#383Earlier quoted context omitted.
JNDI lookup in it self is not a problem, problem is that user input is not sanitised and can include templates which can have JNDI lookup in them. I would expect user input with {} template symbols to be escaped and not evaluated.
Maybe, but still this seems as vanity feature added because "It would be really convenient"... this wasn't something what was needed, but something what was added to make life of maybe 0.1% of users little bit easier. My guess is that most of users of Log4J2 don't even know that it is able to do such magic, and would be horrified knowing it. IMHO Log library should log, not do some magic stuff.
I am indeed horrified
Re: Log4j RCE Found
#384log4j is a very popular and ubiquitous Java library. Having a zero-day remote code execution vulnerability in it is a serious problem that undoubtedly affects a huge portion of the internet.
It's almost mind boggling that it went for so long undetected. It's been sitting there for 7 years.
Re: Log4j RCE Found
#385Minecraft 1.18.1 was released to patch this exploit. They don't guarantee that < 1.17 isn't vulnerable still.
Re: Log4j RCE Found
#386log4j is a very popular and ubiquitous Java library. Having a zero-day remote code execution vulnerability in it is a serious problem that undoubtedly affects a huge portion of the internet.
It's almost mind boggling that it went for so long undetected. It's been sitting there for 7 years.
> so long undetected
... that we know of.
Re: Log4j RCE Found
#387Earlier quoted context omitted.
By the same token why would you roll your own instead of using a tried and true library that any experienced Java developer already knows?
> why would you roll your own instead of using a tried and true library For one, the very reason we are all in this thread right now.
Plenty of "roll your own x"s have critical security bugs too, they just don't make the front page of HN. Do you really think, in general, roll your own is safer?
Re: Log4j RCE Found
#388I haven't read into the specifics of this issue but doesn't a RCE vulnerability in a Java library really rest on a RCE vulnerability in Java/JRE itself?
Re: Log4j RCE Found
#389I've been thinking about this since I saw it here on HN yesterday, and I can't help but entertain the idea that this might end up being 'the worst software security flaw ever'.
nah, it's just a logging package that not everyone uses. it would be much worse if it was in an OS of some sort.
Re: Log4j RCE Found
#390I’m amazed at the reaction here. Lots of comments ITT about how this library is horrible and logging should be a solved problem from a security perspective. Similar commentary was here recently regarding some unsafe docker default. Developers always want abstractions to make programming easier, but they never consider the cost of using those abstractions. It’s so convenient to place all the burden on library authors…
> Put a regex whitelist on your inputs wherever there’s a trust boundary.
No. That's a horrible idea because it requires you to think about security in multiple places and get it right every time.
Instead I am going to wrap the horrible logging library that does not automatically escape control characters within arguments in a wrapper that does. Now it's impossible for me to mess up.
Or... you know. One could have designed the logging library in such a sane way in the first place.