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

191–200 of 335 posts

Re: Third High Severity CVE in Log4j Is Published

#191

Post by FridgeSeal »

jiggawatts wrote: post #116
c-cube wrote: post #96

Earlier quoted context omitted.

If you still have the source code for your rust code, it contains the lock file. Look in there and you'll see all dependencies and their version. Why do you want to look at the binary instead?

The source code is not what is deployed . There is typically no link back from a deployed system to its source, even if you compiled the binary within your organisation. If it came from an external organisation, things are exponentially harder. Modern deployment systems are largely "one-way", with no way to trigger a full recompile from the deployment end of things. If you have a VM with "SomeRandomBinary.exe" runnin…

> The source code is not what is deployed. There is typically no link back from a deployed system to its source, even if you compiled the binary within your organisation.

Do you not have this? Our docker images are tagged with the git hash they were built from, so at any point, for any of our envs, I can pull up the lock file of that build.

Our deployment config also describes everything that is running the relevant env, and nobody has machine access- going through the pipeline is the only way to get access, so there’s nothing deployed that’s a mystery.

Re: Third High Severity CVE in Log4j Is Published

#192

Post by throwaway81523 »

Is this still about malicious payloads in serialized Java packets? I don't use Java so maybe I'm being unjust, but I'm smiling slightly because Python went through this 20 years ago with regard to the pickle protocol. It was originally intended to be ok for transporting hostile data, and it took a fair amount of persuasion and a few security incidents to turn the community's thinking around about that. ast.literal_eval was invented partly for this reason, but the generally preferred way to serialize now is usually json.

Re: Third High Severity CVE in Log4j Is Published

#193

Post by ldng »

akeck wrote: post #52
Kreotiko wrote: post #9

If information security people would spend the same amount of time they are spending complaining about this vulnerability trying to educate their organisations on the importance of supporting open source solutions they depend on we wouldn’t be in this situation. I am sick of reading of very senior people complaining about the impact this vulnerability has had on their week when their companies don’t even contribute a…

I read a post recently that said part of the open source funding issue comes down to a financial "structure" mismatch. Open source folks are often individuals or loose collections of individuals. Sometimes they have things like Patreons, ask to receive crypto currencies, etc. Companies don't/can't provide funding via these types of structures, so the writer of the post ended up incorporating a company, setting up a m…

They must adapt. Period. And don't worry, when they have to, they do find solutions. The thing is, with open source, you don't have to, worse, the vast majority of enterprises rely because you don't need to make any effort.

Re: Third High Severity CVE in Log4j Is Published

#194

Post by layer8 »

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

That’s a really big "if" though.

Re: Third High Severity CVE in Log4j Is Published

#195

Post by Spooky23 »

jiggawatts wrote: post #88
alanfranz wrote: post #4

Thanks to all Log4j developers. As users of your free software since ~20 years, we're sure that, if this vuln disclosure had been better and there were no sign of widespread in-the-wild exploitation, you would have done a better job at patching it, and a single release would have been enough. We won't hold a grudge against you; open source means collaboration, and you don't blame hard-working people that give away th…

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…

Perhaps everyone is stupid.

It’s funny because when I worked in .gov IT, we were all characterized as stupid donkeys by because we weren’t able to just use NPM, etc to do cool kid stuff.

Good luck getting security people with the power and brass balls to do that in any company.

Re: Third High Severity CVE in Log4j Is Published

#196

Post by NavinF »

a-dub wrote: post #131
hn_throwaway_99 wrote: post #109

Earlier quoted context omitted.

It's not difficult to take user-entered data and just dump it to a log file. I'm pretty positive none of these vulnerabilities exist with System.out.println. The fundamental problem is that, pretty surprisingly, log4j was running the same parsing and logic on user-entered strings as they did format strings. That's essentially the root cause of all this - log4j shouldn't be attempting to parse this data at all. So man…

> It's not difficult to take user-entered data and just dump it to a log file. I'm pretty positive none of these vulnerabilities exist with System.out.println. yes, but there can be (and have been) vulnerabilities in terminal emulators, terminal multiplexers, text editors, databases, web renderers and all manner of tools that can be used to store the contents of or view that file. your argument makes sense that the l…

> user supplied data should be sanitized in the strictest possible manner before anything is done with it, including logging

Oh come on, how would you even do that if you don’t know how the data is going to be interpreted by parsers that nobody knows they’re using? WAFs have been trying to do this since forever, but it’s always been security theater that separates gullible companies from their money and randomly blocks users that use “special” characters like slash or quotation marks.

I guess you could base64 encode everything, but that wouldn’t save you from the terminal bugs you mentioned. At some point you’re gonna have to undo the “sanitizing” and look at the text.

Re: Third High Severity CVE in Log4j Is Published

#197

Post by layer8 »

throwaway81523 wrote: post #192

Is this still about malicious payloads in serialized Java packets? I don't use Java so maybe I'm being unjust, but I'm smiling slightly because Python went through this 20 years ago with regard to the pickle protocol. It was originally intended to be ok for transporting hostile data, and it took a fair amount of persuasion and a few security incidents to turn the community's thinking around about that. ast.literal_ev…

> Is this still about malicious payloads in serialized Java packets?

No, it’s not.

Re: Third High Severity CVE in Log4j Is Published

#198

Post by nitrogen »

junon wrote: post #190
ncmncm wrote: post #188

Earlier quoted context omitted.

You instead wholly failed to address the point about symbol tables.

Symbol table patching doesn't do anything if the functionality is internal... Do you know how programs are linked?

We're all on the same team here, there's no need for this hostility back and forth.

Binary patching, JAR patching, disassembly, library interception, syscall interception, whatever, these are all tools that are on the table. You do what it takes to get the job done, knowing and weighing the pros and cons.

Re: Third High Severity CVE in Log4j Is Published

#199

Post by ncmncm »

junon wrote: post #190
ncmncm wrote: post #188

Earlier quoted context omitted.

You instead wholly failed to address the point about symbol tables.

Symbol table patching doesn't do anything if the functionality is internal... Do you know how programs are linked?

Do you? Have you, e.g., written a linker? Educating is an entirely different process than you are engaged in.

Re: Third High Severity CVE in Log4j Is Published

#200

Post by Spooky23 »

Perseids wrote: post #148
tatersolid wrote: post #97

Earlier quoted context omitted.

In commercial software the customers don’t have the source files…

Well, we're in a thread that started with > 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. If there is the possibility to plan ahead from a sufficiently strong bargaining position, you will not end up in the situation you described. The seller should either continue to support it…

ROFL.

Ok, after putting the unicorns herd to bed, an event happens and congratulations, you now own a license to PeopleSoft v.whatever source code. Oh yeah, you also got the management platform for your network provider too.

Now what?

Post reply on HN