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

251–260 of 291 posts

Re: Log4j: The pain just keeps going

#251

Post by rtev »

beAbU wrote: post #235
horsawlarway wrote: post #78

Earlier quoted context omitted.

I was in this industry for a while (I did 5 years full time for a security company). > I will concede there probably are some firms out there acting poorly that way. This is a hilarious take. Here's mine: The vast majority of these firms are here for liability. They do not provide security, they provide security theater so that if/when something goes wrong, the client can claim to have followed best practices, and th…

My project's client, a major local bank, mandates pen testing before we go live with the product that we're building. Due to time and resourcing constraints, and a fixed launch date (don't ask), we had to significantly reduce scope. We are currently launching with probably 30% of the original scope. Once live we'll iterativley add features and grow our product to bring it back to the original vision. Will we have to…

What you’ve described is an issue with the bank’s procedures, not pentesting.

Re: Log4j: The pain just keeps going

#252

Post by SamuelAdams »

secabeen wrote: post #221
Kalium wrote: post #209

Earlier quoted context omitted.

> 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 paradigm, but people in our industry seem to be only doubling down. On the contrary, I believe we do. The answer is ongoing maintenance . The basic problem is that people persist in looking at software as a fundamentally mechanistic…

So then what do you do with software that doesn't meet this standard? Software that works, that meets a need you have, but that is a fixed artifact, or at least will be in the foreseeable future. Do you refuse to use said software, and instead choose a less useful alternative that is actively developed?

We see this all the time in healthcare. MRI imaging machine that cost 500k 20 years ago still works fine but only on Windows XP. Cost to rewrite the software for windows 10 is more than 500k so rather than paying for that instead they firewall the shit out of it so it can only talk to some printing / output device.

That’s just one example. Medical machines are expensive as hell and companies don’t want to rebuy or constantly invest in something that works and does one thing well.

Re: Log4j: The pain just keeps going

#253

Post by leeoniya »

kelnos wrote: post #211
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.

I think we should acknowledge, though, that not all abstractions are created equal. Abstractions that hide implementation details and allow people to change those implementation details without creating churn and extra work for their downstream consumers are good. Abstractions that paper over problems that you are unwilling or undisciplined enough to tackle properly are usually bad. I think the grandparent was talkin…

> Abstractions that paper over problems that you are unwilling or undisciplined enough to tackle properly are usually bad

some abstractions carry decades of legacy (e.g. linux file-system hierarchy), and cannot simply be replaced. things that did not connect to the non-existent internet did not have to paper over problems that simply could not exist at that time (VMs, multi-user, multi-tenant hardware). there is plenty of deep software dependencies that are no longer maintained which still rely on these abstractions and cannot be cheaply/reasonably replaced in the field. sure, we have new abstractions since then, but only new and actively maintained software can ever make use of them, and that will only end up in systems that are also actively maintained instead of simply continuing to work with exactly zero effort.

Re: Log4j: The pain just keeps going

#254

Post by ChrisMarshallNY »

kelnos wrote: post #242
ChrisMarshallNY wrote: post #149

Earlier quoted context omitted.

I use my own dependencies. I've written many of them. Some of them, go "deeper," but only in dependencies that I authored. Here's the dependency manifest from the app I'm working on now (From my localization file): // MARK: - // MARK: - DO NOT TRANSLATE BELOW THIS LINE - // MARK: - "SLUG-VERSION-BMLT" = "BMLTiOSLib: 1.4.2"; "SLUG-VERSION-KEYCHAINSWIFT" = "KeychainSwift: 20.0.0"; "SLUG-VERSION-LGVCLEANTIME" = "LGV_Cle…

The problem I have with adopting something like this is that (other than the added time it would take to write and maintain all my own dependencies), I don't trust myself to avoid writing the same kinds of security bugs that a third-party dependency might also write. But those bugs are much more likely to be discovered and fixed in the widely-used third-party library than in my bespoke library, even if I publish that…

I don't claim to "never write security bugs."

However, it appears that the norm in the industry, is to write lash-up code, as quickly as possible, in the hopes on an MVP that will get brought up by a FAANG.

And I am doubtful that most OSS actually gets all that "other eyeballs vetting" that everyone talks about. Most folks that I know, that use a lot of these dependencies, would be unable to understand what goes on in them, let alone offer fixes.

In fact, I remember a founder, on this very forum, declare that "If you don't get physically sick, looking at your MVP code, then you are spending too much time on code quality."

That posture doesn't exactly inspire confidence. I'm pretty good at what I do, and I tend to "overengineer" my security-related stuff, because I don't really have huge confidence in that. It's not my forte.

But writing good code, is something that I can do.

Like I said, WFM. YMMV.

Re: Log4j: The pain just keeps going

#255

Post by EdwardDiego »

throwaway23234 wrote: post #70
wyager wrote: post #53

Earlier quoted context omitted.

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

Java person here. Yeah, Go looks a bit crufty, but they're gradually undoing the earlier opinionated choices that make me think that (Who needs generics? Who needs to tune the GC? Oh, our users do), but nah, we mainly hate on Scala when we have to maintain anything with Scala deps, just that damn ABI that's never compatible.

Re: Log4j: The pain just keeps going

#256

Post by bradgessler »

SamuelAdams wrote: post #252
secabeen wrote: post #221

Earlier quoted context omitted.

So then what do you do with software that doesn't meet this standard? Software that works, that meets a need you have, but that is a fixed artifact, or at least will be in the foreseeable future. Do you refuse to use said software, and instead choose a less useful alternative that is actively developed?

We see this all the time in healthcare. MRI imaging machine that cost 500k 20 years ago still works fine but only on Windows XP. Cost to rewrite the software for windows 10 is more than 500k so rather than paying for that instead they firewall the shit out of it so it can only talk to some printing / output device. That’s just one example. Medical machines are expensive as hell and companies don’t want to rebuy or co…

I was visiting my parents this summer and they have a Gameboy from 1991 with a Tetris cartridge, which was authored in 1989. They use it regularly and it still works! For over 30 years this device has played Tetris without requiring any software updates.

Re: Log4j: The pain just keeps going

#257

Post by EdwardDiego »

cmckn wrote: post #218
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 can't reasonably fork the entire dependency just to remove that one sub-dependency from our project's dependency If you use Maven, just exclude that transitive dependency from the explicit dependency. But yeah, dumb warnings are dumb. com.example my-dependency org.slf4j slf4j-log4j12

Bingo.

Re: Log4j: The pain just keeps going

#258

Post by EdwardDiego »

twic wrote: post #216
layer8 wrote: post #165

Earlier quoted context omitted.

> Then apache decides to put new people on log4j, do a backward incompatible v2 design that nevertheless is worse than slf4j. Why? Because the original Log4j author wanted to do his own thing for a Log4j successor (slf4j/logback), and the Apache Log4j maintainers also had ideas about a next-gen framework and wanted to do that. That’s Open Source, everyone can do their own thing if they like, and some things will get…

I use java.util.logging in a few apps, to cut down on dependencies, and i consider it to be fairly braindead. The fundamentals are okay, to the extent that they are copies of log4j, but there are a bunch of little things that just aren't done right, like: - logging methods taking arrays rather than varargs (this would be a trivial change!) - there being no way to create a SimpleFormatter with a custom format in code…

- the console appender writes to stderr.

Re: Log4j: The pain just keeps going

#259

Post by overgard »

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…

Ok, so what is the solution then? To me there isn't one. It's like, how do you prevent all car accidents? The only way would be to ban driving.

Re: Log4j: The pain just keeps going

#260

Post by aahortwwy »

SomeCallMeTim wrote: post #117
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…

>"Use a build tool to do dependency checks!" > >And then what? > >"Only update libraries if they have vulnerabilities." > >So, should this be a manual process where I have to dig through obscure warnings every time I build something? > >"No, you can automate it!" > > Congrats, you've just outsourced the decision making process about which versions of libraries to use to some 3d party. You've also made your build proc…

> If I don't think the change is worth it or the vulnerability is relevant, I can go to the Snyk site and mark a vulnerability to be ignored, or even tell it to ignore it for a month or whatever.

I am currently fighting with our security team because they refuse to allow developers to do this, and instead require my team to file tickets with their team, wait hours for that ticket to be picked up, explain why a thing is a false positive to a person who doesn't understand the codebase they're working on, and hope that person feels that the finding should be ignored.

I do not work at a large company.

This is greatly exacerbated by the fact that Snyk - like all package scanners - primarily flags false positives. When you start digging in to what it flags you'll find that a lot of the vulnerabilities aren't reasonably exploitable, or the impact is questionable, or you can't repro the issue. Those that do legitimately affect the underlying library often don't affect your usage of that library. I'd estimate our false positive rate is >90%. So when we get a finding our options are to go through that costly and disruptive process I mentioned above, or just upgrade the dependency (which carries associated risk of breaking shit in production).

These tools emphasize the quantity of findings they produce, and quietly ignore the quality. As soon as you have any divergence in motivations or incentives between the people running the scanner and the people being blocked by the scanner those low quality findings become incredibly costly.

Post reply on HN