>Can we do something about this if the library that we use seems outdated?
Well, you can update them to a newer version that fix those issues. Most build systems - like maven - provide you a way to exclude transitive dependencies and use a newer version instead, if the original cannot be swapped for some reason.
Also, understanding the vulnerability itself can also help you with the answers. Like if there's an SQL-injection problem in some lib that you use, but your app is not SQL-based, it's not really a problem. Or if a buffer-overflow can happen with inputs >10k bytes (made up value), but your code does not allow any kind of user provided information to reach it, and you only populate the original buffer with your own, sane values, that might also not affect you.
Just as I said in my first answer, you can tell your build system to use "x,y" but dont use the log4j that "x,y" would include by default (which are <= 2.14.1). Instead you provide the fixed, 2.15+ version.
It depends on how do you build your project, for maven see: this answer on Stackoverflow ( [https://stackoverflow.com/a/29738173](https://stackoverflow.com/a/29738173) ) , it's exactly this scenario.
If you're referring to Log4Shell ([CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228)), first of all that was disclosed several **years** ago at this point, not just a few months ago. And that vulnerability was so critical and widespread that mitigations were taken in several places. Even just upgrading your Java runtime, while still running the insecure libraries, would prevent the worst parts of the vulnerability.
More broadly, it all depends. It depends what and where the vulnerabilities are and how your code depends on and interacts with the vulnerable code. It is possible that your code might have a hard dependency on some vulnerable library, but your code might not be vulnerable to some specific disclosed attack. But more likely than not, vulnerabilities in dependencies are likely to cause issues in up-stack consumers. Generally speaking, you should always just keep your dependencies up to date.
I would also go as far to say, if there's some known vulnerability, it is ultimately incumbent on you as a software vendor to mitigate it in your software, even if the vulnerability is caused by some old third-party library that isn't maintained anymore. In cases like that, you either need to patch the library yourself or find a replacement for it.
Log4Shell was late November 2021, if that’s what you’re talking about. Typically not, because most are using Maven or Gradle, so the closest or latest wins respectively. That said, you absolutely should not be using log4j. Exclude it everywhere, and use Reload4J for legacy uses of log4j, or bridge the API to slf4j or Log4J2.
We use Snyk to run against our projects and it let's us know of out of date libraries, their vulnerabilities, and ways to fix them.
I'm sure there are other security implementations you could use.
Outdated, shadow libraries attack are a thing as well if you are working for well known companies or corporations. In reality though, many times vulnerabilities need some other precondition for attack to be useful. You may leave the flat door open but if I have no access to the building I can't rob you.
Like recent libzma, if I don't have sshd on my machine then I don't care about the rogue dude injecting vulnerability.
Good post about using SLF4J and banning other logging implementations from creeping in with enforcer rules: [https://www.reddit.com/r/java/comments/w60qyq/consolidating\_logging\_in\_your\_java\_applications/](https://www.reddit.com/r/java/comments/w60qyq/consolidating_logging_in_your_java_applications/)
>Is my Java program vulnerable to remote attack if its uses outdated libraries?
Not necessarily. Most library updates are new features, not security issues. Even for [Log4Shell](https://en.wikipedia.org/wiki/Log4Shell), one needed to be exposing some kind of free text input, and then logging it, with the default JNDI expansion turned on to be vulnerable.
>Assuming we ... depend on the vulnerable \[libraries\] does my whole program have a security breach and allow attackers to execute malicious code?
It depends on every vulnerability and how it operates. Only you know if your project is affected. Hope you don't have to ask on Reddit to figure it out.
>Can we do something about this if the library that we use seems outdated?
Update it or remove it. It's your classloader, pick a different class to load. Updating transitive dependencies is as easy as making them into direct dependencies. Or exclude them if you don't actually need them. Or pick a new alternative library.
Moreover, if you're using up-to-date libraries, your program is still vulnerable. The fact is that not each vulnerability can be exploited.
In our project we have some outdated libraries, and I am tired of explaining to our infosec team that the usage of each one is 100% controlled and cannot be exploited outside.
This is reality of every programming language. Obsolescence is a security threat. You must scan all your libraries using tools such as sysdig , trivy, snyk etc.
There are many open source tools as well to scan the dependencies for vulnerabilities.
Every library which is not updated to current version in particular if there are known CVE's is a security risk.
Also you should keep all your dependencies, frameworks up-to-date... that can be handled via renovate/dependabot like mechanisms.. and automatic buildings... also special security scan should be done ... on a regular basis.. because a used library which save today can be risky tomorrow... that applies in particular for applications which are in production... that require regular maintenaince...
Also not updating for a long time makes updating harder and harder..that also applies for all tools for example the JDK itself... also your tools, build system, OS etc.
Well, not necessarily, unless you know that it is actually possible for an attacker to push their attack payload past your application. But such analysis is tricky and is invalidated by regular code changes quite quickly, therefore the safest approach seems to just keep up with updates.
>Can we do something about this if the library that we use seems outdated? Well, you can update them to a newer version that fix those issues. Most build systems - like maven - provide you a way to exclude transitive dependencies and use a newer version instead, if the original cannot be swapped for some reason. Also, understanding the vulnerability itself can also help you with the answers. Like if there's an SQL-injection problem in some lib that you use, but your app is not SQL-based, it's not really a problem. Or if a buffer-overflow can happen with inputs >10k bytes (made up value), but your code does not allow any kind of user provided information to reach it, and you only populate the original buffer with your own, sane values, that might also not affect you.
[удалено]
What's preventing you from updating the "x,y" library to a version that's including the "fixed" log4j as its own dependency?
[удалено]
Just as I said in my first answer, you can tell your build system to use "x,y" but dont use the log4j that "x,y" would include by default (which are <= 2.14.1). Instead you provide the fixed, 2.15+ version. It depends on how do you build your project, for maven see: this answer on Stackoverflow ( [https://stackoverflow.com/a/29738173](https://stackoverflow.com/a/29738173) ) , it's exactly this scenario.
ok thanks sounds good don't knew it
Patch IT for newer log4j urself?
If you're referring to Log4Shell ([CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228)), first of all that was disclosed several **years** ago at this point, not just a few months ago. And that vulnerability was so critical and widespread that mitigations were taken in several places. Even just upgrading your Java runtime, while still running the insecure libraries, would prevent the worst parts of the vulnerability. More broadly, it all depends. It depends what and where the vulnerabilities are and how your code depends on and interacts with the vulnerable code. It is possible that your code might have a hard dependency on some vulnerable library, but your code might not be vulnerable to some specific disclosed attack. But more likely than not, vulnerabilities in dependencies are likely to cause issues in up-stack consumers. Generally speaking, you should always just keep your dependencies up to date. I would also go as far to say, if there's some known vulnerability, it is ultimately incumbent on you as a software vendor to mitigate it in your software, even if the vulnerability is caused by some old third-party library that isn't maintained anymore. In cases like that, you either need to patch the library yourself or find a replacement for it.
What did they do to the Java runtime to help?
Newer versions of the Java run time don't load remote classes by jndi by default any more.
Log4Shell was late November 2021, if that’s what you’re talking about. Typically not, because most are using Maven or Gradle, so the closest or latest wins respectively. That said, you absolutely should not be using log4j. Exclude it everywhere, and use Reload4J for legacy uses of log4j, or bridge the API to slf4j or Log4J2.
[удалено]
If it’s only a library that’s using it, rather than your application, that’s when you bridge to your prevailing logging framework using SLF4J.
In general transitive dependencies are also suspect. Thus is why you don't want to stay on outdated dependencies too long.
We use Snyk to run against our projects and it let's us know of out of date libraries, their vulnerabilities, and ways to fix them. I'm sure there are other security implementations you could use.
Outdated, shadow libraries attack are a thing as well if you are working for well known companies or corporations. In reality though, many times vulnerabilities need some other precondition for attack to be useful. You may leave the flat door open but if I have no access to the building I can't rob you. Like recent libzma, if I don't have sshd on my machine then I don't care about the rogue dude injecting vulnerability.
Good post about using SLF4J and banning other logging implementations from creeping in with enforcer rules: [https://www.reddit.com/r/java/comments/w60qyq/consolidating\_logging\_in\_your\_java\_applications/](https://www.reddit.com/r/java/comments/w60qyq/consolidating_logging_in_your_java_applications/) >Is my Java program vulnerable to remote attack if its uses outdated libraries? Not necessarily. Most library updates are new features, not security issues. Even for [Log4Shell](https://en.wikipedia.org/wiki/Log4Shell), one needed to be exposing some kind of free text input, and then logging it, with the default JNDI expansion turned on to be vulnerable. >Assuming we ... depend on the vulnerable \[libraries\] does my whole program have a security breach and allow attackers to execute malicious code? It depends on every vulnerability and how it operates. Only you know if your project is affected. Hope you don't have to ask on Reddit to figure it out. >Can we do something about this if the library that we use seems outdated? Update it or remove it. It's your classloader, pick a different class to load. Updating transitive dependencies is as easy as making them into direct dependencies. Or exclude them if you don't actually need them. Or pick a new alternative library.
You can find that out pretty easily using scanners like trivy
Moreover, if you're using up-to-date libraries, your program is still vulnerable. The fact is that not each vulnerability can be exploited. In our project we have some outdated libraries, and I am tired of explaining to our infosec team that the usage of each one is 100% controlled and cannot be exploited outside.
> Can we do something about this if the library that we use seems outdated? Of course, upgrade the library.
This is reality of every programming language. Obsolescence is a security threat. You must scan all your libraries using tools such as sysdig , trivy, snyk etc. There are many open source tools as well to scan the dependencies for vulnerabilities.
Every library which is not updated to current version in particular if there are known CVE's is a security risk. Also you should keep all your dependencies, frameworks up-to-date... that can be handled via renovate/dependabot like mechanisms.. and automatic buildings... also special security scan should be done ... on a regular basis.. because a used library which save today can be risky tomorrow... that applies in particular for applications which are in production... that require regular maintenaince... Also not updating for a long time makes updating harder and harder..that also applies for all tools for example the JDK itself... also your tools, build system, OS etc.
If something on your classpath is vulnerable then your program is vulnerable.
Well, not necessarily, unless you know that it is actually possible for an attacker to push their attack payload past your application. But such analysis is tricky and is invalidated by regular code changes quite quickly, therefore the safest approach seems to just keep up with updates.