Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New Log4j2 vulnerability

nvd.nist.gov

Post reply on HN
Print view View original

41–49 of 49 posts

Re: New Log4j2 vulnerability

#41

Post by johnisgood »

capableweb wrote: post #35
filleokus wrote: post #29

Earlier quoted context omitted.

If I remember correctly e.g Django and Flask uses plain old python-files for configs. Don’t know if it’s common in the Node landscape but probably? I don’t know how common it is to specify paths to/file name for DLL’s in config to load at runtime for C#, but probably not totally unheard of? And if you can edit the config, maybe you can place a DLL somewhere as well…? (But at the some time if you can edit the config,…

> Don’t know if it’s common in the Node landscape but probably? Webpack is (arguably) one of the most common tools in the nodejs/browser ecosystem, and it has a regular JS file as it's config file (usually named `webpack.config.js`).

I am still stuck at using INI/JSON/TOML for configuration files. :D

Re: New Log4j2 vulnerability

#42

Post by rfd4sgmk8u »

Sebguer wrote: post #36
rfd4sgmk8u wrote: post #30

Earlier quoted context omitted.

The CVSS score cannot be trusted? How so? I don't see why any of the log4j CVE's 'cant be trusted'?

The third CVE arbitrarily had a score of ~7.5 despite requiring a non-standard configuration and only enabling a denial of service attack. The preceding CVE with the same outcome only warranted a 3.5, until it was shown to also potentially allow an RCE. CVSS is honestly pretty open to interpretation, since it's not a particularly objective set of measures.

Fair enough, I agree with you there. CVSS(v2/v3) can be subjective and can change when new information comes to light.

Re: New Log4j2 vulnerability

#43

Post by oars »

break_the_bank wrote: post #31
oars wrote: post #25

Please update the title to indicate this is a low severity CVE and prevent managers around the world from panicking and summoning their developers and engineers back at work during this shut down period. To be honest, I panicked reading this title when I opened HN this evening, but reading the CVE entry tells me this isn't anywhere close to as serious as CVE-44228. You have a responsibility to not just share informat…

I clicked on this wondering if the next few days will be ruined like when the original CVE came out. Glad I read your comment.

The weekend spanning the 11th and 12th December was the first full weekend my entire team and I had to work in years.

This should not happen again without good reason. Announcing that there is a "New Log4j2 vulnerability" is a sure way of getting many good-willed managers, who may lack the deeper understanding us developers have of the vulnerability because we are able to spend more time on it, panicked and executing our critical incident response framework when it's not needed.

I know that we were not the only ones working that weekend, many of my counterparts were also tirelessly working this entire weekend too, along with much of HN I assume. Let's not do this again unless it's truly necessary.

Re: New Log4j2 vulnerability

#44

Post by dylan604 »

Sebguer wrote: post #10

The worst part of these major vulnerabilities is the endless follow-on stream of knee-jerk 'CVE' that are clearly nothing-burgers, and yet will be described as a 'new Log4j' vulnerability, and cause a bunch of people who don't know better to panic.

All of this reminds me of when Zoom was getting all of the attention. It's something that's been around for a while that nobody noticed, then somebody did. Everyone freaks out, and then New Vuln comes out weekly because now everyone is looking for it. Log4j hit servers, where Zoom hit people directly at home. Which is worse? Depends on persepective

Re: New Log4j2 vulnerability

#45

Post by capableweb »

johnisgood wrote: post #41
capableweb wrote: post #35

Earlier quoted context omitted.

> Don’t know if it’s common in the Node landscape but probably? Webpack is (arguably) one of the most common tools in the nodejs/browser ecosystem, and it has a regular JS file as it's config file (usually named `webpack.config.js`).

I am still stuck at using INI/JSON/TOML for configuration files. :D

Just remember that just because you're using .ini/.json/.toml files doesn't mean there isn't any way of executing code from changing their values, it's up to whatever is using the files if there is any way of executing code via them.

One example is package.json. It's a JSON file, yeah, and normally doesn't contain any code. But one of the fields is `scripts` which can contain a object with a key like `preinstall` (and more) that runs those as shell commands at different lifecycle of using `npm`.

So just because you're using those languages/syntaxes, doesn't mean there isn't any way of executing code via them.

Re: New Log4j2 vulnerability

#46

Post by capableweb »

dylan604 wrote: post #44
Sebguer wrote: post #10

The worst part of these major vulnerabilities is the endless follow-on stream of knee-jerk 'CVE' that are clearly nothing-burgers, and yet will be described as a 'new Log4j' vulnerability, and cause a bunch of people who don't know better to panic.

All of this reminds me of when Zoom was getting all of the attention. It's something that's been around for a while that nobody noticed, then somebody did. Everyone freaks out, and then New Vuln comes out weekly because now everyone is looking for it. Log4j hit servers, where Zoom hit people directly at home. Which is worse? Depends on persepective

> Log4j hit servers, where Zoom hit people directly at home

Log4j is used in many desktop/client software as well, some of them being network connected as well, one way or another.

Re: New Log4j2 vulnerability

#48

Post by johnisgood »

capableweb wrote: post #45
johnisgood wrote: post #41

Earlier quoted context omitted.

I am still stuck at using INI/JSON/TOML for configuration files. :D

Just remember that just because you're using .ini/.json/.toml files doesn't mean there isn't any way of executing code from changing their values, it's up to whatever is using the files if there is any way of executing code via them. One example is package.json. It's a JSON file, yeah, and normally doesn't contain any code. But one of the fields is `scripts` which can contain a object with a key like `preinstall` (an…

That is fairs and true. :) Thanks!

Re: New Log4j2 vulnerability

#49

Post by blacksqr »

johnisgood wrote: post #12
formerly_proven wrote: post #4

Eh, that sounds like it's not a vulnerability at all. Most app server configuration files allow you to load and run arbitrary code.

> Most app server configuration files allow you to load and run arbitrary code I do not understand this. Configuration files allow you to load and run arbitrary code? Is this actually a thing? What are they using for configuration files?! Tcl?

>What are they using for configuration files?! Tcl?

This would be preferable, since Tcl allows you to configure safe interpreters that can deny use of any specified set of commands, including those that give access to files and network services.

https://www.tcl.tk/man/tcl8.6/TclCmd/safe.html

Post reply on HN