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

Re: Third High Severity CVE in Log4j Is Published

#271

Post by svieira » Sun, Dec 19, 2021, 12:28 PM UTC

darkr wrote: post #102

UncleMeat wrote: post #93

Earlier quoted context omitted.

Would more funding have actually uncovered this?

Not in and of itself.. However if part of that funding was used to cover formal (external) audits, investment in fuzzing/automated security testing etc.. then it might well have done

"Might have" is the operative word. In a world where Project Zero's _This shouldn't have happened_ [1] was also published this month (buffer overflow on NSS), I'm less certain. Quoted from the article:

---- This wasn’t a process failure, the vendor did everything right. Mozilla has a mature, world-class security team. They pioneered bug bounties, invest in memory safety, fuzzing and test coverage.

NSS was one of the very first projects included with oss-fuzz, it was officially supported since at least October 2014. Mozilla also fuzz NSS themselves with libFuzzer, and have contributed their own mutator collection and distilled coverage corpus. There is an extensive testsuite, and nightly ASAN builds.

I'm generally skeptical of static analysis, but this seems like a simple missing bounds check that should be easy to find. Coverity has been monitoring NSS since at least December 2008, and also appears to have failed to discover this.

Until 2015, Google Chrome used NSS, and maintained their own testsuite and fuzzing infrastructure independent of Mozilla. Today, Chrome platforms use BoringSSL, but the NSS port is still maintained.

Did Mozilla have good test coverage for the vulnerable areas? YES.

Did Mozilla/chrome/oss-fuzz have relevant inputs in their fuzz corpus? YES.

Is there a mutator capable of extending ASN1_ITEMs? YES.

Is this an intra-object overflow, or other form of corruption that ASAN would have difficulty detecting? NO, it's a textbook buffer overflow that ASAN can easily detect. ----

[1]: https://googleprojectzero.blogspot.com/2021/12/this-shouldnt...

Re: Third High Severity CVE in Log4j Is Published

#272

Post by tekknik » Sun, Dec 19, 2021, 12:36 PM UTC

staticassertion wrote: post #130

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?

Honestly, absolutely not, and I think money would be harmful. Lots of software doesn't need a lot of work. It can be simple . When people get paid to solve problems there's an incentive to add more code, to add new domains, etc. Use the standard java logger and move on, it's that easy.

Where’s my incentive to work the weekend supporting a project after a long week of supporting my production code? If we want solid and secure OSS, we gotta pay someone!

Re: Third High Severity CVE in Log4j Is Published

#273

Post by alkonaut » Sun, Dec 19, 2021, 12:47 PM UTC

This isn’t a RCE right? Compared to the previous one I wouldn’t call a denial of service high severity at this point. It might have been high severity two weeks ago.

But to be clear: nested/recursive template expansion and expansion of user provided strings were never by design, correct, and the removal shouldn’t just be by configuration or considered breaking - it should simply be corrected (just like the jndi should be removed and not even be optionally possible)?

Re: Third High Severity CVE in Log4j Is Published

#274

Post by tekknik » Sun, Dec 19, 2021, 12:51 PM UTC

skwirl wrote: post #201

xigency wrote: post #29

More evidence that user provided data shouldn’t be logged at all.

User data shouldn't be processed at all. You never know where there will be a vulnerability. So you turn off logging so you have no idea what pages your customers are now requesting (phew!) but you can still be vulnerable to SQL injection attacks, buffer overflow attacks, etc. when you are processing the user data. Best to just reject it all.

The server is happier this way as well, finally people have gotten off its lawn!

Re: Third High Severity CVE in Log4j Is Published

#275

Post by tekknik » Sun, Dec 19, 2021, 1:11 PM UTC

bob1029 wrote: post #16

klyrs wrote: post #7

Earlier quoted context omitted.

Having worked with security-minded institutions in the past, I've endured and participated in year(s)-long audits of three different open source software projects. The thing that amazes me is that nobody using this software ever did their due diligence. You literally get what you pay for. Kindly step on your own legos and be happy this didn't happen in early April.

> The thing that amazes me is that nobody using this software ever did their due diligence. How could they be expected to? Reviewing all of the source code for log4j is not a walk in the park. Even if you thoroughly reviewed all the source code, would this specific exploit have crossed your mind? The game theory and assumptions around a "logging" library probably led a lot of organizations to not even consider it a p…

> Reviewing all of the source code for log4j is not a walk in the park.

Traditionally if something is too large to audit then you shouldn’t use it, which few exceptions (like Linux). Maybe this should be a red flag in the future, especially for a logging library that can almost be replaced with a call to stdout and a log collector.

Re: Third High Severity CVE in Log4j Is Published

#276

Post by tekknik » Sun, Dec 19, 2021, 1:14 PM UTC

TedDoesntTalk wrote: post #123

pimlottc wrote: post #92

Earlier quoted context omitted.

It’s worth noting that log4j does a lot more than, say, JavaScript’s console.log function. It’s dynamically configurable, supports a wide range of output formats and destinations, easily filterable, and highly optimized to reduce performance impact (in part through delayed evaluation and multi-threading). Rolling your own logging library to reimplement it is not trivial, even if you ignore the more esoteric output fo…

> wide range of output formats Not to mention a wide range of destinations, too. Want to log to a database table? You’re covered. What about log messages to a chat server (xmpp, slack) or email but only fatal errors? You’re covered. Now roll your own logging system that supports those destinations safely and get back to me to do pen testing. I bet we’ll find some vulns in your code.

This is the job of a log collector, not a log producer/library. The logging library itself should have no mechanism for shipping files anywhere except a file / stdout / stderr.

Re: Third High Severity CVE in Log4j Is Published

#277

Post by tekknik » Sun, Dec 19, 2021, 1:15 PM UTC

lazide wrote: post #235

marcosdumay wrote: post #230

Earlier quoted context omitted.

> Prior company had a shared plugin that let you turn up the logging for a given logger remotely for 30 minutes (it self reset). And you really believe this should be a feature of you logging library, and not of you configuration system?

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

You log and collect everything, then use your log aggregator to filter the appropriate content.

Re: Third High Severity CVE in Log4j Is Published

#278

Post by kevingadd » Sun, Dec 19, 2021, 1:17 PM UTC

post-it wrote: post #205

ncmncm wrote: post #165

The most reliable place to find new bugs and security holes is next to others you just found out about. Bugs come in bunches. If you have fixed just one or two, more lurk right there . And, anyplace else that coder worked. The more you have found, the more remain to be found. Look at other places that coder worked that week. Or year.

Your implication that specific bad coders are responsible for bugs is dangerous. Anyone can write a bug, and thinking that you're too good to do it is cocky.

Yes, but when a coder makes a specific mistake, it's likely they made it elsewhere. Similarly, when their mistake made it past code review, it likely made it past review elsewhere. They're not the only person making that mistake, but their diffs are a great place to start looking.

A big subset of mistakes people make when writing software are the result of people not having the same understanding of a concept, policy or practice.

Re: Third High Severity CVE in Log4j Is Published

#279

Post by MereInterest » Sun, Dec 19, 2021, 1:19 PM UTC

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?

When HeartBleed came out, there was a single dynamically linked library to be replaced. If you had a vulnerable version of libopenssl, then you replace the .so or .dll with a patched version, restart any applications that were using the old version, and you're set.

This works because the binary is compiled against the dynamic library, using the system-provided library. It isn't statically compiled, because even though that frees the developers from worrying about library versions, it makes the sysadmin's job tracking library versions be much harder. It isn't vendored, for the same reason.

Re: Third High Severity CVE in Log4j Is Published

#280

Post by hamilyon2 » Sun, Dec 19, 2021, 1:35 PM UTC

lazide wrote: post #232

spockz wrote: post #180

Earlier quoted context omitted.

Besides this, who actually scans the deployed binaries? Just check which version of the binary was deployed, backtrack to the source, and get the dependency tree from there. Problem solved. (Except for shaded dependencies…, but scanning for that should happen at build time anyway.)

Good luck doing that on the custom software some vendor provided you 5 years ago and since has gone out of business.. and that’s a GOOD scenario for a lot of enterprise software. Sometimes it’s 20 years.

We need some sort of escrow for source code of closed-source product. Whenever there is practical need to have access to source code, it should be available.