Hacker News Reader

Comment by orangea | Hacker News Reader

> What I ended up doing was making some scripts to install empty universal Erlang servers on all the Planet lab machines (pretty much like the code in this article) - then I set up a gossip algorithm to flood the network with become messages. Then I had an empty network that in a few seconds would become anything I wanted it to do.

But you already had an empty network that in a few seconds would become anything you wanted it to, that's how you installed empty universal Erlang servers on all the computers.

View on HN

The difference is I think that you hand off managing the distribution of the code to the Erlang VM, making it much easier to distribute anything else.

Of course security guys are going "Wait, every machine has an open RPC channel that will blindly execute code to every other machine???"

> security guys are going

It's a bit concerning if it's only "security guys" seeing issues with this approach.

A cluster of Erlang nodes in distribution don't have a security boundary once they're connected. Neither do two threads in the same process in a traditional system.

If that's an issue, and I can see why it might be for some, you'll need to use something other than Erlang distribution to connect your cluster.

You can patch out the explicit rpc server, but I'm not sure that you can patch out receiving functions (maybe removing the code that deserializes them from external term format would work?), and you'd need to audit the whole thing to ensure nothing ever calls a function it receives.

I'm not a security guy, so I can't speak for what their concerns would be.

I think my concern would be more in the realm of, you're inherently relying on whatever peer authentication system BEAM uses (and it being bug/exploit-free), to determine whether an RPC call can suddenly inject new code into a running system.

In my experience good security is a lot like an onion - there's lots of layers and generally some crying.

If we consider a "non-BEAM" system that runs on say JVM, or even a "scripting" runtime (e.g. PHP, Python, Ruby, NodeJS) - you typically have a number of elements that (can) contribute to making the code that runs, relatively immutable outside of a deployment event (e.g., restricting access to ssh/sftp/etc protocols; varying types of filesystem permissions; readonly volumes; container filesystems; etc)

Do other systems have similar "run arbitrary code" vulnerabilities? Sure. Allowing uploaded content to be executed by the PHP runtime is a classic example. But there's almost no legitimate purpose for this, it's almost certainly a configuration error/mistake, and it's relatively trivial to prevent it completely.

You can lock things down to your hearts content using features of your OS of choice.

You're not supposed to open the Erlang RPC port to the open Internet, and there is a modicum of security barrier with its cookie if you're so inept as to run Erlang on a non-firewalled server on the open Internet.

You don't need security people for basic sysadmin know how.

You do apparently need security or basic sysadmin knowhow to understand that not all security threats originate from "the open Internet"

So? How is this specifically relevant to the topic at hand?

If you have someone malicious in your internal network that can connect to your Erlang nodes, you have bigger issues that them connecting to your Erlang nodes.

I don't see the point of your original comment. Having an out-of-the-box RPC mechanism means you gotta secure it as you secure any other internal service. That's sysadmin 101.

> I don't see the point of your original comment. Having an out-of-the-box RPC mechanism means you gotta secure it as you secure any other internal service. That's sysadmin 101

Most RPC systems can't inject code into the running system dynamically. That's the point of my original post.

Yeah, but what happens when your local web browser is tricked into opening a socket to the local Erlang instance by a malicious web page? That's the kind of thing that keeps security professionals up all night.

It’s a binary protocol though, which means that this specific scenario isn’t an issue as far as I’m aware (the only ways of making arbitrary JS-controlled network requests are XHR/fetch(), which is only HTTP, and WebSockets, which have a handshake mechanism to ensure that the other side is really expecting a WS connection, which Erlang won’t be).

Reply on news.ycombinator.com