Log4j: The pain just keeps going • Hacker News Board

Re: Log4j: The pain just keeps going

#191

Post by citrin_ru » Wed, Jul 20, 2022, 7:26 PM UTC

pixl97 wrote: post #184

apeace wrote: post #178

Earlier quoted context omitted.

I have a very simple solution, in three parts: 1) We use very few dependencies. We err on the side of writing our own function, library, or UI component rather than installing a new dependency, even if a "better" open-source version might theoretically be available. 2) We use a monorepo. We have two Go backends sharing the same go.mod, and three Typescript/React frontends sharing the same package.json, all in the sam…

>We use very few dependencies. While this may solve the "exploit from 3rd party dependencies" this says nothing about the security quality of your functions. Now instead of the vuln being found in the 3rd party package and fixed, the issue remains in your program forever, probably getting exploited by nation state level actors without your knowledge.

A benefit of writing own functions - you'll not implement something you don't need, which reduces attack surface.

Re: Log4j: The pain just keeps going

#192

Post by preseinger » Wed, Jul 20, 2022, 7:27 PM UTC

0xbadcafebee wrote: post #121

chrisseaton wrote: post #103

Earlier quoted context omitted.

> nearly every Go project in the world having to be patched and recompiled Is that a particular problem? What's the difficulty with recompiling?

Imagine you are a random person in charge of a computer. You hear there's this big vuln affecting Go programs. 1. How do I find out which programs on my system are Go programs? I have a lot of programs scattered all over. Someone will have to come up with a method (probably search through $PATH for files, run `strings` on it, grep for "Go" , pray that's enough) to identify them. 2. They don't list a website, so I hav…

> You hear there's this big vuln affecting Go programs.

This isn't relevant. What's relevant is if any of the specific programs I am responsible for have a vulnerability. If so, I need to update those specific programs. The notion of implementation language, shared library, dependency, these are all abstraction leaks. The atomic unit of responsibility, at the machine level, is program/service.

Re: Log4j: The pain just keeps going

#193

Post by Griffinsauce » Wed, Jul 20, 2022, 7:28 PM UTC

apeace wrote: post #178

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 have a very simple solution, in three parts: 1) We use very few dependencies. We err on the side of writing our own function, library, or UI component rather than installing a new dependency, even if a "better" open-source version might theoretically be available. 2) We use a monorepo. We have two Go backends sharing the same go.mod, and three Typescript/React frontends sharing the same package.json, all in the sam…

> 1) We use very few dependencies. We err on the side of writing our own function, library, or UI component rather than installing a new dependency, even if a "better" open-source version might theoretically be available.

This just means you likely have a lower quality version with the same problems but without the benefit of an ecosystem to find them.

Re: Log4j: The pain just keeps going

#194

Post by Genbox » Wed, Jul 20, 2022, 7:29 PM UTC

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 was wondering when it would become the norm to call it "ducktape". It has been 3 hours and nobody has corrected it. Last week I found a 3-pack of "ducktape" in the builders market.

I'm not making fun of you or trying to be funny - it is simply an observation that I find interesting.

Re: Log4j: The pain just keeps going

#195

Post by wizofaus » Wed, Jul 20, 2022, 7:34 PM UTC

skrtskrt wrote: post #172

aclatuts wrote: post #160

Earlier quoted context omitted.

I find Python is very prone to a lot of breaking changes even with minor version changes. And not just that, even minor versions have to match up specifically with another libraries minor version. It seems to be a community or ecosystem problem with Python, which is why I avoid Python as much as possible. In every other ecosystem when minor version are updated there are very rarely issues, and there are little issues…

eh, people love to break stuff on minor version changes of Go libraries to

At least you find out at compile time...

Re: Log4j: The pain just keeps going

#196

Post by na85 » Wed, Jul 20, 2022, 7:34 PM UTC

Genbox wrote: post #194

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 was wondering when it would become the norm to call it "ducktape". It has been 3 hours and nobody has corrected it. Last week I found a 3-pack of "ducktape" in the builders market. I'm not making fun of you or trying to be funny - it is simply an observation that I find interesting.

Where I live there's a brand of duct tape called Duck Tape. It's terrible compared to the 3M brand tape, but it's cheap so it's popular.

Also nobody that knows what they're doing uses "duct tape" on ducts, so the name is pretty meaningless.

Re: Log4j: The pain just keeps going

#197

Post by upupandup » Wed, Jul 20, 2022, 7:37 PM UTC

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.

but the cost of rewriting everything that you are currently using through dozens of dependencies and third party libs you are going to go broke.

Unless you have the budget like the DOD which has its own coding language I believe, you are ngmi

Not to mention you would be introducing attack surfaces that wont have enough attention because its only being used by your team.

At least with a widely used lib, vulnerabilities are caught, published (very important) and constantly raising vigilence. here you would have to perform your own threat mitigation and have bounty programs.

Re: Log4j: The pain just keeps going

#198

Post by pixl97 » Wed, Jul 20, 2022, 7:39 PM UTC

ClumsyPilot wrote: post #112

leeoniya wrote: post #109

Earlier quoted context omitted.

> 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.

but then someone builds a bank on top of this abstraction, and sorts of shit hits the fan.

Working in the industry I do, there are a number of banks I will never used based on the terrifying lack of quality in the software they write. The SBOM on these projects could be printed out and bound as a dictionary there are so many packages included.

Re: Log4j: The pain just keeps going

#199

Post by pixl97 » Wed, Jul 20, 2022, 7:39 PM UTC

citrin_ru wrote: post #191

pixl97 wrote: post #184

Earlier quoted context omitted.

>We use very few dependencies. While this may solve the "exploit from 3rd party dependencies" this says nothing about the security quality of your functions. Now instead of the vuln being found in the 3rd party package and fixed, the issue remains in your program forever, probably getting exploited by nation state level actors without your knowledge.

A benefit of writing own functions - you'll not implement something you don't need, which reduces attack surface.

Until your developer decides to write their own encryption routines.

Re: Log4j: The pain just keeps going

#200

Post by hinkley » Wed, Jul 20, 2022, 7:41 PM UTC

agumonkey wrote: post #144

hinkley wrote: post #134

Earlier quoted context omitted.

When I worked on a code signing app, which is arguably some of the highest stakes of almost anything I've worked on, we came around to an agreement that one ticket a month would be assigned to upgrade libraries, and we rotated that responsibility. We didn't stipulate what library, we didn't even stipulate which application in the suite (though it was assumed that you were likely to chose your primary application as t…

> we rotated that responsibility how did that go ? I often wanted to do it but never got to submit the idea.

A couple didn't get it, a few chose things we might not have picked, but that was fine because sooner or later having 'dumb' out of date dependencies adds up to real problems.

It also took some reminders from the leads to add it in instead of letting it slip, but so far it's the least broken process I've gotten to use.