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

41–50 of 291 posts

Re: Log4j: The pain just keeps going

#41

Post by Natsu »

Nursie wrote: post #23
jacobyoder wrote: post #12

Had to deal with some automated scan tool telling a client "you have log4j - you're vulnerable!" when... we didn't. A project was including a dependency on SLF4J and that project pulled in slf4j-log4j (IIRC). But it was not configured, wasn't compiled in to the final jar, and ... even it was, it was very old log4j (1.1 or 1.2 IIRC?). The vulnerability didn't affect that older version. We had to spend a week back and…

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…

This is where you could probably just have renamed the file.

Re: Log4j: The pain just keeps going

#42

Post by dylan604 »

commandlinefan wrote: post #29
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 sometimes feel that my job description could be "arguing with people who feel passionately about something they don't understand".

Isn't that just a description of life in general?

Re: Log4j: The pain just keeps going

#43

Post by raesene9 »

dspillett wrote: post #36
jacobyoder wrote: post #12

Had to deal with some automated scan tool telling a client "you have log4j - you're vulnerable!" when... we didn't. A project was including a dependency on SLF4J and that project pulled in slf4j-log4j (IIRC). But it was not configured, wasn't compiled in to the final jar, and ... even it was, it was very old log4j (1.1 or 1.2 IIRC?). The vulnerability didn't affect that older version. We had to spend a week back and…

> We had to spend a week back and forth with We've had similar out of a pen test that noted we were using nginx for some of our internal dashboards/tools and the version running (1.18 IIRC) was officially EOLed upstream so a high security issue. They initially wouldn't listen to the argument that we use stable/LTS Debian/Ubuntu release only, and those hold functionality stable (which is one of the key reasons to use…

If it was an unauthenticated test, I'm not surprised. Raising findings off of banners is notoriously error prone, but pentesters often err on the side of raising things that are dubious rather than leaving them out.

If it was a credentialed review, you'd have hoped their scanners would plugin to the appropriate debian/ubuntu security database and give you a less false positive prone set of findings (although with debian based stuff you still have the problem of scanners reporting the "unfixed" set sometimes)

Re: Log4j: The pain just keeps going

#44

Post by hedora »

shagie wrote: post #40
hedora wrote: post #22

Earlier quoted context omitted.

Java's "statically link then scan" approach doesn't really work though. (Some sibling threads explain why.) Even Linux distributions where rebuilding the world is easy (like Debian) insist on breaking dependencies out into shared libaries, since tracking ad hoc vendored dependencies is just too difficult. For example, sometimes people play dynamic loading and renaming tricks to allow multiple versions of the same Jav…

I'm not sure what you mean by "statically link then scan" in the Java context. The fingerprint of the vulnerable class files are the same no matter where they are stored. They could be bundled together, or shoved in a fat jar, or exploded into all their classes -- but the class file always is distinct and identifiable.

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

Re: Log4j: The pain just keeps going

#45

Post by robertlagrant »

upupandup wrote: post #8

It'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 acces…

It could be that npm libraries' obsession with only doing one thing will mean that they are less likely to get the sort of feature bloat that caused log4j's current misery.

Re: Log4j: The pain just keeps going

#46

Post by raesene9 »

Nursie wrote: post #23
jacobyoder wrote: post #12

Had to deal with some automated scan tool telling a client "you have log4j - you're vulnerable!" when... we didn't. A project was including a dependency on SLF4J and that project pulled in slf4j-log4j (IIRC). But it was not configured, wasn't compiled in to the final jar, and ... even it was, it was very old log4j (1.1 or 1.2 IIRC?). The vulnerability didn't affect that older version. We had to spend a week back and…

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…

Over-reliance on tools is a bad problem in Infosec, often due to the range of areas they have to cover. That said a good infosec person should always have an understanding of where their tools are limited, so they can work around those deficiencies.

Re: Log4j: The pain just keeps going

#47

Post by hedora »

tekchip wrote: post #33
hedora wrote: post #17

Earlier quoted context omitted.

Once you realize this sort of shallow, automated audit exists to grease the wheels of some security theater operation, this sort of back and forth makes sense. False positives don't waste the security team's budget, and are the only surefire way to justify ongoing expenditures on the scanning tool.

So somehow false positives negate all the actual positives caught and corrected? The only true solution is what? Manual audit of everything by some perfect human security practitioner? I suppose the same applies to automated development tools then. I will concede there probably are some firms out there acting poorly that way. When aren't there? Humans sigh . But by in large automation and the problems inherent are re…

You could set your build up to not auto-download questionable stuff from untrustworthy machines on the Internet.

Re: Log4j: The pain just keeps going

#48

Post by AndrewDucker »

LaGrange wrote: post #35
AndrewDucker wrote: post #4

Earlier quoted context omitted.

Make sure you have the time to patch/update your applications when security issues are raised.

Whoa whoa whoa, slow down, that would mean somebody in the organization would have to spend _valuable senior developer time_ on reading things. Yes, that's jaded, but that's what I'd expect. So far I've yet to feel like a job _encouraged me_ to pay attention to security updates, accessibility standards, or anything like that. And it's quite hard to keep myself motivated to do that, when it's pretty clear most softwar…

You can automate some of this. BlackDuck scans your dependencies (if you're using Maven or similar) to check what versions of dependencies you're using and if there are known CVEs for them. And there are plenty of competitors.

But you still need to patch and test when you find out there's an issue.

Re: Log4j: The pain just keeps going

#49

Post by AndyMcConachie »

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…

The ease with which software remains mutable after deployment is both a blessing and a curse. This is particular and intrinsic to software and other digital artifacts. Things based in matter do not benefit from this blessing or suffer from this curse.
Post reply on HN