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

231–240 of 335 posts

Re: Third High Severity CVE in Log4j Is Published

#231

Post by spc476 »

pabs3 wrote: post #222
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…

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?

Re: Third High Severity CVE in Log4j Is Published

#232

Post by lazide »

spockz wrote: post #180
nitrogen wrote: post #101

Earlier quoted context omitted.

With languages that output a single binary by default such as Rust and Go, we would have been screwed. No way to scan, no way to self-help update. ELF binaries are just collections of another sort. You can scan for symbol names or assembled instructions common to a dependency, and you might be able to update with an LD_PRELOAD library that patches the symbol table. Just look at what game modders have accomplished wit…

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.

Re: Third High Severity CVE in Log4j Is Published

#233

Post by lazide »

staticassertion wrote: post #219
bigiain wrote: post #218

Earlier quoted context omitted.

> IDK where this idea that no one can know what's in a dependency tree is coming from I’d guess people running commercial non source available binaries in production. And outside startups and unicorns, that’s almost everybody. How do you find the dependancy tree for your on prem Oracle db, or your self hosted Atlassion stuff, or your non cloud ServiceNow or PeopleSoft stuff, or your Huawei network management stuff, o…

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.

Re: Third High Severity CVE in Log4j Is Published

#234

Post by lazide »

themerone wrote: post #224
macinjosh wrote: post #216

Earlier quoted context omitted.

Just because a dev lives in the Midwest doesn’t mean they’re idiots compared to coastal elites. The hate/mockery/minimizing of anyone not from a major coastal city is really gross. Screw you.

I am a developer in the midwest, and maybe if you hadn't completely missed my poin you wouldn't be such a jerk. Nebraska is a reference to an XKCD Comic ( https://xkcd.com/2347/ ). The idea is that there are nameless people all over the world contributing to critical open source infrastructure. Back to the point. Running Google Maps on one of my low traffic sites, would generate at most, several dollars a month in ch…

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

Re: Third High Severity CVE in Log4j Is Published

#235

Post by lazide »

marcosdumay wrote: post #230
ashtonkem wrote: post #215

Earlier quoted context omitted.

> It's a logging library. You don't reconfigure logging, you just make another logger and use it. Prior company had a shared plugin that let you turn up the logging for a given logger remotely for 30 minutes (it self reset). Extremely helpful for incident debugging. Now we can have an interesting discussion about whether that capability is worth the complexity, but that’s a very different discussion than unilaterally…

> 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?

Re: Third High Severity CVE in Log4j Is Published

#236

Post by Too »

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.

Lesson learned. Never buy closed source.

Imagine the vulnerability would have been in the vendor code instead of in the log4j jar. You’d. still need a way to fix and rebuild it.

Note that this doesn’t have to mean a public MIT repo on GitHub. You can have more restrictive gray box licenses between your b2b partners only.

Re: Third High Severity CVE in Log4j Is Published

#237

Post by Too »

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.

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.

Re: Third High Severity CVE in Log4j Is Published

#238

Post by arpa »

jiggawatts wrote: post #228
FridgeSeal wrote: post #191

Earlier quoted context omitted.

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

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…

> Now what?

Goodbye and thanks for all the fish. Run!

Re: Third High Severity CVE in Log4j Is Published

#239

Post by staticassertion »

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.

My point is that patching third party binaries is generally not something companies take responsibility for. They wait for vendors to patch the binaries and ship them.

Re: Third High Severity CVE in Log4j Is Published

#240

Post by Too »

nlitened wrote: post #124
dwaite wrote: post #84

Earlier quoted context omitted.

How do I fund ripping out bad ideas from existing open source software? Log4j2 partially exists because of pushback on adding features to v1

Fund a new fork

Just leads to the xkcd “there are now 14 competing standards.”

Honestly the biggest problem of package managers is finding a reputable package that one can trust.

The best one can do to aid this situation is reviewing, vetting and warning of which packages that can be trusted and not. Automatic scanners to find code smells and vulnerabilities.

“Security rating: 2/10, This package seems to use JNDI loading, are you sure you want to continue (y/n).”

Post reply on HN