Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Third High Severity CVE in Log4j Is Published

logging.apache.org

Post reply on HN
Print view View original

301–310 of 335 posts

Re: Third High Severity CVE in Log4j Is Published

#301

Post by rocqua »

staticassertion wrote: post #259
rocqua wrote: post #257

Earlier quoted context omitted.

It is! But a lot of ops departments have problems! OPs point is that a lot of deployments out there make it really hard to remediate this kind of vuln. Moreover he is arguing that java, as opposed to fat binaries with potentially stripped symbols, made things solvable. He fears that many companies would be much worse off with a big vulnerability in e.g. a rust crate.

Yes, some places suck. They're going to suck either way. If their system is so backwards that they need to manually patch services because everything is EOL, and compiled code will break their workflow, they have plenty of other shit to deal with. I don't think we should optimize for garbage companies with garbage practices.

I'd say places lie on a spectrum of sucking. With a lot of places being very important and far from perfect. Those places really should get good security. That means designing for security in the common situation rather than the situation of 'best practices'.

I think we should optimize security for say the 80th percentile company as far as not following best practices (i.e. 80% of companies have better practices than what I suggest targeting).

Re: Third High Severity CVE in Log4j Is Published

#302

Post by jethro_tell »

lazide wrote: post #233
staticassertion wrote: post #219

Earlier quoted context omitted.

Presumably you would go ask Oracle, and then patch it when they provide a patch.

Hope you’ve got a pretty sweet support contract or you’re going to be waiting awhile. Depending on the product, maybe forever.

Why would you have oracle without a super sweet support contract? That's the whole point.

Re: Third High Severity CVE in Log4j Is Published

#303

Post by staticassertion »

rocqua wrote: post #301
staticassertion wrote: post #259

Earlier quoted context omitted.

Yes, some places suck. They're going to suck either way. If their system is so backwards that they need to manually patch services because everything is EOL, and compiled code will break their workflow, they have plenty of other shit to deal with. I don't think we should optimize for garbage companies with garbage practices.

I'd say places lie on a spectrum of sucking. With a lot of places being very important and far from perfect. Those places really should get good security. That means designing for security in the common situation rather than the situation of 'best practices'. I think we should optimize security for say the 80th percentile company as far as not following best practices (i.e. 80% of companies have better practices than…

In no way is manually writing a patch and then live patching the common situation.

The vast majority of cases, and this has been the case for decades, will be that you take responsibility for your own dependencies, and you let your vendors take responsibility for theirs.

Re: Third High Severity CVE in Log4j Is Published

#304

Post by lazide »

yjftsjthsd-h wrote: post #245
lazide wrote: post #234

Earlier quoted context omitted.

How does your company handle coffee? Surely there is SOME mechanism for small incidental charges, or how could your company even exist?

Coffee company sends a monthly invoice.

So no Starbucks with a client on sales calls I guess?

Re: Third High Severity CVE in Log4j Is Published

#305

Post by lazide »

staticassertion wrote: post #258
jiggawatts wrote: post #249

Earlier quoted context omitted.

> generally not something companies take responsibility for I have some bad news for you: viruses and hackers don't care about your support contracts and the delays they cause. Actually, I tell a lie: the hackers love them.

That's not relevant? The original premise here is "compiled languages will make things worse because they're harder to patch" except: a) It's very rare to patch things manually b) It's very rare to develop patches yourself (for 3rd party software) I'm sure some companies out there with many decades old deployments have to do stupid shit like that, but it's hardly the standard.

Having been on the receiving end of waiting a long time to get a patch for a actively being exploited zero day - the point is, even if you want to fix it yourself (which I desperately did), you can’t.

If it’s some important piece of software you also can’t stop or the business stops - well, you and everyone else is just going to take it in the pants.

Many enterprises are in exactly this bind. And support contracts only get you so far.

Re: Third High Severity CVE in Log4j Is Published

#306

Post by lazide »

jethro_tell wrote: post #302
lazide wrote: post #233

Earlier quoted context omitted.

Hope you’ve got a pretty sweet support contract or you’re going to be waiting awhile. Depending on the product, maybe forever.

Why would you have oracle without a super sweet support contract? That's the whole point.

People don’t get Oracle because they want to get stuck with a super expensive (and still only ok), or super insanely expensive (and maybe sweet) support contract. They get it because they usually don’t know about these things, are trying to do something and BLAM they get hooked.

Many people don’t even realize how long it can take to get a real issue fixed even with a super sweet support contract. For instance, I once was a wet behind the ears Oracle DBA, and when creating a schema i dumbly used a feature in the documentation without checking to see how long it had been released. Unfortunately, it had been released about 6 months before, as I found out later.

It took 6 months for them to figure out that it was the cause of our sporadic ORA600 errors (aka core dumps), by which point we’d already migrated to MySQL for many of the workloads because the database was having at best 95% reliability because of it.

Once we migrated the table off with the feature, somehow our problems ceased, but that was still well before they told us what was going on.

Re: Third High Severity CVE in Log4j Is Published

#307

Post by lazide »

marcosdumay wrote: post #291
lazide wrote: post #235

Earlier quoted context omitted.

How is your logging system going to get that new configuration without restarting if it doesn’t support dynamic reconfiguration?

Why is there any problem in restarting your logging system? There is nothing in a logging system that could be harmed by a restart. Restarting it is exactly how you should handle changes, because it deals with plenty of stuff that isn't reconfigurable on a lower level. The only way to make a "reconfigurable" logging system is by having a stable facade that restarts everything behind it. But that extra layer does not…

If you turn on debug logging to see why somewhere weird is happening, and the only way to do that is to completely restart the entire system - good luck figuring out why a large class of weird things happen!

Re: Third High Severity CVE in Log4j Is Published

#308

Post by jacquesm »

AtNightWeCode wrote: post #256
jacquesm wrote: post #82

Earlier quoted context omitted.

This has absolutely nothing to do with the GDPR. In fact, the GDPR and various data retention laws are at odds with each other which is why the GDPR has a very explicit exemption for this.

Not sure what you are answering. If you for instance expose an endpoint by accident and then can't show logs for the access to it, you are going to have a problem in one of those GDPR hearings. The irony of GDPR is that you may end up with more logging of user data, not less.

Explain 'one of those GDPR hearings'. I'm pretty familiar with the GDPR and everything that comes with it, I've never even heard of the term 'GDPR hearing'.

Re: Third High Severity CVE in Log4j Is Published

#309

Post by yawaramin »

pabs3 wrote: post #223
yawaramin wrote: post #136

Earlier quoted context omitted.

Go 1.18 onwards will solve this problem: https://utcc.utoronto.ca/~cks/space/blog/programming/GoVersi... > The go command now embeds version control information in binaries including the currently checked-out revision and a flag indicating whether edited or untracked files are present.... Additionally, the go command embeds information about the build including build and tool tags (set with -tags), compiler, assemble…

So if you make a commit to the README.md fixing a typo, now your build of the source code has a different checksum? I wonder why they don't instead hash all the source files and then embed that hash.

> So if you make a commit to the README.md fixing a typo, now your build of the source code has a different checksum?

Yes...? What's the problem?

> why they don't instead hash all the source files and then embed that hash.

This is almost exactly what the git sha is. If you're arguing that README.md files shouldn't be included in the checksum, that's subjective. Many people would argue otherwise. And it doesn't hurt to be more accurate than less.

Re: Third High Severity CVE in Log4j Is Published

#310

Post by staticassertion »

lazide wrote: post #305
staticassertion wrote: post #258

Earlier quoted context omitted.

That's not relevant? The original premise here is "compiled languages will make things worse because they're harder to patch" except: a) It's very rare to patch things manually b) It's very rare to develop patches yourself (for 3rd party software) I'm sure some companies out there with many decades old deployments have to do stupid shit like that, but it's hardly the standard.

Having been on the receiving end of waiting a long time to get a patch for a actively being exploited zero day - the point is, even if you want to fix it yourself (which I desperately did), you can’t. If it’s some important piece of software you also can’t stop or the business stops - well, you and everyone else is just going to take it in the pants. Many enterprises are in exactly this bind. And support contracts on…

I'm losing your point. So, you wanted to patch it, and you couldn't, so how is it bad then that a compiled binary would make patching more difficult?
Post reply on HN