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

61–70 of 291 posts

Re: Log4j: The pain just keeps going

#61

Post by voxl »

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…

And what would you have anyone do?

You could formally spec software and implement it, congrats you're now 1000x slower to market and any change you want to make is another 1000x investment to spec out and prove.

And let's not even mention the ridiculous idea that open source developers be expected to do this. Moreover, this doesn't even handle hardware problems!

Okay, but we could just build all the software internally, reinvent all the wheels. But how is this any better? Now you have even less manpower to fix bugs and you're probably 100x slower to market because you're building all these half baked, bug ridden libraries.

If anything, the best idea is formally verified sandboxing, so that you have strong assurances about certain apps not doing bad stuff, but this doesn't solve all problems either.

It's an unsolvable problem in general, which is why no one has solved it.

Re: Log4j: The pain just keeps going

#62

Post by Beltalowda »

commandlinefan wrote: post #34
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…

> seems like there's no solution There is - don't depend on anybody else's software. It just means that software development will take longer and cost more.

This assumes that your own software is more secure.

Re: Log4j: The pain just keeps going

#63

Post by allochthon »

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…

Typically there's a way to suppress specific warnings in systems like these. In your company's situation, I would look at moving away from a scanning system if it didn't allow overrides like this.

Re: Log4j: The pain just keeps going

#64

Post by qw »

hedora wrote: post #24
bgro wrote: post #16

When are they going to release Log5j? Or even Log4k to address these issues?

The log4j author already did this about a decade ago. No one could understand log4j back then, so the replacement is much, much simpler, and API compatible for 99+% of use cases. Few projects seem to have bothered moving to it, probably becuase log4j is such a collosal pain to set up or modify.

I think Spring Boot defaults to Logback these days.

Re: Log4j: The pain just keeps going

#65

Post by pclmulqdq »

voxl wrote: post #61
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…

And what would you have anyone do? You could formally spec software and implement it, congrats you're now 1000x slower to market and any change you want to make is another 1000x investment to spec out and prove. And let's not even mention the ridiculous idea that open source developers be expected to do this. Moreover, this doesn't even handle hardware problems! Okay, but we could just build all the software internal…

It takes a lot longer to build houses that are up to building codes, and bridges that have 10x safety factors rather than 2x. There's a reason we have building codes and large safety factors. Software engineers are discovering this today.

Re: Log4j: The pain just keeps going

#66

Post by dboreham »

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…

Same experience several times. Tool picks up examples code dependencies from our dependencies is another form of this.

Re: Log4j: The pain just keeps going

#67

Post by throwaway23234 »

jsiaajdsdaa wrote: post #55
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…

Better idea: stop logging.

the issue is that this can pop up in any library, not just logging. It's about keeping your deps up to date (or not) by a "3d party" (assuming he mean 3rd party)

Re: Log4j: The pain just keeps going

#68

Post by thechao »

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…

I hired a guy because he loves to be (technically) correct about everything, and he does so by reading (and REREADING) specs. Gives my team a superpower.

Re: Log4j: The pain just keeps going

#69

Post by dboreham »

mbreese wrote: post #51
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…

It sounds like some of this should be automated. If all the infosec person is doing is running a tool against a repo and reporting results, that should be automated. When there are false positives, that should be annotated in the repo with multiple people checking off on it. I’ve been impressed by automated bug checking tools in the past and I see this as part of the same issue. I don’t see why this would need an FTE…

It's the "intelligent life form determines the alert is a false positive" part that's not automated.

Re: Log4j: The pain just keeps going

#70

Post by throwaway23234 »

wyager wrote: post #53
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 current software engineering paradigm has no meaningful answer to this The answer is to stop using garbage software written in garbage languages. Of course the current environment is too high-time-preference for this to be economical in many industries. We have lightweight-to-heavyweight formal systems which can almost completely or literally completely eliminate issues of the type seen with log4j, but due to t…

What counts as a garbage language? Java guys will tell you it's rust or go, go guys will tell you it's java or rust, rust guys will tell you it's java and go.
Post reply on HN