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 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.
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
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
> 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 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).
oars|4 years ago
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.
break_the_bank|4 years ago
ansraliant|4 years ago
[deleted]
rst|4 years ago
jfoutz|4 years ago
jfoutz|4 years ago
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.
alfiedotwtf|4 years ago
tailspin2019|4 years ago
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…!
NicolaiS|4 years ago
Sebguer|4 years ago
dylan604|4 years ago
mnd999|4 years ago
formerly_proven|4 years ago
phoronixrly|4 years ago
frogger8|4 years ago
johnisgood|4 years ago
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?
jet390|4 years ago
https://github.com/gredler/aegis4j/
bjornsing|4 years ago
MattPalmer1086|4 years ago
frogger8|4 years ago
imwillofficial|4 years ago
[deleted]
richardfey|4 years ago