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

241–250 of 291 posts

Re: Log4j: The pain just keeps going

#241

Post by staticassertion »

kelnos wrote: post #215
laughingbovine wrote: post #148

Earlier quoted context omitted.

Yeah but you can cache the packages or store them in some fashion. I've seen JAR files in git repos far too many times... With security, you need some online service so you can find the new CVEs every day.

> With security, you need some online service so you can find the new CVEs every day. Or you just do it manually if that service is down. It's weird to me that the argument for not having an automated, 3rd-party service is "if it goes down then you'll have to do things manually", when the alternative is "you always have to do it manually". If you are comfortable trusting a third-party service to tell you when to upgr…

Yeah, honestly there's probably just a few libraries you're going to have to care about re: keeping up to date. Everything else can get updated opportunistically/ on some cadence. Your exposed attack surface for most software is pretty much your TLS library and network stack. The more mature you become the more of the attack surface you can try to track.

But basically if you just subscribe to a few projects' releases you can pretty easily get things pushed to you when it matters.

Re: Log4j: The pain just keeps going

#242

Post by kelnos »

ChrisMarshallNY wrote: post #149
jeroenhd wrote: post #147

Earlier quoted context omitted.

I like the "2-level-dependency" rule, but what do you do when one of your dependencies gains more dependencies? Do you stop updating and start migrating to something else, or maybe maintain a fork of your own? It's a very nice concept, but I kind of have my doubts about maintainability.

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 library as open source.

Sure, I would never write these log4j security-related bugs, because I would never even think to write such obscure functionality into a logging library for my own use.

Regardless: frankly, I think anyone who claims they won't write security bugs... well, that kind of person is probably a bit unrealistic about the flawlessness of own abilities, to put it as politely as possible.

Re: Log4j: The pain just keeps going

#243

Post by Nicook »

kelnos wrote: post #210
xmprt wrote: post #136

Earlier quoted context omitted.

At most companies I've worked for, mentoring and training junior engineers is a requirement for promotion. Also, you might not get promoted for maintenance but 1. keeping it running with a healthy userbase and demonstrating high impact does, and 2. if you know how to spin it, then maintenance work can look like "building new stuff".

> At most companies I've worked for, mentoring and training junior engineers is a requirement for promotion. You've worked for some great orgs, then! My experience is mostly the opposite. One company I worked for did value mentorship, at least somewhat, and it was a factor in promotion decisions, but not mentoring others didn't really stop people from getting promoted.

I think this is more of a "do what I say, and not what I do" thing. Nominally most companies want you to mentor junior devs, but the worker who spends less time on that, and more time on higher visibility work gets the promotion priority.

Re: Log4j: The pain just keeps going

#244

Post by staticassertion »

throwaway23234 wrote: post #67
jsiaajdsdaa wrote: post #55

Earlier quoted context omitted.

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)

Yes, this can pop up in any library. But only because developers aren't taught "don't put remote code execution into your code". You'd think that would be something that someone would teach, but it doesn't really come up. Remember that log4j was vulnerable because of a feature - it all worked as designed.

Re: Log4j: The pain just keeps going

#245

Post by mgsouth »

_dain_ wrote: post #131
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, 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. Capability-based security is one possible answer. The Austral language is trying to make this a first-class language feature: >The problem is that code is overwhelmi…

There are a few issues here...

1. Depending upon context, *any* change to state (network I/O, console I/O, file I/O, environment variables, etc.) is a security vulnerability you can drive a truck through. For example: Foo is a very-locked down package that only appends text to a file the caller owns. It's formally verified to only change the file specified, verified to only append in all possible situtations, verified to not have cross-file-system identity problems, not subject to file renaming race conditions, yada yada yada. Safe? No. "foo('evil_command' '~/.bash.rc')".

2. A useful definition of a "capability" depends upon context. A *dynamic* context. Say Foo is intended to be used for generating log files. There's no way for a third-party library to determine whether the target is actually such a thing. It requires manual tuning which fits the operational context. Perhaps the file must be named "/var/log/${x}.log". Or maybe its "${home}/local/log/${x}.log". Great. Of course, now you've got to verify the context-specific defintions. And verify the tool that does this verification. And the verify the configuration of the tool that does the verification... Safe now? No. Context is *dynamic*. "foo('var/log/evil-hack-attempts.log' '0.0.0.0/0 tried-to-crash-us')", and your other context, the automated blacklisting, locks out the Internet.

3. This gets very complex very quickly. IMHO, configuring Selinux, in a real production environment with real personell, is akin to rolling your own cryptography. Can people learn to do it? Of course. But the same argument applies to writing cryptographic functions. You. Will. Make. Huge. Mistakes.

To be clear, this does not mean that capabilities are useless. It's obviously critical that they exist. However, they ain't magic. You can't "solve security with capabilities." There is a point where throwing more of them at the problem makes things *worse*.

Re: Log4j: The pain just keeps going

#246

Post by danhab99 »

I feel like if we as the open source community would require commit signing we would be in a safer position. Crypto signing doesn't block malware from being introduced, but it would make it harder to sneek under our noses.

Currently in open source, you really don't know where your code is coming from and who worked on it. Git's "commit author" fields don't require any proof of identity, that's what GPG is for.

Re: Log4j: The pain just keeps going

#247

Post by mbreese »

dboreham wrote: post #69
mbreese wrote: post #51

Earlier quoted context omitted.

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.

Of course that’s not automated.

From the parent, it sounded like the their issue wasn’t figuring out if something was a false positive. It was that another “intelligent life form” ran a tool and then wouldn’t accept when another “intelligent life form” assessed that a flag was a false positive.

If the infosec person is just running a tool and reporting results, why are they part of the loop? Make running the tool mandatory for each git push back to the main repo. Then, if/when there is a false positive, allow them to pass if they’ve already been “approved” by some means (like a .infosec_ignore file).

Re: Log4j: The pain just keeps going

#248

Post by pas »

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…

> I really don't like pen testing as a practice

could you elaborate on this a bit? what's wrong with it? to me it seems the only logical thing to spend external security budget on. (or internal red team if the company is so bit it can afford it.)

Re: Log4j: The pain just keeps going

#249

Post by WesolyKubeczek »

kelnos wrote: post #226
WesolyKubeczek wrote: post #130

Earlier quoted context omitted.

The thing about "single file deployment" is that it shouldn't have external requirements, otherwise it's not a single file deployment anymore.

... which is why the parent is (IMO correctly) claiming that the grandparent's assertion is incorrect that a Debian package is a "single file deployment".

I think both grandparent you’re referring to and its parent are lost in the woods.

Re: Log4j: The pain just keeps going

#250

Post by taeric »

kelnos wrote: post #208
taeric wrote: post #170

Earlier quoted context omitted.

I don't see how you have really fixed the break much. Especially if you can "push back" and say no to an update, you are just setting yourself up for when the update is even harder to accept. (That is, the further behind on an update you are, the harder to take it. Typically.) And then there is the "I want the fix, but I don't want the added attack vector of features that comes with it."

Sure, but you're in control, and can decide to do what's best for you and your organization. Taking on the technical debt of allowing your dependencies to get further and further behind isn't a decision I usually make, but it can be a valid one depending on the individual circumstances.

I mean, you aren't wrong. But this is akin to saying you don't need a memory safe language, because you can decide what is best for your applications memory needs.

That is, I think the ask is more of "why haven't we come up with something that is a bit better at mitigating risks, here?"

Post reply on HN