RStudio is not affected by CVE-2021-44228 (Log4j vulnerability)

[kyle_hekhuis]

RStudio has confirmed that CVE-2021-44228 (Log4j vulnerability) is not present in the currently supported versions of RStudio Professional software applications. For a list of our currently supported versions of RStudio Professional software applications, please see RStudio Support - RStudio.

UPDATE - 2021-12-14
We have confirmed that the open source versions of RStudio Desktop, RStudio Server, and Shiny Server are also free from the vulnerability.

Furthermore, we have confirmed that both the open source and pro versions of RStudio Desktop, RStudio Server/RStudio Workbench, and Shiny Server have never used Log4j so older versions should be free of the vulnerability as well.

The only thing we have found using Log4j so far is shinycannon, which is used as part of shinyloadtest for load testing Shiny apps. Both shinycannon and shinytest are completely separate from Shiny Server and RStudio Connect. For those that do use shinycannon as part of their load testing, we do have a fix for the Log4j vulnerability in progress right now.

I would also like to provide clarification that Shiny Server uses a Node module called Log4js which is a logging framework for JavaScript. This is not associated with Log4j which is a logging framework for Java. Log4js does not contain the vulnerability that Log4j does.

UPDATE - 2021-12-15
We have confirmed that RStudio Connect has never used Java nor Log4j. This means all older versions of RStudio Connect should also be free of the vulnerability.

Since it is possible to use Java in R via the rJava R package, and thus possibly Java libraries like Log4j, we would suggest that everyone perform audits on their own R code for this vulnerability if they use rJava.

UPDATE - 2021-12-16
We have released version 1.1.2 of shinycannon which updates Log4jto version 2.16.0. This fixes the initial CVE-2021-44228 Log4j vulnerability as well as the CVE-2021-45046 Log4j vulnerability introduced in Log4j version 2.15.0. Anyone using shinycannon should update to this newest version as soon as possible.

We have found older (and no longer supported) versions of RStudio Pro Drivers contained an instance of Log4j inside the MongoDB drivers (under rstudio-drivers/mongodb/bin/Tools/SchemaEditor/app/libs). However, the currently supported versions of RStudio Pro Drivers do not contain the rstudio-drivers/mongodb/bin/Tools/SchemaEditor folder anymore. Thus, as stated earlier, our currently supported versions of our products do not have the vulnerability.

All further questions or concerns in relation to RStudio's products and the Log4j vulnerability should be directed to security@rstudio.com.

[jowest1]

Hi, please can I check that of the following Libraries we use, none are written in Java/affected by the Log4j issue?
Tidyr
Dplyr
Ggplot2
Haven
Lfe

Thank you

[kyle_hekhuis]

Hi jowest1,

I have asked Hadley, who is one of the primary developers of tidyverse (which those libraries you use are a part of), if any tidyverse libraries use rJava at all. He has informed me that rJava is not used in any of the tidyverse libraries and thus none of the libraries are affected by the Log4j issue.

-Kyle

[jiludvik]

I have done grep through RStudio source code for "log4j" and found a reference to the component in src/gwt/lib/gwt/gwt-rstudio/gwt-dev.jar. Similar search for "log4js" does not return any results.

I understand GWT is one of the open source components used by RStudio client.

Could you clarify why is Log4J in your source code when it is not used?

[ndejay]

Thanks for the update @kyle_hekhuis. Could you confirm whether possible vulnerabilities in users' R code (e.g. via rJava) could affect the port on which RStudio server (as a service) is running?

My guess is that it does not, but just wanted to confirm. My reasoning is that if an RStudio server (as a service) is configured to present an authentication page, arbitrary code making use of rJava/log4j can only be executed after authentication. An attacker could therefore not exploit this via the RStudio server port. If, however, this arbitrary code spins up a web server making use of rJava/log4j on another port, then this port (but not the RStudio server port) could be at risk.

Thanks for your help!
Nic

[awatts]

I downloaded src/gwt/lib/gwt/gwt-rstudio/gwt-dev.jar from the RStudio github repo which is a so-called "fat jar" (i.e. it has all of its dependencies bundled together instead of depending on other jars) and it uses Apache Commons Logging, which abstracts logging to allow various backends and has a class for logging with Log4J in it, but also has a number of other classes for other logging backends, so it would have to be specifically configured to use Log4J (they said in the original post that they have not ever used it). If they're using some other logging backend (they are), it's not going to do anything. Also, Commons Logging is so old (last release was in 2014) that it wouldn't even be for an exploitable version of Log4J anyway.