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

321–330 of 335 posts

Re: Third High Severity CVE in Log4j Is Published

#321

Post by emn13 »

kitd wrote: post #241
jiggawatts wrote: post #228

Earlier quoted context omitted.

This happened last week, for real with ${dayjob} customer. Put yourself in their shoes for a second. Imagine you are Mr SecOps guy, and you've just ran some sort of Log4j tool across literally three thousand servers . Of those, several hundred came back positive. Those included about a dozen flavours of Linux, a smattering of manually built(!) containers, and every version of Windows from 2008 R1 to 2022. Most of the…

So what you have now is literally just a string to a path, something like "D:\apps\foo\bar\baz\libs\stuff\thingie\log4j-core.jar" or the Linux equivalent. Now what? The remediation (until you can get an update from the vendor) is to remove the JndiLookup.class file from that jar. It's been fairly well publicised, as has the way to do it.

This generalizes to "apply a vulnerability-specific tricky auto-fix to a binary it was never tested on". That might be a reasonable solution if there's nothing better (and since speed is of the essence, there might not be). But it's not exactly a reliable solution, and not every vulnerability will have hacks like that available, nor is it really clear to what extent they fix the problem; it's pretty easy to miss something using this kind of approach, or to have some future deploy bot restore the vulnerability in normal operation. And hacks like this can break things, both directly (the patch breaks actually used functionality unexpectedly), and indirectly (the fact that the software was patched at all breaks sanity checks or other cleverness like binary diffing or whatever).

I can't see how this is going to work as a strategy. Ad hoc cleverness? Sure, and that's always good to have when you're smart and lucky enough to pull it off. But it'd be nice to have a strategy that works without relying on being smart, willing and able to engage with tricky ad hoc solutions, and somewhat lucky.

Re: Third High Severity CVE in Log4j Is Published

#322

Post by emn13 »

tekknik wrote: post #270
l5ymep wrote: post #115

Earlier quoted context omitted.

Convincing project managers to tackle tech debt is hard enough. Contributing to open source won't even reach the middle ear unfortunately.

Let’s not even get legal involved…

Don't worry, legal will answer a completely different question that's unrelated, but rests on a fundamental misunderstanding of the entire premise due to a combination of misinterpreting technical jargon as plain English and then misapplying a legal generalization, resulting in absolutely essential advice that needs to be followed immediately, which is couched in legalese that the techs will proceed to misunderstand by misinterpreting legal jargon as plain English in combination with a misapplied technical generalization, resulting in an absolute quagmire when it turns out that these essential compliance steps turn out to have a minor impact on the next quarter's bottom line. Thus some even more obtuse interpretation will be dreamed up by some manager to claim CYA without hurting the bottom line (or addressing the reinterpretation of the reinterpretation of the reinterpretation of the original issue). The issue will be resolved, pending small details like the actual legal risk and technical issues, and all will be fine.

But just be be sure, we should ask legal!

Re: Third High Severity CVE in Log4j Is Published

#323

Post by jsmythe45 »

I was pretty horrified to learn that log4j makes network calls, was even surprised to hear it parses log strings.

Fortunately our log4j was too old and JVM too young to be vulnerable to the first exploit, but it seemed best to rip out log4j and replace it with something simpler anyway.

java.util.logging seemed the obvious choice, but the API is different, so would have been a lot of s/debug/fine and so on.

In the end, we:

- wrote a new class with the same 'api' as the part of log4j that we use

- globally replaced 'import org.apache.log4j.Logger' with our new class

- fixed any compile errors by adding new methods to our class

- wrote a test to make sure it rolled correctly and could handle lots of threads etc.

Here's the code if you want to do something similar (don't know how long it will be accessible from there): https://ideone.com/XKg5M9>

Re: Third High Severity CVE in Log4j Is Published

#324

Post by samhw »

ahtihn wrote: post #147
samhw wrote: post #48

Earlier quoted context omitted.

Up until the semicolon, this was actually a decent point. I can see a future for high-quality open-source software hosted on an 'app store' which requires a small payment for use - or for commercial use, perhaps.

And how are you going to prevent someone from just hosting a mirror for free?

That's the question that such an effort would have to solve. I think you're assuming a model where software is directly used by an individual consumer, though, which is not always the case. For commercial applications where your software is integrated into the end product, for instance, companies would never risk stealing unlicensed code considering the risk. How one would address the question you posed is entirely dependent on the domain one's operating in.

Re: Third High Severity CVE in Log4j Is Published

#325

Post by samhw »

ksaj wrote: post #85
samhw wrote: post #46

Earlier quoted context omitted.

> The uncomfortable truth is these libraries need scratch rewrites with better authors. If that's true, do you think that having money might possibly be helpful to that effort?

One of the maintainers in question holds two jobs to live. Having money might allow him more time to test and retest and update the software more expediently.

Sorry, I was posing that question semi-sarcastically. I agree it's blindingly obvious to any sensible person that money would help immensely. However, sadly, there are apparently plenty of people who are just about sensible enough to be able to get out of bed and navigate to this site, but not sensible enough to understand much else.

Re: Third High Severity CVE in Log4j Is Published

#326

Post by AtNightWeCode »

jacquesm wrote: post #319
AtNightWeCode wrote: post #313

Earlier quoted context omitted.

Maybe it is not handled the same way depending on where you operate from but where I live you are supposed to report any potential data leak of GDPR sensitive data to the local authorities. I do not know what the criteria is that makes you end up being questioned about it though. I been at such meetings over silly things.

The reporting requirements are the same all over Europe, it's a 'better safe than sorry' mechanism put in place after companies routinely wiped their data breaches under the rug in the hope that nobody would notice. Once you get to that stage there can be a follow up to gather more information, and that follow up then usually results in some advice or no further action. In rare cases - typically the ones where gross…

At companies I worked with repute is key. Companies with employee count in the range of 10 to 50k. The legal departments will report any potential breach. As a developer you can decide what is logged but not much about anything else in the business. You as a developer or tech lead will most likely be held accountable.

Re: Third High Severity CVE in Log4j Is Published

#327

Post by lazide »

staticassertion wrote: post #310
lazide wrote: post #305

Earlier quoted context omitted.

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?

It was impossible to fix because it was a compiled binary with no available source. That’s the point.

Re: Third High Severity CVE in Log4j Is Published

#328

Post by pabs3 »

spc476 wrote: post #231
pabs3 wrote: post #222

Earlier quoted context omitted.

Bundling/embedding/vendoring/monorepos and other names for embedded code copies really need to stop being common practice in the tech world.

What should be done instead?

Depend on your dependencies instead of embedding them. Specify version ranges instead of pinning dependencies. Report issues in your dependencies and contribute back fixes for them.

Re: Third High Severity CVE in Log4j Is Published

#329

Post by to11mtm »

cutemonster wrote: post #297
to11mtm wrote: post #206

Earlier quoted context omitted.

Egress is a very fair question IMO. I've worked at more than one place where Infosec would start integration talks at 'What are the static IPs and how do we rotate certs' Every layer you go lower (longer certs, domain whitelisting vs static IPs, etc.) is a tradeoff of maintenance and security. > What these applications are supposed to connect to are likely unknown. This is a major problem at enterprises Only if they…

I suspect that a manager that suggested / insisted on such properly staffed teams, would get fired or no longer promoted, at most big companies. Since it'd cost a lot, and not show any results the nearest time / years. And also, they might hire the wrong people, and just burn money for nothing > Simple, if brutal solution ... properly staffed teams The recruitment part is not simple, maybe bordering to impossible? fo…

> and not show any results the nearest time / years.

Depends on how you game OKRs. Implement auditing Q1. Contact all teams Q2. Have 75% of teams Q3. 90% of teams Q4. Just an example but its all in how you sell it. Big IT understands icebergs, you just have to give a good/accurate roadmap and execute if they agree on it.

You might be correct that a lack of insight on this sort of thing is an organizational problem. My experience indicates that if you can't get a list of dependencies based on a series of e-mails down an org chart, something is wrong. Either someone is managing too many services for the level of tooling you have, or there's a complete breakdown in org comms (which happens more in larger enterprises.)

Re: Third High Severity CVE in Log4j Is Published

#330

Post by cutemonster »

to11mtm wrote: post #329
cutemonster wrote: post #297

Earlier quoted context omitted.

I suspect that a manager that suggested / insisted on such properly staffed teams, would get fired or no longer promoted, at most big companies. Since it'd cost a lot, and not show any results the nearest time / years. And also, they might hire the wrong people, and just burn money for nothing > Simple, if brutal solution ... properly staffed teams The recruitment part is not simple, maybe bordering to impossible? fo…

> and not show any results the nearest time / years. Depends on how you game OKRs. Implement auditing Q1. Contact all teams Q2. Have 75% of teams Q3. 90% of teams Q4. Just an example but its all in how you sell it. Big IT understands icebergs, you just have to give a good/accurate roadmap and execute if they agree on it. You might be correct that a lack of insight on this sort of thing is an organizational problem. M…

Sounds interesting, but what does "Have 75% of teams Q3" mean?
Post reply on HN