Third High Severity CVE in Log4j Is Published • Hacker News Board

Re: Third High Severity CVE in Log4j Is Published

#331

Post by butlerm » Thu, Dec 23, 2021, 7:22 PM UTC

xyproto wrote: post #175

jiggawatts wrote: post #88

Earlier quoted context omitted.

I lay any blame squarely at the feet of IT security of large organisations that were entirely unprepared to update a widely used dependency that wasn't an operating system or a runtime. Windows, Linux, Java, and .NET are all commonly updated, but "modules" aren't. This wasn't just a predictable scenario, it was predicted. Or more accurately, it has occurred already repeatedly in the NPM ecosystem, but for some myster…

You can make dynamically linked executables with both Go and Rust. The compilers have no blame in this.

Sure. But you have a slight problem with ABI stability, at least in Rust, if you ever want to compile an ABI compatible replacement library. Until that problem is resolved, if you want to make a useful replaceable object you need to make a C style foreign function interface and use that, something that isn't exactly convenient for Rust to Rust use, even if rather helpful for making Rust libraries usable from other languages. C++ has a very similar issue, and has had it for years, albeit one mostly resolved by the advent of stable C++ ABI standards.

Re: Third High Severity CVE in Log4j Is Published

#332

Post by pabs3 » Fri, Dec 24, 2021, 9:38 AM UTC

yawaramin wrote: post #309

pabs3 wrote: post #223

Earlier quoted context omitted.

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 t…

The git commit hash is less accurate, since it includes extra files like README.md that aren't converted to any part of the executable.

Re: Third High Severity CVE in Log4j Is Published

#333

Post by pabs3 » Fri, Dec 24, 2021, 9:39 AM UTC

Too wrote: post #237

pabs3 wrote: post #223

Earlier quoted context omitted.

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.

That doesn’t provide a link back to the source, unless you store that hash elsewhere. Giving you the problem of maintaining a database also.

You store the source packages alongside the binary packages, and then index hashes of all the source/binary package contents. Then you know which source files were used from which source/binary packages to produce a particular executable.

Re: Third High Severity CVE in Log4j Is Published

#334

Post by tekknik » Fri, Dec 24, 2021, 2:01 PM UTC

ashtonkem wrote: post #320

tekknik wrote: post #317

Earlier quoted context omitted.

Ok? One you need to disable debug logging and two I still don’t see a problem with that amount of data. You also don’t need to keep logs more than a month or so. How much log data do you think cloudwatch and the other majors filter per hour? much more than terabytes.

Log emission can often have a negative impact on performance, especially since peak logs and peak traffic tend to coincide. I’ve seen P95 latencies suffer just because of logs. > How much log data do you think cloudwatch and the other majors filter per hour? How much do you think the major providers pay for that infrastructure per hour, and are you willing to shoulder that cost too? (Hint: log ingestion is $0.50 per…

> Log emission can often have a negative impact on performance, especially since peak logs and peak traffic tend to coincide. I’ve seen P95 latencies suffer just because of logs.

Only if the emissions of said logs is doing more than stdout or fs writing and it’s not done in another thread.

> Log emission can often have a negative impact on performance, especially since peak logs and peak traffic tend to coincide. I’ve seen P95 latencies suffer just because of logs.

Yes and you need to fix that terabyte per hour garbage as that is well beyond typical for a single service. We’re also talking about java so 7000 page stack traces is where i’d start…

Re: Third High Severity CVE in Log4j Is Published

#335

Post by mtrower » Tue, Dec 28, 2021, 12:36 AM UTC

pabs3 wrote: post #328

spc476 wrote: post #231

Earlier quoted context omitted.

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.

... hear back from upstream that your fix, developed against version X (that you pinned and use), does not apply to HEAD. Pull HEAD and realize there have been major changes which conflict with your platform, use case, or any number of your other dependencies.

Sometimes you can get away with just depending, and that’s nice, but other times there are strong reasons to embed. At that point, you own the code, and can actually do the things you need to do. (Of course, it follows that you own the code - and need to then actually do the things you need to do.)

Both approaches have their advantages, and both have potential for technical debt. Which approach offers the most advantage for the least debt will depend on the individual circumstance; I don’t feel that you can really advocate for one over the other in a general sense.