Hope this helps someone. How we visualized and fixed runtime exposure due to vulnerable Elasticsearch, using ThreatMapper
Log4j RCE Found
501–510 of 531 posts
Re: Log4j RCE Found
#502Earlier quoted context omitted.
Because it apparently is absurdly complicated for a task I can solve with 'println'.
Java since 5 has included it’s own logging class. It doesn’t have as many features as log4j, but it also doesn’t load classes via JNDI.
java 5 - erm. java 1.4... and truth be told I'd prefer them over any other logging solution. Yet, java.util.logging has has quite a lot of vulnerabilities, itself.
Re: Log4j RCE Found
#503Earlier quoted context omitted.
That's stunning. People are screaming about SQL injections and such for decades now, every "programming 101 for complete doofuses" course has a chapter about it in the first ten pages, we have tools upon tools to detect patterns of using untrusted data as control... And yet, one of the most popular logging toolkits in one of the most popular languages has it built in as a feature - literally using untrusted and unfil…
I mean it's so inexplicably bad that it's hard to imagine it being an innocent mistake. You have to wonder if opening a ticket for such a feature then having someone (or yourself under another account) build it in such an egregious way is a possible vector for deliberately creating such exploits. If this feature was default enabled, then it's even more suspect. It's just such an esoteric thing. When you factor in thi…
That is a pretty far out security assessment. You have the same exploits in commercial software, just security through obscurity helps because of far less usage.
Re: Log4j RCE Found
#504Earlier quoted context omitted.
Trying to put my head around, why is this log.debug("user-agent=" + userAgent); bad?
Because the string concatenation requires allocation of a new string, which will need to be garbage collected, regardless of whether or not the log.debug actually needs it. Using a format and args lets you call the method with only references to existing objects, no additional string needs to be allocated unless the log method actually needs to generate the string to log (and it might even be able to use streaming to…
ok, so its only gc overhead, and no security issue with it?
Re: Log4j RCE Found
#505Earlier quoted context omitted.
My original comment is a joke to security minded people, because if pentesters/crooks see you're handling your inputs in that manner, they know to keep looking. Nobody in their right mind will sanitize (and specifically not encode), on receipt, something like a name to be safe for every logging library, query language, or output in HTML/terminal/etc their backend may use. Such an undertaking is even provably impossib…
> Nobody in their right mind will sanitize (and specifically not encode), on receipt, something like a name to be safe for every logging library, query language, or output in HTML/terminal/etc their backend may use. Such an undertaking is even provably impossible for combinations where one component requires escape sequences that again would need to be escaped for something else - in a circular manner. And that's jus…
First off, how nice of you to quote only the first and last part of my comment while paraphrasing the middle part as if you're telling me something new:
> Beyond the rules applicable to the specific type of input (for example: it should be a correctly UTF-8 encoded string with a maximum length)
versus
> You aren't understanding. You should only need one regex per input.
Also you're hopping between sanitation and validation as if you believe they're the same thing. My original example was a case of doing specifically validation badly and you specifically spoke about validation in your original comment. You then replied with a comment suggesting one should apply encoding, specifically escaping, to inputs. That is not called validation.
Apparently with this most recent comment we're back to validation.
At this point I don't know how to talk to you because you seem to make this conversation about something new with each comment and I'm past humoring it.
Re: Log4j RCE Found
#506Earlier quoted context omitted.
I mean it's so inexplicably bad that it's hard to imagine it being an innocent mistake. You have to wonder if opening a ticket for such a feature then having someone (or yourself under another account) build it in such an egregious way is a possible vector for deliberately creating such exploits. If this feature was default enabled, then it's even more suspect. It's just such an esoteric thing. When you factor in thi…
Alexander Dumas once said: > Une chose qui m'humilie profondément est de voir que le génie humain a des limites, quand la bêtise humaine n'en a pas. So, never discount human stupidity :-(
Sounds quite sensationalized and the other way round tbh. Nobody 10000 years ago would have imagined how far we’ve come nowadays as a whole, while stupidity would be more likely limited by the circumstances and conditions of the time.
Re: Log4j RCE Found
#507">
Re: Log4j RCE Found
#508">
'
Re: Log4j RCE Found
#509This is exploitable in applications that use Elastic Stack with logstash as a log processor. I've just been able to reproduce it in an Magento ecommerce with payload inserted into payments details.
Per ESA-2021-31 [1] the common mitigation is not sufficient for logstash:
> The widespread flag -Dlog4j2.formatMsgNoLookups=true is NOT sufficient to mitigate the vulnerability in Logstash in all cases, as Logstash uses Log4j in a way where the flag has no effect. It is therefore necessary to remove the JndiLookup class from the log4j2 core jar, with the following command:
Logstash 7.16.1 should be out today to fix this... update even if mitigated:
> Users should upgrade to Logstash 6.8.21 or 7.16.1 once they are released (expected Monday 13th December). These releases will replace vulnerable versions of Log4j with Log4j 2.15.0.
EDIT: 7.16.1 is out in GitHub, but not yet everywhere on elastic co: https://github.com/elastic/logstash/releases/tag/v7.16.1
[1] https://discuss.elastic.co/t/apache-log4j2-remote-code-execu...
Re: Log4j RCE Found
#510Earlier quoted context omitted.
Because the string concatenation requires allocation of a new string, which will need to be garbage collected, regardless of whether or not the log.debug actually needs it. Using a format and args lets you call the method with only references to existing objects, no additional string needs to be allocated unless the log method actually needs to generate the string to log (and it might even be able to use streaming to…
ok, so its only gc overhead, and no security issue with it?
No. I don’t think anybody generally expects log message parameterization to do anything like escaping or white space normalization or anything to the parameters that wouldn’t also be done to the message string.
If you are using a logger to output a message which you want to be able to parse based on delimiters, say, it would be up to you to escape any parameters you were incorporating into it to ensure they don’t confuse your parser.