[Rd] Scanning a R script for potentially insidious commands

[Simon Urbanek]

On Dec 19, 2012, at 1:10 PM, Simon Urbanek wrote:

> On Dec 19, 2012, at 1:09 PM, Gabriel Becker wrote:
> 
>> Simon,
>> 
>> I don't really have a horse in this race (as I said I didn't write sandboxR), but it seems like if you control library (to prevent "untrusted" packages, specifically including things like Rcpp and Rffi), and dyn.load the executing arbitrary compiled code issue can be curtailed. If I'm wrong please let me know, I'm always looking to learn.
>> 
>> I assume XXXX in your example was some C code you whipped up and then loaded using one of the methods above? Or a .Call to an existing internal R function?
>> 
> 
> No, it's pure R code, I just didn't want to put the exploit on the list ...
> 

I just found another exploit that is harder to catch than the fist one. Both work by giving you unrestricted access directly to any function in any namespace or environment. The first one consists of 15 chars + the function name, the second takes 33 characters + function name (both work on base R, no extra packages needed). They use two entirely separate aspects of R to do it. I don't want to make this an exploit contest, I'm just trying to make the point that you cannot try to secure R by any kind of filtering or pre-processing, because the language is too flexible to make you feel secure. I would strongly discourage anyone from providing an open service that relies on filtering. There is a fairly high probability that the will be a way around it. That's why all realistic approaches work on the back-end.

Cheers,
Simon


> 
>> ~G
>> 
>> On Wed, Dec 19, 2012 at 9:12 AM, Simon Urbanek <simon.urbanek at r-project.org> wrote:
>> On Dec 19, 2012, at 11:21 AM, Gabriel Becker wrote:
>> 
>>> See also: https://github.com/Rapporter/sandboxR
>>> 
>>> sandboxR (not written by me) is a proof of concept for security inside R
>>> (as opposed to security outside R as discussed above) via evaluating all R
>>> commands in a specialized security environment (R environment that is)
>>> which contains safe replacements for blacklisted functions.
>>> 
>> 
>> It is a good example of false security. For the reasons mentioned before this doesn't work and can be circumvented:
>> 
>>> sandbox("XXXX('tail /etc/group')")
>> _developer:*:204:
>> _locationd:*:205:
>> _carddav:*:206:
>> _detachedsig:*:207:
>> _trustevaluationagent:*:208:
>> _odchpass:*:209:
>> _timezone:*:210:
>> _lda:*:211:
>> _cvms:*:212:
>> _usbmuxd:*:213:
>> [1] 0
>> 
>> The problem is that you can try to plug holes (and sandboxR is trying hard to plug a lot of them), but there will always be new ones. It's simply the wrong approach IMHO.
>> 
>> Cheers,
>> Simon
>> 
>> 
>> 
>>> HTH,
>>> ~G
>>> 
>>> 
>>> 
>>> On Wed, Dec 19, 2012 at 5:33 AM, Dirk Eddelbuettel <edd at debian.org> wrote:
>>> 
>>>> 
>>>> Jeroen has a package devoted to the sandboxing approach in conjunction with
>>>> the system-level AppArmor facility:  RAppArmor.  See
>>>> 
>>>> http://cran.r-project.org/web/packages/RAppArmor/index.html
>>>> 
>>>> and more details at
>>>> 
>>>> https://github.com/jeroenooms/RAppArmor#readme
>>>> 
>>>> Dirk
>>>> 
>>>> --
>>>> Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
>>>> 
>>>> ______________________________________________
>>>> R-devel at r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Gabriel Becker
>>> Graduate Student
>>> Statistics Department
>>> University of California, Davis
>>> 
>>>      [[alternative HTML version deleted]]
>>> 
>>> ______________________________________________
>>> R-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>> 
>>> 
>> 
>> 
>> 
>> 
>> -- 
>> Gabriel Becker
>> Graduate Student
>> Statistics Department
>> University of California, Davis
>> 
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
>