Good day,
A very urgent security issue was made public on 10-Dec-2021 in a well-used library, log4j-v2 that affects many web services (see CVE-2021-44228 - Log4j 2 Vulnerability Analysis - Randori Attack Team 22).
While this is a severe vulnerability that affects many Java based applications including DHIS2 (see announcement) and OpenMRS (see announcement), it should be noted that it should NOT affect Bahmni installations UNLESS you use
Bahmni (all versions) run on Log4j v1.x and not on v2.x. This specific CVE cannot be exploited with the default configuration of Log4j v1.x, which ships with Bahmni. For details see the following announcement by Red Hat (link: cve-details). It states that:
- Note this flaw ONLY affects applications which are specifically configured to use JMSAppender, which is not the default, or when the attacker has write access to the Log4j configuration for adding JMSAppender to the attacker’s JMS Broker.
- Applications using Log4j 1.x may be impacted if their configuration uses JNDI as described above. Therefore Red Hat Product Security has rated this issue as having MODERATE severity impact.
ACTION:
- Since Bahmni by default doesn’t ship or use JMSAppender, we don’t see any need for Bahmni deployments to take any immediate action.
- If you are using any of above two modules (two-factor-auth or pacs-integration) then please go ahead and do the following as immediate mitigation from the issue
Run the following command on your server to recursively find all log4j-core JAR files, starting from the current directory, and remove the vulnerable JndiLookup class from them. For full coverage, the command may be executed from the root directory of your project or server.
find ./ -type f -name "log4j-core-*.jar" -exec zip -q -d "{}" org/apache/logging/log4j/core/lookup/JndiLookup.class \;
Once done restart pacs-integration
sudo systemctl restart pacs-integration
and stop-start two-factor-auth application
java -Dloader.path=/home/bahmni/.bahmni-security/ -jar two-factor-auth-VERSION.jar
Note:
We do recommend that servers running Bahmni or within the same network still check for existence of log4j-v2.x in other applications/machines, to ensure machines don’t get compromised. To do that, you can run a wildcard search on the machine for log4j.jar and ensure none of the results on the machine are for log4j v2.x. If so, please check which application is loading that version of log4j, and patch it as suggested in CVE links above. You could still have situations where log4j is in an embedded .war file or .ear file, so - it is best to check security announcements of any products installed on that server that run on java.
As a long term mitigation we soon plan to release a hotfix in-order to upgrade Bahmni to a more safer and stable version of log4j.
@ajeenckya @arjun @mksrom @pramidat @ramashish @shivarachakonda @binduak @swetha184 @laxman @anandpatel @snehabagri @sushilp @sushmit @vmalini @dipakthapa @ramashish @pradiptakundu @mddubey @rrameshbtech @mddubey @iadksd @mwelazek @michaelbontyes @buvaneswariarun @praveenad @sanjayap @florianrappl @apaule @mwelazek @som.bhattacharyya @tejakancherla @rabbott @gsluthra @wolf @mdg583 @gsluthra @akhilmalhotra @n0man @swatigogia @mohant @abinaya