Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Log4j: The pain just keeps going

thenewstack.io

Post reply on HN
Print view View original

101–110 of 291 posts

Re: Log4j: The pain just keeps going

#101

Post by jsiaajdsdaa »

MilStdJunkie wrote: post #76
jsiaajdsdaa wrote: post #55

Earlier quoted context omitted.

Better idea: stop logging.

It's not just logging. L4J is so extensible that people have used it for all kinds of things, way waaaaaayyyyy away from just logs. So disabling logs won't necessarily cut it. I am no expert. I ended up indexing all the open source kruft I use to hold this ship of fools together, then verified that the Log4J pieces were definitely disabled with a bunch of monitoring while I tossed stuff at it. I did mention I am not…

F around and find out basically. If you choose to build on the house of cards, thou repeath whaet thou soweth or something.

Re: Log4j: The pain just keeps going

#102

Post by WorldMaker »

vanattab wrote: post #50

Does anyone know if log4net the .net version of log4j is effected?

log4net was never affected by the log4shell vulnerability as there is no .NET equivalent for JNDI [0]. JNDI is remote code execution as a service, and entirely a Java idea that that would be generally useful.

Though if you are concerned about using a library with "log4" in the name and/or shuffled into the Apache graveyard in .NET, there are lots of useful replacement libraries. Microsoft.Extensions.Logging is "out of the box" in modern .NET and a simple NuGet away in older frameworks.

[0] https://en.wikipedia.org/wiki/Java_Naming_and_Directory_Inte...

Re: Log4j: The pain just keeps going

#103

Post by chrisseaton »

0xbadcafebee wrote: post #5
WesolyKubeczek wrote: post #3

Sometimes 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 "rep…

> nearly every Go project in the world having to be patched and recompiled

Is that a particular problem? What's the difficulty with recompiling?

Re: Log4j: The pain just keeps going

#104

Post by brabel »

shagie wrote: post #54
hedora wrote: post #44

Earlier quoted context omitted.

What if the project recompiled them from source with some other version of javac, and prepended "My" to each class name?

I am not familiar with any project that goes through such extremes to avoid vulnerability scanners. I am also not aware of any Java developers who build 3rd party libraries from source and avoid using maven (or gradle, or the odd one with ivy). Your "what if..." doesn't describe any workflow that I have ever experienced with Java in a professional (and even hobbyist) context.

I think OP is basically describing shading, which is actually quite common.

https://maven.apache.org/plugins/maven-shade-plugin/

Re: Log4j: The pain just keeps going

#105

Post by brundolf »

AshamedCaptain wrote: post #85
BrainVirus wrote: post #37

If you automatically update your dependencies all the time, you will constantly get new bugs, issues and sometimes even malware. If you don't update your dependencies all the time, you will be vulnerable to old bugs and issues. The current software engineering paradigm has no meaningful answer to this , no matter what "security experts" tell you. In a sane industry this realization would lead to a change of the parad…

I still think that betteer ABI/API stability & control _is_ the ideally better solution, but even if I'm a fan of plain old C / sonames dependency management, I'll readily admit that very few people actually do any type of API promises these days, much less API.

ABI/API stability != behavioral stability, though. I can give you a dependency with exactly the same interface, that will still break your software. It's not a solution (even if it helps with one piece of the puzzle)

The only complete solution would be static analysis (read: type systems) that can guarantee everything about some code's contract/behavior relative to the caller. Short of that, it's just going to continue being a bunch of manual half-solutions like API checks, existing type-level checks, manual changelog reading, manual upgrades, testing, etc.

Re: Log4j: The pain just keeps going

#106

Post by d4mi3n »

BrandoElFollito wrote: post #71
Nursie wrote: post #23

Earlier quoted context omitted.

Been in similar situations, it is not fun. "You have a vulnerable version of netty" "No, we don't, that's a false positive" "No see, the tool says you need netty 4.x and that's version 1.x, you need to update" "OK, but the tool is wrong, it's just picking up anything with 'netty' in the name, and that component is a wrapper around netty for some other thing, it only goes up to 1.8" "You have to update it to 4.x, this…

I run a security team in a large company. What you described is usually the result of some "consulting company" (in our case big ones) that drop stuff with zero actual knowledge. Every year we "review" these with the board and it is annoying as fuck. Recently they got a new manager who understands we are in the same boat. They have to provide a report with some findings and I need to have a secure environment. We tal…

Hi! Question from a fellow practitioner: What tools or processes do you and your team use to identify false positives in such scans and reports? How do you track out-of-band mitigations against real-but-unreachable vulnerabilities that have been identified? e.g. A WAF set to intercept requests that trigger a specific vuln, or network segmentation to limit the scope of a moderate vulnerability.

In my experience tuning out false positives and other noise is fairly straightforward when you're only looking at CVEs, but things rapidly break down when you're trying to prioritize work with limited resources (only so many security engineers and engineering teams with spare cycles on their roadmap).

I have yet to find a good solution here other than manually whitelisting specific vulns in some kind of tracker and reviewing them whenever the network topology or configuration for an application changes.

Curious to hear your experiences, though I suspect this is a common and difficult to solve problem.

Re: Log4j: The pain just keeps going

#107

Post by ClumsyPilot »

BrainVirus wrote: post #37

If you automatically update your dependencies all the time, you will constantly get new bugs, issues and sometimes even malware. If you don't update your dependencies all the time, you will be vulnerable to old bugs and issues. The current software engineering paradigm has no meaningful answer to this , no matter what "security experts" tell you. In a sane industry this realization would lead to a change of the parad…

because our industry is obsessed with abstractions - the moto is to never fix anything, just pave over it with another abstraction.

for example we didnt fix how we build applocations and manage dependancies, we invented docker.

we didn't create a secure runtime for the cloud where applications can run, instead we virtualised whole operating systems

Re: Log4j: The pain just keeps going

#108

Post by _jal »

Spooky23 wrote: post #79
BrainVirus wrote: post #37

If you automatically update your dependencies all the time, you will constantly get new bugs, issues and sometimes even malware. If you don't update your dependencies all the time, you will be vulnerable to old bugs and issues. The current software engineering paradigm has no meaningful answer to this , no matter what "security experts" tell you. In a sane industry this realization would lead to a change of the parad…

Yup, you’re outsourcing your decisions in exchange for not doing the work. You have to understand your risks and needs. Your boring business systems that will live for 50 years need to have boring system level libraries or stuff you maintain. Your fast time to market or non-critical systems are optimized by speed and cost. If your service depends on a bunch of downstream stuff, your processes need to support upgrade…

There is pressure in our org to find ways to have fewer dependencies.

Some of this is trivial, and a very good thing - stop using bullshit exercises in fragmentation like isEven.

Some of it is very much not, and will apply pressure to find vendors who are willing to vet their own bundles of commonly used libs.

There will be numerous second order effects of that, including the ghettoization of open source that isn't "QualStrike Approved(tm)".

Re: Log4j: The pain just keeps going

#109

Post by leeoniya »

ClumsyPilot wrote: post #107
BrainVirus wrote: post #37

If you automatically update your dependencies all the time, you will constantly get new bugs, issues and sometimes even malware. If you don't update your dependencies all the time, you will be vulnerable to old bugs and issues. The current software engineering paradigm has no meaningful answer to this , no matter what "security experts" tell you. In a sane industry this realization would lead to a change of the parad…

because our industry is obsessed with abstractions - the moto is to never fix anything, just pave over it with another abstraction. for example we didnt fix how we build applocations and manage dependancies, we invented docker. we didn't create a secure runtime for the cloud where applications can run, instead we virtualised whole operating systems

> because our industry is obsessed with abstractions

"we do not break userland, period" -- Linus Torvalds

not breaking existing stuff is why many abstractions exist, and even why many are put in place early on, to allow for some wiggle room without having to break all the things. people tend to prefer software that continues to work, above all else.

Re: Log4j: The pain just keeps going

#110

Post by brabel »

neals wrote: post #2

As a small time hobby / small business server administrator (enthusiast) , what's the best practice here?

Every case is different... but for the log4shell case in particular:

* newer JVM versions protected against the main attack (JNDI), so if you were on any JDK version released in the last couple of years, you wouldn't be vulnerable. * Java serialization filters [1], which are highly recommended to be setup in any Java application, would also have prevented the attacks. * not including large libraries with lots of unused features could have prevented this. In this case, log4j has support for a dozen or so things that should've been opt-in (and I think they are now) but were enabled by default in every installation.

In summary: actually paying attention to possible attacks and ensuring you're defended against them, and reducing the surface area for attacks makes your application much safer.

[1] https://docs.oracle.com/javase/10/core/serialization-filteri...

Post reply on HN