101–110 of 209 posts
I'm not a security researcher, so I'd like to know if (probably "why") this is a bad idea: It seems like there should be some intermediary stage between logging the vulnerability & full public disclosure. Something like a partial public disclosure that says "Hey, we have a CVSS 10 about to come down on Log4j, everyone carve out a chunk of time to get their systems fixed when we publish to full disclosure & patch." An…
I'm not a security researcher, so I'd like to know if (probably "why") this is a bad idea: It seems like there should be some intermediary stage between logging the vulnerability & full public disclosure. Something like a partial public disclosure that says "Hey, we have a CVSS 10 about to come down on Log4j, everyone carve out a chunk of time to get their systems fixed when we publish to full disclosure & patch." An…
Earlier quoted context omitted.
Does this routing happen before or after log4j would be exploitable? Like if log4j is still running its parser and doing all the crazy stuff, but then routes to some other logger, it doesn't matter.
The routing happens before. The vulnerability is due to processing in the log4j back-end, after normal message formatting.
I have taken some flak over the years for rolling my own basics like logging, telemetry, tracing, authentication, session management, etc... Incidents like this remind me that it is sometimes OK to ignore those who constantly order you to "vendor it out" over some notion of principled development excellence wherein one never reinvents a single hypothetical wheel. Arguably, writing text to a log file on disk is a simp…
Given many of the engineers i have worked with and much more importantly the PMs and Managers that work over them, I would expect vulnerabilities like this to proliferate all over the place if people were to roll their own logging and telematry and especially authentication. I mean SQL injection is such an easy known mitigation yet is still on the OWASP top 10 even after so many years.
; delete from comments where id = 29544262 */--
...still there?
Earlier quoted context omitted.
On the other hand, you don't know what vulnerabilities are hidden in your own code and just haven't been discovered yet, and you're one fuzzing attack away from a vulnerability being discovered/exploited.
What if there are none? It's not like library code is some magical stuff that only senior principal ninja 10x developers can comprehend Not everything is don't roll your own crypto.
Even for crypto, I have had people give me trouble for daring to use Microsoft's public & documented implementations of SHA256 and CSPRNG to derive session secrets. It's almost as if directly interacting with any crypto primitives is tantamount to rolling your own crypto these days.
I have taken some flak over the years for rolling my own basics like logging, telemetry, tracing, authentication, session management, etc... Incidents like this remind me that it is sometimes OK to ignore those who constantly order you to "vendor it out" over some notion of principled development excellence wherein one never reinvents a single hypothetical wheel. Arguably, writing text to a log file on disk is a simp…
On the other hand, you don't know what vulnerabilities are hidden in your own code and just haven't been discovered yet, and you're one fuzzing attack away from a vulnerability being discovered/exploited.
For me the trade-off is when understanding the complete architecture and important subtleties (often ill-documented) of a third-party library takes more time than writing reasonably straightforward custom code restricted to the current needs of the application.
I'm not a security researcher, so I'd like to know if (probably "why") this is a bad idea: It seems like there should be some intermediary stage between logging the vulnerability & full public disclosure. Something like a partial public disclosure that says "Hey, we have a CVSS 10 about to come down on Log4j, everyone carve out a chunk of time to get their systems fixed when we publish to full disclosure & patch." An…
It's really hard for vulnerabilities as simple as this one to stay under wraps. When the patch went out 9 days ago [1], many vulnerability researchers were able to look at it and identify the root cause within minutes. Exploits started going out over a week ago before the CVE was released. Good security orgs that can hire skilled vulnerability researchers started patching on December 6th/7th/8th. All the chaos started on December 9th when people started leaking the poc on twitter.
The same thing happens to google chrome when they release a patch for a security vulnerability. Very skilled researchers can produce a POC and exploit given the patch alone [2]
The same thing happens even with embargoes like the one you describe in place.
[1] https://github.com/apache/logging-log4j2/commit/d82b47c [2] https://blog.exodusintel.com/2019/09/09/patch-gapping-chrome...
so is it: -Dlog4j.formatMsgNoLookups=true or -Dlog4j2.formatMsgNoLookups=true ? Every project seems to list one or the other, even this cheat-sheet seems to list both in a random way...
Replying to myself but I guess it's the second one. https://github.com/apache/logging-log4j2/blob/04637dd9102175...
Wouldn't this also be mitigated by better/stricter sandboxing? (specific network access, per app firewall etc)
I'm not a security researcher, so I'd like to know if (probably "why") this is a bad idea: It seems like there should be some intermediary stage between logging the vulnerability & full public disclosure. Something like a partial public disclosure that says "Hey, we have a CVSS 10 about to come down on Log4j, everyone carve out a chunk of time to get their systems fixed when we publish to full disclosure & patch." An…