New Log4j2 vulnerability(nvd.nist.gov) |
New Log4j2 vulnerability(nvd.nist.gov) |
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 information on HN, but to share it in an accurate and well thought manner.
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.
The key point here is log4j can get configuration a lot of different ways, including a network request. Based on https://logging.apache.org/log4j/2.x/manual/configuration.ht... control over dns would let you rewrite sections of config, and thus run arbitrary code.
So, if you've got some access, this would allow you to escalate that access to a full RCE. I think that's why it's only Medium severity.
The wording in the CVE description of “an attacker with permission to modify the logging configuration file” really obscures that fact if that’s true.
That wording means something very specific to me (and I would assume many others) - my immediate assumption was that it refers to an actual file on disk on the machine running Log4j.
If it can load config over a network request - I feel like this would have been useful to point out in the description?
Unless this particular issue is just restricted to local file-based config?
Sadly it’s late here so I don’t have time to read up further right now. I’ll reserve that pleasure for tomorrow morning…!
Log4j is used in many desktop/client software as well, some of them being network connected as well, one way or another.
It is merely a way of tagging security vulnerabilities through multiple products. Before CVE it was difficult to reason if a product was insecure because it had a an insecure component. CVE speaks to nothing of the severity (that CVSS), just that two products that have the same CVE suffer from the same root vulnerability in their components.
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?
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, maybe you can just replace/patch the main binary in the first place…)
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.
The problem is compounded in cases like Log4j where not even the CVE score can be trusted, or in cases you're describing where end-users don't understand CVE itself and only know it in the context of these 'world-ending' vulnerabilities.
But if your attacker has gotten so far as to be able to tamper with these config files then it's probably game-over already.
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`).
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.