From jttkim at googlemail.com  Wed Dec 19 13:02:11 2012
From: jttkim at googlemail.com (Jan T Kim)
Date: Wed, 19 Dec 2012 12:02:11 +0000
Subject: [Rd] Scanning a R script for potentially insidious commands
In-Reply-To: <CAO1zAVbqQXsBEz7Uvdjqi0FxE2NxMb3fTZ5MuEFgn3KSaLb_xw@mail.gmail.com>
References: <50D06614.9060404@epiconcept.fr>
	<C388E3C2-611A-4717-8049-D72867AB8BCB@gmail.com>
	<CAO1zAVbqQXsBEz7Uvdjqi0FxE2NxMb3fTZ5MuEFgn3KSaLb_xw@mail.gmail.com>
Message-ID: <20121219120210.GA4036@paxarchia.galaxy.uni>

On Wed, Dec 19, 2012 at 12:39:21PM +0100, Joris Meys wrote:
> The safest way to prevent attacks using an R connector, is managing the
> permissions for the application on your own server. We do that with the
> RStudio Server application we have running. You have to take into account
> that R allows for many interactions with the system. Also file(), dir(),
> unlink() and all sys. functions have the potential to screen and possibly
> alter your system. Not only system() and eval() pose a security problem...

just out of curiosity, how do you disable these functions? Is there
a way to "blacklist" functions as such in R, regardless of what name
is used to call them? Simple string pattern matching (as I understand
Michael's "grepping" suggestion below) can be circumvented by using
the get function, as in

    s <- paste(letters[i], collapse = "");
    f <- get(s);
    f("insidiouscommand");

where i contains suitable indices to produce "system". So the system
function needs disabling as such, as there are innumerable ways to
code up its invocation.

> How to do this exactly, depends very much on both the server and OS
> settings and the specific R connector you use/build. But don't count on R
> alone to provide safety.

Personally, I'd suggest to consider long and hard whether executing
user submitted R code is really necessary, and if that's the case, my
inclination would be to run that on a virtual machine and sandbox that
as much as you can.

Best regards, Jan


> Cheers
> Joris
> 
> On Wed, Dec 19, 2012 at 12:28 PM, Michael Weylandt <
> michael.weylandt at gmail.com> wrote:
> 
> >
> >
> > On Dec 18, 2012, at 12:48 PM, Etienne S?vin <e.sevin at epiconcept.fr> wrote:
> >
> > > Hey all,
> > >
> > > We are building a R connector for our web application.
> > > The user can upload a script so it can be executed on the server.
> > >
> > > Is there a way to scan the script for insidious commands (writing on the
> > > disk for example) and purge them out?
> >
> > Completely, not that I know of: but grepping for system() and eval()
> > should catch a majority of red flags.
> >
> > Michael
> >
> > > I guess a simple search is not enough so is there a way to analyse the
> > > pseudo code?
> > >
> > > Best,
> > >
> > > Etienne
> > >
> > > ______________________________________________
> > > R-devel at r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> > ______________________________________________
> > R-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> 
> 
> 
> -- 
> Joris Meys
> Statistical consultant
> 
> Ghent University
> Faculty of Bioscience Engineering
> Department of Mathematical Modelling, Statistics and Bio-Informatics
> 
> tel : +32 9 264 59 87
> Joris.Meys at Ugent.be
> -------------------------------
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
> 
> 	[[alternative HTML version deleted]]
> 

> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel


-- 
 +- Jan T. Kim -------------------------------------------------------+
 |             email: jttkim at gmail.com                                |
 |             WWW:   http://www.jtkim.dreamhosters.com/              |
 *-----=<  hierarchical systems are for files, not for humans  >=-----*



[Rd] Scanning a R script for potentially insidious commands
Jan T Kim