Are there any notable systems exploited by this besides minecraft?
Kronos private cloud. Wouldn't be surprised to see disruption to UKG.
https://community.kronos.com/s/feed/0D54M00004wJCdJSAW?langu...
Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
51–60 of 209 posts
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#52Ideally, log4j should not have the ability to make "outgoing calls" right? It has been years since I used it but I can't remember a valid reason why it should be allowed to do so. Since it is running inside the stack it may not be easy to enforce it. If the "client" log4j does it before even logging that is a bother. It seems like having a "central" "syslog" logging server. Traffic goes from the stack -> logging serv…
> Ideally, log4j should not have the ability to make "outgoing calls" right? What is the intended scope of log4j? I spent some time looking over the source code and cannot fathom why something that logs information would need to become this complicated.
> I spent some time looking over the source code and cannot fathom why something that logs information would need to become this complicated.
That's easy: because software development is complicated. If you look at the ticket where this was added[1], it seems like a reasonable request for something a very featureful logging library might do. Other logging frameworks[2] already supported this feature.
It's easy to armchair quarterback and say the feature shouldn't have been added, but the reality is an old project like this that's used by many large enterprises with specific requirements is going to naturally bloat as it ages.
Anyone who's been in software dev long enough has experienced this. You build a super-simple internal tool or library that does solves a specific problem you have. It starts getting used. Then you get a feature request from Department A to do something slightly different. Department B says you need to integrate the tool with their new CRM platform. The security team gets involved and says you need to integrate auditing of your tool's usage into their metrics. etc...
For Apache/log4j, it's not just multiple departments, but a wide array of companies across the entire world. It's very easy to explain feature bloat.
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#53Ideally, log4j should not have the ability to make "outgoing calls" right? It has been years since I used it but I can't remember a valid reason why it should be allowed to do so. Since it is running inside the stack it may not be easy to enforce it. If the "client" log4j does it before even logging that is a bother. It seems like having a "central" "syslog" logging server. Traffic goes from the stack -> logging serv…
The main design mistake in log4j is that it performs ${…} substitution on the complete log message by default. There’s no way for application code using the log4j front-end API to have input data containing such strings be logged verbatim, without nonstandard log4j back-end configuration (someone correct me if there’s actually a way). In principle, each application has to sanitize all strings to be logged by strippin…
The main design mistake is including it, by default, in the first place, rather than requiring you to specify some kinda custom appender or whatever.
The idea that a logging framework could lead to an RCE like this is completely bonkers. The vast majority of users just want to log straightforward data.
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#54as I understand, if we are running Java 8u121 this is not an issue... or is it?
that's what the CVE (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4422...) says:
> protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#55Earlier quoted context omitted.
"A project with a footprint like Log4j is not possible to avoid as a transient dependency even if you don’t directly import it. Log4j is a canonical logging utility for a huge ecosystem. Its current radius is beyond doing due diligence." - @rakyll (AWS)
Yeah - for example to determine if log4j is used in a maven project one would have to run "mvn dependency:tree | grep log4j". Which I did today for our 60 microservices. And also for projects deployed as war files - container server libraries also have to be checked.
The Maven enforcer plug-in lets you fail the build if you'd depend on it either directly or indirectly [1]. Note this wouldn't find shaded usages.
[1] https://twitter.com/gunnarmorling/status/1469603432269062146
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#56as I understand, if we are running Java 8u121 this is not an issue... or is it? that's what the CVE ( https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4422... ) says: > protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
As I understand it that prevents the RCE, but not other variants like leaking environment variables.
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#57Ideally, log4j should not have the ability to make "outgoing calls" right? It has been years since I used it but I can't remember a valid reason why it should be allowed to do so. Since it is running inside the stack it may not be easy to enforce it. If the "client" log4j does it before even logging that is a bother. It seems like having a "central" "syslog" logging server. Traffic goes from the stack -> logging serv…
Personally I'd like to see more runtimes with some concept of capabilities. As a user, I'd like to be able to say "this package cannot make outbound calls" rather than doing so at the program or host grain via layer 3 or layer 7 firewall rules. I think maybe Deno allows this, and I wouldn't be surprised if JVM or .Net did as well. Failing that, it would be interesting to see this implemented as a linter--low level I/…
That’s pretty much what the Security Manager is for, which Java has had since the 1.0 version. However it was rarely applied outside of Java applets, and is scheduled to be removed [0] because it is difficult to apply effectively and doesn’t cover all types of vulnerabilities.
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#58Ideally, log4j should not have the ability to make "outgoing calls" right? It has been years since I used it but I can't remember a valid reason why it should be allowed to do so. Since it is running inside the stack it may not be easy to enforce it. If the "client" log4j does it before even logging that is a bother. It seems like having a "central" "syslog" logging server. Traffic goes from the stack -> logging serv…
The main design mistake in log4j is that it performs ${…} substitution on the complete log message by default. There’s no way for application code using the log4j front-end API to have input data containing such strings be logged verbatim, without nonstandard log4j back-end configuration (someone correct me if there’s actually a way). In principle, each application has to sanitize all strings to be logged by strippin…
> without nonstandard log4j back-end configuration
By "nonstandard" do you mean different than default settings? It looks like they changed the default as of v2.15: https://issues.apache.org/jira/browse/LOG4J2-3198
For earlier versions (2.10+) it looks like there's a single setting you can toggle to prevent the lookup behavior:
log4j2.formatMsgNoLookups=true (or env var LOG4J_FORMAT_MSG_NO_LOOKUPS=true)
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#59Are there any notable systems exploited by this besides minecraft?
It's still very early, we won't have breach notifications for a while since any attacks would have started in the last few weeks at the earliest, and most would have started last week.
It’s possible that it was exploited before the issue was widely discovered, right? I thought it had been in there for a while.
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#60Ideally, log4j should not have the ability to make "outgoing calls" right? It has been years since I used it but I can't remember a valid reason why it should be allowed to do so. Since it is running inside the stack it may not be easy to enforce it. If the "client" log4j does it before even logging that is a bother. It seems like having a "central" "syslog" logging server. Traffic goes from the stack -> logging serv…
Personally I'd like to see more runtimes with some concept of capabilities. As a user, I'd like to be able to say "this package cannot make outbound calls" rather than doing so at the program or host grain via layer 3 or layer 7 firewall rules. I think maybe Deno allows this, and I wouldn't be surprised if JVM or .Net did as well. Failing that, it would be interesting to see this implemented as a linter--low level I/…
> Personally I'd like to see more runtimes with some concept of capabilities. As a user, I'd like to be able to say "this package cannot make outbound calls" rather than doing so at the program or host grain via layer 3 or layer 7 firewall rules. I think maybe Deno allows this, and I wouldn't be surprised if JVM or .Net did as well.
Unfortunately both of these platforms have removed their security controls - the JVM's SecurityManager[0] was deprecated and recent versions of .NET have dropped sandboxing. [0] https://openjdk.java.net/jeps/411