On 10/20/2011 08:42 AM, Jonathan Langevin wrote:
Don't the other KVs implement M/R as well? If so, how is it they
don't have a similar exploit? Is this issue due specifically to
Basho's usage of Erlang for processing M/R?
Is it possible to circumvent this type of exploit by running Erlang
& Riak as unprivileged users?
Seems sandboxing may be needed for all nodes to ensure server
integrity. If someone made it into a node somehow (regardless of
public availability), it's still quite a concern that they could then
exploit Riak to gain root access.
I've actually been looking into this. MongoDB, for instance, exposes a
delightful javascript shell with a version of Spidermonkey (and, it
appears, V8 and Java! Even *more* surface area!) which could be
susceptible to arbitrary-code-execution attacks. There are some
interestingly named functions in their JS context, like "nativeHelper",
and a few undocumented server control functions, but without any real
comments in their source tree I'm finding it hard to follow.
I *do* know that multitenant mongo is vulnerable to trivial
denial-of-service vulnerabilities, thanks to a global write lock and
gleefully executing javascript everywhere. While we're talking DoS, it's
worth mentioning that if you can convince a sufficiently large riak
cluster to list-keys, it *will* go down.*
As for privileges; Basho's debian packages set up Riak as an
unprivileged user, and I presume most sysadmins are doing something
similar. In most cases, having full access to db data files is scary
enough to warrant caution. It doesn't stop there, however.
After exploiting the javascript VM one could inject an executable onto
the system; some small payload designed to get an interactive shell or
execute code from a remote server. There are many ways to escalate
privileges under linux--some direct (e.g.
http://www.exploit-db.com/exploits/15704/), some relying on other
services. From there, install a rootkit and proceed to neighboring boxes.
There are some easy ways to mitigate the damage caused by taking control
of the riak process; running riak in a chroot jail, for instance, and
aggressively tracking security patches for your operating system. You
can also disable erlang mapreduce and restrict the functions exported to
the javascript context... but these are deterrents, not failsafes.**
The answer is not to ban mapreduce (or distributed code execution of any
kind). The answer is to avoid running code from people in dark alleys on
a system you care about.*** :)
--Kyle
* http://twitter.com/#!/aphyr/status/124275497042591746/photo/1/large
** e.g. http://www.cvedetails.com/cve/CVE-2011-2998/. They won't show
you the bugzilla page unless you're on the sec team, so you *know* it's
juicy. :)
*** The best mapreduce system I can think of would be one with provable
execution consequences. Perhaps something like GHC (the haskell
compiler) could verify that one's mapreduce phases are purely
functional--or control which side-effect functions were exposed in
various contexts. Combine that with a memory/cpu/time budget for each
function.
_______________________________________________
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
