https://github.com/search?o=desc&q=formatMsgNoLookups&s=inde... if you're curious who's patching what in the opensource (github) world.
Log4j RCE Found
411–420 of 531 posts
Re: Log4j RCE Found
#412Earlier quoted context omitted.
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?
Not in general. Your own cryptography implementation? Hell no. Your own simple logging solution that doesn't need anything fancy from log4j? Probably.
Simple is..a pretty big stretch for Log4j, even just taking the subset of features that your average medium-sized company would use.
Re: Log4j RCE Found
#413Well obviously we need a way in our LOGGING LIBRARY to download binary blobs off the Internet and execute them from log messages. Sigh
This is what has me scratching my head. What is the usecase that somebody is using LDAP to load remote classes?
I am your run of the mill CRUD developer but I haven't had to load remote classes ever.
Is this some framework level stuff? Was this an opt-in kinda scenario?
Re: Log4j RCE Found
#414log4j 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 how was it detected now? Who reported it first and what were they looking for?
Re: Log4j RCE Found
#415I 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?
In this case the library is using JNDI to go get a class from an LDAP server to execute.
But where does it get used? I mean the loading of a remote class on an LDAP server. Was this an opt-in or is it like properly baked in?
Re: Log4j RCE Found
#416I'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'.
We tested this on several JVM versions and found you needed to go really far back, to around Java 8u121 I think, to see the specific exploit using LDAP+HTTP class loading work because they changed the value of the JVM property that allows loading a class file from a remote codebase... however, as this article points out, quite mind blowingly, early JDK11 releases also seem to have been vulnerable (I believe at least…
Interesting, thank you for that analysis. From what I understand, the RCE exploit really needs two things to work: 1) The interpretation of the JNDI reference by log4j, and 2) The 'auto-execute loaded classes' (which I don't quite understand).
Is there any kind of low-level flag you can pass to Java or your environment to completely disable JNDI? I recall that there is a flag you can pass to log4j, but I can't see any reason why I would ever use JNDI anywhere in Java.
Also, do you have any additional insights on how exactly the mechanism for 2) works? From what I understand, this is a feature of Java itself?
Re: Log4j RCE Found
#417Well obviously we need a way in our LOGGING LIBRARY to download binary blobs off the Internet and execute them from log messages. Sigh
Or just make network requests from the logging framework when data comes in from, anywhere, and it’s just turned on by default.
Not that I can’t think of a use but it’s just on and no white list or…something?
Re: Log4j RCE Found
#418Is there any reason to believe this wouldn't affect log4net in the same way?
12 years of experience with .Net here - it’s been a long time since I used log4net and I was never intimately familiar with it, but I’m not aware of any built-in or common .Net functionality that will make a web request and remotely load code just by parsing a string. So unless the log4net library totally implemented that feature from scratch, it should be safe.
Re: Log4j RCE Found
#419To folks wondering what the issue is about, I'll give a short summary that I myself needed. Typically a logging library has one job to do: swallow the string as if it's some black box and spit it elsewhere as per provided configurations. Log4j though, doesn't treat strings as black boxes. It inspects its contents and checks if it contains any "variables" that need to be resolved before spitting out. Now there's a bun…
Does this affect SL4j wrappers over log4j as well ?
Re: Log4j RCE Found
#420I'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.
It's used by Elasticsearch, so possible you could exploit the log aggregation service even if the app-level logging library isn't vulnerable, but you'd need a way to make sure the first-level logging doesn't interpret the format string.