[R] R Tools Security Posture

Marc Schwartz m@rc_@chw@rtz @end|ng |rom me@com
Wed May 17 13:35:40 CEST 2023


An additional resource that was not listed below is the R Software Development Life Cycle (SDLC) document that is available here:


which addresses a subset of the issues raised.


Marc Schwartz

On May 17, 2023 at 4:52:27 AM, Ivan Krylov (krylov.r00t using gmail.com (mailto:krylov.r00t using gmail.com)) wrote:

> В Tue, 16 May 2023 13:47:19 +0000
> "MAJID, Ayesha \(NHS ENGLAND - X26\) via R-help"  
> пишет:
> > * When was the application last updated?
> > * How often is it updated?
> This information is publicly available at
> by looking for "Release plans". You
> can reach this page by starting at and
> clicking the "Developer Pages" link. The developer pages are admittedly
> harder to navigate than the main website, but I think that they could
> answer some of your other questions too.
> You can also obtain this information by looking for "News" under
> and by checking the dates of all released
> versions of R at .
> > * Is the source code anywhere? If so where is
> Yes, you can download release source code by following the "download R"
> link at , ending up at
> https://cloud.r-project.org/ (or your preferred CRAN mirror) and
> clicking the link for the currently-latest version, R-4.3.0.tar.gz.
> The link to the Subversion repository containing yet unreleased code
> can be located at https://developer.r-project.org/.
> > and is it secure?
> What's the threat model?
> > * Are there any common vulnerabilities?
> What would be considered a vulnerability in a piece of software that
> was never supposed to be a security boundary?
> (Will R run arbitrary code typed at its prompt? Yes, by design. Is it
> possible to feed maliciously-constructed data into R's unserialize()
> and cause arbitrary code execution this way? Probably, but typing code
> at the prompt is much easier. Can third-party R packages that start TCP
> servers be convinced to run arbitrary code on attacker's behalf?
> Consider that a given.)
> > * Do your employees (e.g., developers or system administrators)
> > have access to customer data?
> By itself, R processes any data fed into it locally, on the computer
> where it's running, without contacting R developers about it.
> The same cannot be guaranteed about third-party packages, although
> there are tests and reviews at both CRAN and Bioconductor in order to
> prevent the packages from doing anything considered "anti-social". (See
> for more
> information on this.) A sufficiently motivated malicious actor could
> circumvent them, of course, but that can be said about anything.
> If someone at NHS wants to use R, they will probably want to use CRAN
> and Bioconductor packages too. Potentially, they might need packages
> published elsewhere as well. All these packages will have to be
> reviewed separately from R, because they are maintained by different
> people.
> > * Does R require third party authorization/connections?
> No, but shouldn't you be more concerned with third-party software
> dependencies?
> (Did you mean to ask these questions at the public mailing list open
> for J. Random Hackers like me to answer?)
> --
> Best regards,
> Ivan
> ______________________________________________
> R-help using r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

More information about the R-help mailing list