Log4j: The pain just keeps going
thenewstack.io
Log4j: The pain just keeps going
1–10 of 291 posts
Re: Log4j: The pain just keeps going
#2As a small time hobby / small business server administrator (enthusiast) , what's the best practice here?
Re: Log4j: The pain just keeps going
#3Sometimes people ask me why I'm so skeptical about software delivery techniques involving bundling and static compilation. This is a thing that people sometimes ask.
Re: Log4j: The pain just keeps going
#4As a small time hobby / small business server administrator (enthusiast) , what's the best practice here?
Make sure you have the time to patch/update your applications when security issues are raised.
Re: Log4j: The pain just keeps going
#5Sometimes people ask me why I'm so skeptical about software delivery techniques involving bundling and static compilation. This is a thing that people sometimes ask.
It's funny how every Go project seems to statically compile in the same libraries. If just one of them has a serious vuln, we're talking nearly every Go project in the world having to be patched and recompiled, or upgraded with potentially breaking changes. And as we know from Log4j, that can be incredibly difficult. Just finding all the affected Go apps will be a nightmare, and patching will not be as simple as "replacing a jar in a zip file".
Re: Log4j: The pain just keeps going
#6As a small time hobby / small business server administrator (enthusiast) , what's the best practice here?
Put a dependency check in your builds. Raise build errors when something is bad. Have it build on a regular basis (could be every month)... and then fix things.
https://owasp.org/www-project-dependency-check/
And some examples - https://jeremylong.github.io/DependencyCheck/dependency-chec...
Re: Log4j: The pain just keeps going
#7At this point I’m asking if it is ok to go nuclear: just slab aspectJ compiler as the last step and do comptime patch the log4j remote logging API. Have anyone thought of this? Btw who would use remote logging to begin with?
Re: Log4j: The pain just keeps going
#8It's probable that there are more log4j type of exploits thats just waiting to be discovered. It's also becoming hard to tell which are private enterprises vs state sponsored cyber attack.
It just seems like there's no solution. If Java is this bad imagine how much more attack surface a npm heavy project. Not only that the seeming hardware knowledge of state sponsored attackers seem sophisticated enough to gain access at the vendor level, which forces us to question even the most trusted methodologies and dependency management.
Re: Log4j: The pain just keeps going
#9As a small time hobby / small business server administrator (enthusiast) , what's the best practice here?
As an alternative / addition to the other suggestions, maintain an internal artifact store that syncs with upstream stores, but enforce that vulnerable versions aren't present. Block access to the upstream artifact stores so builds have to use the internal one.
Re: Log4j: The pain just keeps going
#10As a small time hobby / small business server administrator (enthusiast) , what's the best practice here?
If want an extremely strong mitigating control that you can design into your architecture..... allow internet egress in your production environment only to a list of domains/ips in an allowlist. This or control egress with an explicit proxy.
If vulnerable systems have no path to the internet at large then it's extremely difficult for attackers to know if a system is vulnerable to log4j and even harder to actually use it to exfiltrate data.