10 ms·

New Log4j2 vulnerability

103 points by xaner4 5y ago

NicolaiS 5y ago
"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"
rst 5y ago
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.
- jfoutz 5y ago
  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.
  - btown 5y ago
    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!
    - hinkley 5y ago
      > ex-IT director If only that were true. At least we could bond over what an idiot 'that guy' was. But he probably is friends with the CEO so we can't say shit.
      - btown 5y ago
        old IT directors never die, they simply fade away, much like the sanity of everyone left
formerly_proven 5y ago
Eh, that sounds like it's not a vulnerability at all. Most app server configuration files allow you to load and run arbitrary code.
- phoronixrly 5y ago
  Yeah, maybe should be mentioned in the title to save people from PTSD over the holidays...
  - xaner4 5y ago
    If I could have have changed the title I would have added something to make it give less PTSD
- johnisgood 5y ago
  > 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?
  - rst 5y ago
    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...
  - filleokus 5y ago
    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…)
    - 5y ago
jet390 5y ago
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). https://github.com/gredler/aegis4j/ https://github.com/gredler/aegis4j/
jfoutz 5y ago
I've just started looking, and I'm not an expert. 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.html#PropertySubstitution 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 5y ago
  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
  - jfoutz 5y ago
    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.
    - mongol 5y ago
      Sad that it should be retired now when it is coming of age.
    - mschuster91 5y ago
      Log4j v2 (which was the first version to support plugins and lookups) was released in 2014.
      - jfoutz 5y ago
        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.
Sebguer 5y ago
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.
- mnd999 5y ago
  CVE doesn’t have much credibility at this point as far as I’m concerned. It can mean anything.
  - rfd4sgmk8u 5y ago
    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.
    - mnd999 5y ago
      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.
      - Sebguer 5y ago
        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.
frogger8 5y ago
https://twitter.com/nas_bench/status/1475940057924222977?s=20 https://twitter.com/nas_bench/status/1475940057924222977?s=2...
imwillofficial 5y ago
- richardfey 5y ago
  A couple CVEs ago I'd already have replaced it with a shim using System.err.println()
oars 5y ago
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.
- break_the_bank 5y ago
  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.
  - oars 5y ago
    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.
- ansraliant 5y ago
bjornsing 5y ago
Why do they say it’s a RCE (Remote Code Execution) if it requires changing a configuration file?
- MattPalmer1086 5y ago
  Changing the config enables the RCE vulnerability.

103 points by xaner4 5y ago

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

rst 5y ago

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.

jfoutz 5y ago
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.
- btown 5y ago
  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!
  - hinkley 5y ago
    > ex-IT director If only that were true. At least we could bond over what an idiot 'that guy' was. But he probably is friends with the CEO so we can't say shit.
    - btown 5y ago
      old IT directors never die, they simply fade away, much like the sanity of everyone left

formerly_proven 5y ago

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

phoronixrly 5y ago
Yeah, maybe should be mentioned in the title to save people from PTSD over the holidays...
- xaner4 5y ago
  If I could have have changed the title I would have added something to make it give less PTSD
johnisgood 5y ago
> 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?
- rst 5y ago
  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...
- filleokus 5y ago
  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…)
  - 5y ago

jet390 5y ago

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). https://github.com/gredler/aegis4j/ https://github.com/gredler/aegis4j/

jfoutz 5y ago

I've just started looking, and I'm not an expert. 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.html#PropertySubstitution 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 5y ago
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
- jfoutz 5y ago
  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.
  - mongol 5y ago
    Sad that it should be retired now when it is coming of age.
  - mschuster91 5y ago
    Log4j v2 (which was the first version to support plugins and lookups) was released in 2014.
    - jfoutz 5y ago
      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.

Sebguer 5y ago

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.

mnd999 5y ago
CVE doesn’t have much credibility at this point as far as I’m concerned. It can mean anything.
- rfd4sgmk8u 5y ago
  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.
  - mnd999 5y ago
    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.
    - Sebguer 5y ago
      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.

frogger8 5y ago

https://twitter.com/nas_bench/status/1475940057924222977?s=20 https://twitter.com/nas_bench/status/1475940057924222977?s=2...

imwillofficial 5y ago

richardfey 5y ago
A couple CVEs ago I'd already have replaced it with a shim using System.err.println()

oars 5y ago

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.

break_the_bank 5y ago
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.
- oars 5y ago
  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.
ansraliant 5y ago

bjornsing 5y ago

Why do they say it’s a RCE (Remote Code Execution) if it requires changing a configuration file?

MattPalmer1086 5y ago
Changing the config enables the RCE vulnerability.