Thanks for the heads-up. What are the type of attacks that you expect R users might be affected by? Most problems discussed on the libcurl mailing lists are local vulnerabilities. E.g. an out-of-bounds read or buffer overflow exploit doesn't do anything that can easily be done from R itself?
I guess the worst case scenario would be if a server can trigger a remote code execution by sending a specially crafted payload or so. I'll keep my eyes open for that. The macOS binaries are dynamically linked, so they will be fixed when Apple pushes out an update for libcurl.dylib. On Windows we would need to a rebuild. AFAIK, R based services like shiny rely on mandatory access control and explicitly assume remote code execution by the client is possible/allowed. Assuming anything else would be silly, code execution can be triggered anywhere in R, you really don't need an exploit for that :-) More generally, I wonder how useful it is to keep external C libraries to high security standards while code from CRAN binding to those libraries is not reviewed at all. In practice there are probably more vulnerabilities in the C code for the 'curl' package than libcurl itself. It would be really interested having a broad discussion outlining the most imminent threats for R users. I wrote a paper [1] about security in R a few years back highlighting some issues, but not many people seemed to bother. Perhaps that has changed. [1] http://dx.doi.org/10.18637/jss.v055.i07 Jeroen On Fri, Oct 21, 2016 at 4:48 PM, Bob Rudis <b...@rud.is> wrote: > (didn't know where else to post this, but pkg authors seemed to be a > good group to run this by) > > Some folks may know I work in cybersecurity and my org's been talking > with the curl/libcurl community regarding: > https://curl.haxx.se/mail/lib-2016-10/0076.html > > TLDR: there's a new libcurl/curl coming out in early November which > contains a number of serious security fixes (which you'll have to wait > until they disclose them publicly to know, unfortunately). > > There are an ever increasing number of orgs/users who work with pkgs & > their own code that rely on the curl & RCurl pkgs and it is really > going to be in their best interest to upgrade curl/libcurl and rebuild > the pkgs, especially if they run them in a server (e.g. Shiny, model > feature generation, automated scraping) context. > > I don't use Windows regularly, but IIRC CRAN builds binaries for both > RCurl & curl that are either statically linked to libcurl or bundle > the shared library. I don't remember if that's true for macOS binaries > (I tend to build my envs from verified source for various paranoid > reasons). > > My q is that how do we [widespread] encourage/inform users to upgrade > libcurl and re-install the pkgs? > > I can (and will) be sending the R Core folks a note (tho they are all > prbly on here) when the new code is released, but there are many folks > who won't even see this and who really should upgrade. > > Most processes involving R & libcurl/curl aren't going to be directly > attacked or susceptible, but we've (my org) has been informed that > these are going to be some pretty critical vulns (again, I can't talk > more abt it) and most R users aren't going to be watching for vulns in > this context, so I'm just trying to figure out the best way to get the > word out the largest R audience. I'll be posting something on > R-bloggers after the release, but I'm hoping others can help get the > word out as well. > > thx, > > -Bob > > ______________________________________________ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
