Potential vulnerability in Atlas

Implementers
1

Hey,
I got this from out IT crew

Log4Shell: RCE 0-day exploit found in log4j, a popular Java logging package
Atlas is using log4j for logging recomende to apply patch

https://www.lunasec.io/docs/blog/log4j-zero-day/

Im not an expert in security, Atlas developers may have fix this already.
Im just forwarding this in case it can protect someone.

2

Actually, I would like to generalize @Javier 's query about log4j – in addition to Atlas, are there any other OHDSI tools that also use this infrastructure. And for all tools who are using log4j, what needs to happen to fix this vulnerability in new build?

3

According to my knowledge Log4j2 is not used in ATLAS/WebAPI. CVE-2021-44228 says about Log4j v2.x, while WebAPI still uses Log4j v1.x

4

Hi, i found the following which also describes the (smaller) potential in Version 1 of log4j.

“As log4j 1.x does NOT offer a JNDI look up mechanism at the message level, it does NOT suffer from CVE-2021-44228. However, log4j 1.x comes with JMSAppender which will perform a JNDI lookup if enabled in log4j’s configuration file, i.e. log4j.properties or log4j.xml. Thus, an attacker who already has write access to an application’s log4j configuration file can trigger an RCE attack whenever log4j 1.x reads a corrupt/malicious configuration file.” [1]

[1] SLF4J

5

I think in this case attacker will have access to more attractive things :frowning:

6

You are right, but for the sake of completness :wink:

7

I wanted to provide some additional information on Log4Shell and the OHDSI software. As mentioned by @Konstantin_Yaroshove Log4j v2 is not used by the software stack inclusive of Atlas/WebAPI/Hades so the good news is that the Log4Shell vulnerability does not impact us. There are known issues with Log4j v1 as noted by @Mirko but these are less severe when compared to the Log4Shell vulnerability.

We are currently working on a patch for WebAPI to allow us to upgrade to Log4j v2 that allows us to move past all known vulnerabilities. Updating any component, such as Log4j, to a new major version (in this case v1 → v2) requires careful testing to ensure we preserve backwards compatibility and to not introduce new errors. When this patch is ready, we’ll communicate it out to the OHDSI community.

8

Hi Guys!

Seems like they are on it :slight_smile:

log4j and Google OAuth security updates · Issue #1969 · OHDSI/WebAPI · GitHub

9

It is also important to note that popular open-source client SQL Workbench/J also uses log4j package, and as of now did not receive any updates recently, so it is very much possible that it has the same vulnerability. I would recommend to switch to DBeaver for now: it’s another great open-source tool that does not use the affected library.

1 Like
10

That’s good news! Do you have some kind of a prioritized list of CVEs you want to mitigate?

11

For log4j, we’d like to make sure we’re using the latest version so we by-pass all known CVEs. That said, it looks like work around log4j v2 is still on-going. Last week the guidance was to patch log4j to v2.15.0 and then this week another vulnerability was identified resulting in a v2.16.0. It would seem prudent to give it some time to wait for stable, secure release of log4j v2 since the stack is not vulnerable to these zero-day attacks.

12

I’ve asked Thomas Kellerer, who is the developer of Workbench/J, about this problem by email, and he answered that by default Workbench/J does not use Log4J. Good news for those who love old-school things and/or minimalistic Windows 98 style :slight_smile:

1 Like
13

Happy New Year Everyone. I know its been the holidays but I was just wondering if there is any update log4j issue with OHDSI WebAPI? Thanks.

14

How about JDBC drivers? For instance, the Spark JDBC driver page states that older versions of it are impacted by the vulnerability.

15

is it really ATLAS? Same drivers are being used by all OHDSI tools.

Anyhow, you definitely bring up a very good point - the shared common, mostly 3rd party, components that used across the whole stack and need to be maintained and synchronized

16

Hi All,

Happy new year!

Following the recent Log4J vulnerability, we identified some more vulnerabilities (high and critical) that can affect Atlas using Snyk.

Is there any intend to have a look at the others as well for the next version?
WebAPI
Atlas

Many thanks :slight_smile:

1 Like
17

Hi Anthony,

As I see there is some update done for log4j in git hub. (1970 pull request). is it affective already. we are still using old version. if we need to update, do we need to clone the new git hub repo for log4j update?

18

@anthonysena Watching yesterdays WG meeting, I understood that Atlas/WebAPI release v2.11 will be discussed further in March. In the meantime, from looking at recent WebAPI PR it seems that the the security fixes have been merged.

Is there already a plan to release Atlas/WebAPI with these security fixes (i.e. v2.10.2)?