Some thoughts on the Log4j 2.17.1 release
32 views
Skip to first unread message
Josh Bressers
Dec 28, 2021, 8:44:50 PM12/28/21
to GSD Discussion Group
Hi all,
If you've not yet heard, there's yet another Log4j security release.
CVE-2021-44832
I think this one needs a discussion, I'm doing that here (I don't think Twitter is a reasonable medium for real discussion).
The TL;DR of this one is if an attacker can modify a configuration file they can execute arbitrary code. I think calling this a security issue is wrong. For example Log4j configuration files can also run arbitrary scripts
A highly complex system like Log4j should take the stance that if an attacker can modify configuration files they can execute arbitrary code.
However, there are some reasons I'm OK with this getting a CVE ID.
First, the world is on edge for anything Log4j related. I think the purpose of an identifier in this case isn't really about a security vulnerability, it's how we can give the world a common language. There's no question what I'm talking about if I mention CVE-2021-44832.
Next, there's the question of is this a vulnerability. It's clearly not. A better way to deal with this should be to assign an identifier to any system that allows a remote user to modify Log4j configuration details. I think creating a parent/child type relationship between CVE-2021-44832 and any vulnerable applications would make discovery of affected apps easier. I suspect in this current case anything found will just reuse CVE-2021-44832 which is very difficult to track.
The last thought I have on this is about discussion. When there is a new identifier assigned, sometimes discussion will be needed. What makes the most sense for that? Maybe a thread on a list like this? Maybe a discussion forum of some sort? I don't think trying to use Twitter or Github will work for any discussion of moderate size.
I would love to know what others may be thinking here. Thanks in advance.
--
Josh
Kurt Seifried
Dec 28, 2021, 9:04:00 PM12/28/21
to Josh Bressers, GSD Discussion Group
On Tue, Dec 28, 2021 at 6:44 PM Josh Bressers <jo...@bress.net> wrote:
Hi all,If you've not yet heard, there's yet another Log4j security release.CVE-2021-44832I think this one needs a discussion, I'm doing that here (I don't think Twitter is a reasonable medium for real discussion).
The TL;DR of this one is if an attacker can modify a configuration file they can execute arbitrary code. I think calling this a security issue is wrong. For example Log4j configuration files can also run arbitrary scriptsA highly complex system like Log4j should take the stance that if an attacker can modify configuration files they can execute arbitrary code.
Ok let's set some expectations:
1) Does the program in question have a config file that is reasonably going to result in arbitrary code execution if an attacker controls it? E.g. Web servers have configs that are will understood to control code execution (this is a cgi-bin dir, run PHP scripts here, etc.) but I fear many servers are not expected to have code execution, e.g. Samba, it can execute scripts (username map script, abort shutdown script, etc.) and some would not expect this at all (e.g. log4j, why is it running scripts?
2) Is this well documented? In your case it's documented, but the word security literally doesn't occur in there at all(*).
3) Does this code execution result in changed privileges, e.g. one would expect the code execution to only occur as the user the software runs as, but what if the software has to be setuid root to bind to a low port and then drops privileges (like... everything did in the past), could code execution occur as root and allow privilege escalation?
4) How easy it for an attacker to rewrite the config file(s) if they break into the service? E.g. some services explicitly support "dump currently loaded config to file" to support making run time changes and then saving them
5) How easy/hard is it for an attacker to cause the software or service to reload the config, e.g. can they break in and issue a reload command, or do they have to crash it and wait for an admin to restart it?
(*) In fact the only mention of security is:
As of version 2.9, for security reasons, Log4j does not process DTD in XML files. If you want to split the configuration in multiple files, use XInclude or Composite Configuration.
which I would argue should have gotten its own security identifier as well, also there's no mention of how well it handles HTTPS/errors.
However, there are some reasons I'm OK with this getting a CVE ID.First, the world is on edge for anything Log4j related. I think the purpose of an identifier in this case isn't really about a security vulnerability, it's how we can give the world a common language. There's no question what I'm talking about if I mention CVE-2021-44832.
There's definitely more sharp edges as well, see the 2.9 file inclusion stuff above.
Next, there's the question of is this a vulnerability. It's clearly not. A better way to deal with this should be to assign an identifier to any system that allows a remote user to modify Log4j configuration details. I think creating a parent/child type relationship between CVE-2021-44832 and any vulnerable applications would make discovery of affected apps easier. I suspect in this current case anything found will just reuse CVE-2021-44832 which is very difficult to track.
Yup. This speaks to the relationship data, parent/child/sibling/etc. "This issue GSD-2020-1234567) is a result of Foo plus the sharp edge (GSD-2020-11122233)" and then at some point you have 400 GSD's all linking to the sharp edge case of GSD-2020-11122233 and maybe it gets disabled by default.
The last thought I have on this is about discussion. When there is a new identifier assigned, sometimes discussion will be needed. What makes the most sense for that? Maybe a thread on a list like this? Maybe a discussion forum of some sort? I don't think trying to use Twitter or Github will work for any discussion of moderate size.
I think realistically the problem is "we need to support a discussion that may be a single post with no reply, all the way to a discussion spanning weeks with dozens of people", it needs to be captured, and tightly linked to the thing so that it can be discovered easily, I suspect GitHub issues are the least worst option here. Twitter is good for ad-hoc arguments but capturing it... good luck.
Weston Steimel
Dec 29, 2021, 2:31:05 AM12/29/21
to GSD Discussion Group, ksei...@cloudsecurityalliance.org, GSD Discussion Group, Josh Bressers
Could GitHub Discussions possibly be a good fit here? I haven't used it yet before, but perhaps worth a try?
Kurt Seifried
Dec 30, 2021, 12:41:55 PM12/30/21
to Weston Steimel, GSD Discussion Group, Josh Bressers
I enabled discussion on the database and project plans repos:
So discussions in database about the GSD entries, in project plans about meta topics (like this) makes sense I think?
Reply all
Reply to author
Forward
0 new messages