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 information on HN, but to share it in an accurate and well thought manner.
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.
The threat here is that "an attacker with permission to modify the logging configuration file can construct a malicious configuration". If the attacker can modify server config files, this particular log4j fixup is likely to still leave you with nasty problems.
yes that would be true. Unfortunately log4j doesn't get configuration exclusively from config files on the server where it's running. this doesn't look like no access to full RCE like the first few rounds. But this might let an attacker turn a small exploit into a big exploit.
I suppose that there could be companies that load logging configs from a shared filesystem share that the non-security-minded now-retired ex-IT director threw up on an insecure server somewhere "so I can debug the outages better." Still not as bad as the log content being an attack vector!
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.
Holy moly, how was that ever a good idea. Just like routers being able to be configured via the manufacturer's website, config by someone other than you seems like a big red flag
well log4j will be old enough to drink in a few weeks (January 8, 2001). It's way older than bcfg2 or ansible, chef, puppet, etc. I'm not sure when the functionality was added. I'd bet it was the bees knees at the time.
Wild. I guess the NSA black bag job at Google was 2013, which led to SSL everywhere. I guess most folks still had the hard and crunchy on the outside, soft and chewy model on the inside mindset. Time flies.
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…!
"Log4j2 versions 2.0-beta7 through 2.17.0 are vulnerable to a remote code execution attack if an attacker with permission to modify the logging configuration file can construct a malicious configuration"
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
Hang about. You may have misunderstood what CVE is. CVE doesn't mean 'world ending vulnerability'. It means "common vulnerability and exposure".
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.
Whether I misunderstand it or not (I don’t) is irrelevant because customers run scanning tools and demand fixes for any CVE without attempting to understand them.
So, you either explain to the customer about how the CVE is out of scope in this context due to the various mitigations or lack of exploitability, or you patch it. Every CVE is real, and should be addressed. Your customers pay you to help them understand it.
That's fair, but it's not really the fault of MITRE / the CVE database, it's the fact that people have been incentivized to submit these. Similar conversations have come up around how NPM handles vulnerability reports, since they treat all vulnerabilities the same, including very low-risk ones like DoS risks that require control of your build pipeline.
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.
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.
> 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?
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, maybe you can just replace/patch the main binary in the first place…)
You can configure ASP.NET to load HTTP Handlers and Modules for use in the request/response pipeline via the web.config file (from the file system, not over HTTP).
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.
> 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`).
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.
>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.
In a typical installation of something like Apache Tomcat, there will be config files that tell the server what code to load and run. If you can modify those config files...
If you've been impacted by these log4j vulnerabilities, have a look at aegis4j, a Java agent that completely disables platform features you don't use, before an attacker uses them against you (including e.g. JNDI and Java serialization).
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.