Skip to content

[R-pkg-devel] New libcurl coming / question for pkg authors

2 messages · Bob Rudis, Jeroen Ooms

#
(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
1 day later
#
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 <bob at rud.is> wrote: