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

31–40 of 49 posts

Re: New Log4j2 vulnerability

#31

Post by break_the_bank »

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.

Re: New Log4j2 vulnerability

#32

Post by teh_klev »

filleokus wrote: post #29
johnisgood wrote: post #12

Earlier quoted context omitted.

> 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,…

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.

Re: New Log4j2 vulnerability

#33

Post by btown »

hinkley wrote: post #20
btown wrote: post #19

Earlier quoted context omitted.

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!

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

old IT directors never die, they simply fade away, much like the sanity of everyone left

Re: New Log4j2 vulnerability

#34

Post by mschuster91 »

jfoutz wrote: post #21
alfiedotwtf wrote: post #13

Earlier quoted context omitted.

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.

Log4j v2 (which was the first version to support plugins and lookups) was released in 2014.

Re: New Log4j2 vulnerability

#35

Post by capableweb »

filleokus wrote: post #29
johnisgood wrote: post #12

Earlier quoted context omitted.

> 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,…

> 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`).

Re: New Log4j2 vulnerability

#36

Post by Sebguer »

rfd4sgmk8u wrote: post #30
Sebguer wrote: post #23

Earlier quoted context omitted.

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…

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.

Re: New Log4j2 vulnerability

#38

Post by ansraliant »

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…

No post body was provided.

Re: New Log4j2 vulnerability

#39

Post by tailspin2019 »

jfoutz wrote: post #8

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.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…

> including a network request

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…!

Re: New Log4j2 vulnerability

#40

Post by jfoutz »

mschuster91 wrote: post #34
jfoutz wrote: post #21

Earlier quoted context omitted.

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.

Log4j v2 (which was the first version to support plugins and lookups) was released in 2014.

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.
Post reply on HN