91–100 of 289 posts
Also recommended by Lunasec's mitigation guide: https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-g...
Earlier quoted context omitted.
Only once. At Facebook: https://krebsonsecurity.com/2019/03/facebook-stored-hundreds...
And google: https://www.theverge.com/2019/5/21/18634842/google-passwords...
Calendar date = Calendar.getInstance();
PrintStream ps = new PrintStream(new FileOutputStream(new File("log.txt")), true, "UTF-8");
ps.write(new SimpleDateFormat("yy-MM-dd HH:mm:ss.SSS").format(date.getTime()) + " message that does not need LDAP".getBytes("UTF-8"));
"It does more than that..." I hear you mutter... yes it does more than that!
Please build something that you are responsible for.
From scratch and with minimalism as a guideline.
Using only an OS and a programming language.
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)!
I would run screaming from such an organization.
Reality is a messy thing.
It's funny that this vuln kind of already exists in other software that uses printf() allowing the user to specify the format string. (Not nearly as easy as this particular bug of course!) Maybe we'll have a mini renaissance of format string vulns now?
Earlier quoted context omitted.
log4j 2 isn't in so many things AFAIK? log4j 1.x is in everything, but that's not vulnerable.
It's in a whole stack of Salesforce and GIS products based on the Sales force update page and some of our spatial vendors emails. That alone means a great many large and medium companies and large government departments around the world have v2 available in some way on a piece of infrastructure somewhere.
This vulnerability is like PFAS, it's going to be around forever. log4j is in so many things, things no one might think would have it. Probably a ton of old stuff people don't think to update or can (thinking consumer routers).
log4j 2 isn't in so many things AFAIK? log4j 1.x is in everything, but that's not vulnerable.
Log4j 1.x was indeed ubiquitous at one time. SLF4J took most of the mindshare before Log4j 2.x got traction and Log4j 2.x is not the go-to Java logging solution today. Spring, for instance, defaults to SLF4J. Huge code bases that were heavily invested in Log4j 1.x often migrated from 1 to 2 due to API compatibility and these account for most Log4j 2.x usage today. That's the history as I see it.
Had most developers not done Log4j 1.x -> SLF4J and instead waited for Log4j 2.x this problem would be much worse than it is; a vast number of small, neglected services would have had to be fixed. The thought that I'm having is now that the power of compromising these logging frameworks has been demonstrated the ransomware crews are going to look very hard at them and find more large holes.
Earlier quoted context omitted.
Logout4Shell is clever but would require you know where to put the string so it gets logged by the app. So, you have to know how to exploit the app. It could be in the user-agent header, or somewhere else entirely depending on the app. And, the fix wouldn't be permanent, only until the app was restarted. And, in a load-balanced environment you would need to make sure you hit each server.
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)!
It's funny that this vuln kind of already exists in other software that uses printf() allowing the user to specify the format string. (Not nearly as easy as this particular bug of course!) Maybe we'll have a mini renaissance of format string vulns now?
How does that allow RCE?