A less trusting Erlang.

[Calum-3]

Hello all,

I am an Erlang beginner, although I've been dipping in and out of it
for a while.

I'd like to use Erlang, and the built-in distributed meshing effect of
it to build a sort of IRC-plus distributed storage/messaging system
platform, of which each node would run the Erlang app.
However, I'd like to use avoid using lib_chan if possible, and just
use the native Erlang connectivity/distribution mechanisms.

The big problem then is that Erlang is way too trusting for connecting
to random people in the default
if-you-know-my-cookie-you-can-do-whatever-you-like mode.

The obvious thing (to me anyway) would be to limit the calls that
remote nodes can make - Erlang Untrusting, if you will, or Paranoid
Erlang.

Would it be possible to patch the core libraries that "accept/receive"
the spawn requests, and check them against a list of "allowed"
functions.
For example, if erl was run with the -paranoid parameter, it would
only allow calls which are listed in .erlang.allowed to be made from
remote nodes. Such a file might look like public:*, mystuff:another/1,
etc etc.

Would it require patching and recompiling of the source to Erlang, or
could the "receive" function be "overwritten" from the
shell/programatically?

Is this approach one that could work? Are there sufficiently few
places that could be restricted to make this solution secure? How much
of a patch would this be, or are there too many places to be able to
secure it with any degree of confidence?

And even if these restrictions were in place, would it provide a
high-enough level of security to prevent ne'er-do-wells doing things
like drain resources, insert code somehow, etc? Or would it be too
hard to prevent people passing in Funs, or doing other unexpected
things?

Hoping some Erlang heavyweights can provide some thoughts onto this
approach, and give some feedback on this idea.

C

PS. Apologies if this functionality already exists somewhere.

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[Jim McCoy]

The short answer is that you can't effectively prevent a node in a
distributed erlang setup from doing just about anything it wants to
another node.  It just doesn't work that way.  There was some effort a
while back to try to deal with these issues (see the SSErl work and a
long thread on the list from the summer of 2006 relating to E/Erlang
integration) but nothing concrete has come of it.

You are better off using a well-defined protocol at the trust
boundaries and not trying to let untrusted users make calls directly
into the trusted side of this boundary.

jim


On Sun, Oct 11, 2009 at 2:55 PM, Calum <caluml@...> wrote:

> [...]
> I'd like to use Erlang, and the built-in distributed meshing effect of
> it to build a sort of IRC-plus distributed storage/messaging system
> platform, of which each node would run the Erlang app.
> However, I'd like to use avoid using lib_chan if possible, and just
> use the native Erlang connectivity/distribution mechanisms.
>
> The big problem then is that Erlang is way too trusting for connecting
> to random people in the default
> if-you-know-my-cookie-you-can-do-whatever-you-like mode.
> [...]

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[Calum-3]

On Mon, Oct 12, 2009 at 5:21 AM, Jim McCoy <jim.mccoy@...> wrote:
> The short answer is that you can't

(with Erlang as it currently is)

> effectively prevent a node in a
> distributed erlang setup from doing just about anything it wants to
> another node.  It just doesn't work that way.  There was some effort a
> while back to try to deal with these issues (see the SSErl work and a
> long thread on the list from the summer of 2006 relating to E/Erlang
> integration) but nothing concrete has come of it.

I looked at SSErl, and seems as though it was an internal proof of concept.

> You are better off using a well-defined protocol at the trust
> boundaries and not trying to let untrusted users make calls directly
> into the trusted side of this boundary.

Which is all very fine, but then I'd end up duplicating (probably
badly) all the nice node discovery, linking, rpc stuff that Erlang has
got built in.
If Erlang didn't allow anyone to run anything, it'd be perfect - I'm
just curious as to whether it's fairly simple to limit it so.

In my very simplistic mind *, I'm imagining a recv_spawn function
squirrelled away in the source somewhere, which could have a few lines
added to check that the function being requested matches a list
(perhaps even as simple as being hardcoded to a module starting with
the word public).


C

* I'm sure it's not as easy as this - but I'm wondering if anyone with
knowledge of the internals of Erlang could tell me how many thousands
of miles off I am. :)

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[Jim McCoy]

The problem I am seeing with this is that it is not sufficient to just
prevent a remote node from running an apply() or calling certain
functions, you also have to prevent it from sending messages to places
you care about.  What happens to your system if my node connects and
then starts spraying exit signals around?  This is the hard part.  In
theory a pid() should be a relatively safe unguessable number, in
practice it is trivial to guess and there are built-in facilities to
make this task even easier. There are at least two parts to making
Erlang "internally secure": restricting function calls across trust
boundaries (as you have noted) and restricting message sending across
these same boundaries.  There are probably other components necessary
for this task, but those two jump right out as hard problems to solve.

jim

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[Jacob Torrey]

Could perhaps the pid generation in the VM be made more random,
therefore you can only gain access to pids that you know the name to?
This seems like an obvious (and pretty trivial) solution to obscure and
increase the security of the Erlang system.

Jacob

Jim McCoy wrote:

> The problem I am seeing with this is that it is not sufficient to just
> prevent a remote node from running an apply() or calling certain
> functions, you also have to prevent it from sending messages to places
> you care about.  What happens to your system if my node connects and
> then starts spraying exit signals around?  This is the hard part.  In
> theory a pid() should be a relatively safe unguessable number, in
> practice it is trivial to guess and there are built-in facilities to
> make this task even easier. There are at least two parts to making
> Erlang "internally secure": restricting function calls across trust
> boundaries (as you have noted) and restricting message sending across
> these same boundaries.  There are probably other components necessary
> for this task, but those two jump right out as hard problems to solve.
>
> jim
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
>

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[Robert Virding]

The trouble is is that there are no "special" processes in the system as
such. Messages from the outside will be routed to a normal Erlang process
which will then decide whether to ignore it or or treat it as a command and
execute it. So by only exposing certain processes which are "safe" then your
system is "safe".

How do you mean recv_spawn? There is nothing builtin to the emulator which
somehow takes a message and spawns a new process to handle it, it all done
in Erlang. I can't remember where it all handled but I would start by
checking out the module net_kernel which must be called to start networking.
From there you can probably work out how to restrict external access.

Robert

2009/10/12 Calum <caluml@...>

> On Mon, Oct 12, 2009 at 5:21 AM, Jim McCoy <jim.mccoy@...> wrote:
> > The short answer is that you can't
>
> (with Erlang as it currently is)
>
> > effectively prevent a node in a
> > distributed erlang setup from doing just about anything it wants to
> > another node.  It just doesn't work that way.  There was some effort a
> > while back to try to deal with these issues (see the SSErl work and a
> > long thread on the list from the summer of 2006 relating to E/Erlang
> > integration) but nothing concrete has come of it.
>
> I looked at SSErl, and seems as though it was an internal proof of concept.
>
> > You are better off using a well-defined protocol at the trust
> > boundaries and not trying to let untrusted users make calls directly
> > into the trusted side of this boundary.
>
> Which is all very fine, but then I'd end up duplicating (probably
> badly) all the nice node discovery, linking, rpc stuff that Erlang has
> got built in.
> If Erlang didn't allow anyone to run anything, it'd be perfect - I'm
> just curious as to whether it's fairly simple to limit it so.
>
> In my very simplistic mind *, I'm imagining a recv_spawn function
> squirrelled away in the source somewhere, which could have a few lines
> added to check that the function being requested matches a list
> (perhaps even as simple as being hardcoded to a module starting with
> the word public).
>
>
> C
>
> * I'm sure it's not as easy as this - but I'm wondering if anyone with
> knowledge of the internals of Erlang could tell me how many thousands
> of miles off I am. :)
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
>

[Raoul Duke]

On Mon, Oct 12, 2009 at 12:46 PM, Jacob Torrey
<discipleofranok@...> wrote:
> Could perhaps the pid generation in the VM be made more random,
> therefore you can only gain access to pids that you know the name to?
> This seems like an obvious (and pretty trivial) solution to obscure and
> increase the security of the Erlang system.

swiss numbers?

http://www.mail-archive.com/cryptography@.../msg02711.html

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[Calum-3]

On Mon, Oct 12, 2009 at 9:07 PM, Robert Virding <rvirding@...> wrote:
> How do you mean recv_spawn? There is nothing builtin to the emulator which
> somehow takes a message and spawns a new process to handle it, it all done
> in Erlang.

I was thinking of the code that gets run on the remote node when you
do something like
1> spawn('two@localhost', c, ls, []).
or the proverbial
2> rpc:multicall(nodes(), os, cmd, ["rm / -rf"]).

Something on the second node must receive that bunch of args - just a
small check at that point then to make sure the second arg is "public"
or similar - if not, it could then just refuse to pass that message on
to the rest of the code that actually runs it and returns the result.

Net result - in "paranoid mode" - you'd have to consciously expose any
public methods in a module called public.

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[Ulf Wiger-3]

Jacob Torrey wrote:
> Could perhaps the pid generation in the VM be made more random,
> therefore you can only gain access to pids that you know the name to?
> This seems like an obvious (and pretty trivial) solution to obscure and
> increase the security of the Erlang system.

You don't even need to bother with the pids:

{rex,Node} ! {'$gen_cast',{cast,M,F,A,user}}

...will allow you to execute any function on Node.

BR,
Ulf W
--
Ulf Wiger
CTO, Erlang Training & Consulting Ltd
http://www.erlang-consulting.com

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[Kenneth Lundin]

There has been plenty of thinking and prototyping in the area of
"SAFE" Erlang and the
solution is far from trivial. There are many aspects to consider.

Have a look at the following Master theses:

Safe Erlang.
Gustaf Naeser.
UU/CSD, 1997.
http://www.erlang.se/publications/xjobb/0109-naeser.pdf

Enhancing Security in Distributed Erlang by Integrating Access Control.
Rickard Green.
KTH, 2000.
http://www.erlang.se/publications/xjobb/d95-rgr.thesis.2s.pdf

Secure Distributed Communication in SafeErlang.
Bertil Karlsson.
KTH, 2000.
http://www.erlang.se/publications/xjobb/Secure_Dist_Comm_in_SafeErlang.pdf


We have not been able to prioritize work towards "SAFER" built in
distribution mechanisms
since the current implementation support local trusted networks well
enough and that
was the intended use from the beginning. This kind of distribution is still
the dominating.

It might whoever be the right time to do something in this area now.


/Kenneth Erlang/OTP Ericsson

On Tue, Oct 13, 2009 at 8:01 AM, Ulf Wiger
<ulf.wiger@...> wrote:

> Jacob Torrey wrote:
>>
>> Could perhaps the pid generation in the VM be made more random,
>> therefore you can only gain access to pids that you know the name to?
>> This seems like an obvious (and pretty trivial) solution to obscure and
>> increase the security of the Erlang system.
>
> You don't even need to bother with the pids:
>
> {rex,Node} ! {'$gen_cast',{cast,M,F,A,user}}
>
> ...will allow you to execute any function on Node.
>
> BR,
> Ulf W
> --
> Ulf Wiger
> CTO, Erlang Training & Consulting Ltd
> http://www.erlang-consulting.com
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
>

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[Jim McCoy]

As much as I would love to see some work go into making Erlang more
"internally secure" I would probably prefer to see the effort directed
at making it easier and less cumbersome to run distributed erlang
across untrusted networks.  Something as simple as a flag to make all
node-to-node communication run over SSL and a few of the previously
discussed tweaks to make epmd less susceptible to DoS attacks would
probably deliver more short-term benefit to the community at large.

jim

On Mon, Oct 12, 2009 at 11:45 PM, Kenneth Lundin
<kenneth.lundin@...> wrote:

>[...]
> We have not been able to prioritize work towards "SAFER" built in
> distribution mechanisms
> since the current implementation support local trusted networks well
> enough and that
> was the intended use from the beginning. This kind of distribution is still
> the dominating.
>
> It might whoever be the right time to do something in this area now.
>
>
> /Kenneth Erlang/OTP Ericsson
>

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[Jacob Torrey]

Ulf,
        If rex a required process? Is there any way to turn it off, or replace
it with a module of my choosing? Could you please point me to a
reference on rex, all I can find is a passing reference in erl_call.

                Jacob

Ulf Wiger wrote:

> Jacob Torrey wrote:
>> Could perhaps the pid generation in the VM be made more random,
>> therefore you can only gain access to pids that you know the name to?
>> This seems like an obvious (and pretty trivial) solution to obscure and
>> increase the security of the Erlang system.
>
> You don't even need to bother with the pids:
>
> {rex,Node} ! {'$gen_cast',{cast,M,F,A,user}}
>
> ...will allow you to execute any function on Node.
>
> BR,
> Ulf W

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[Ulf Wiger-3]

Jacob Torrey wrote:
> Ulf,
> If rex a required process? Is there any way to turn it off, or replace
> it with a module of my choosing? Could you please point me to a
> reference on rex, all I can find is a passing reference in erl_call.
>
> Jacob

Rex is the registered name of the rpc server.

The one way I know of to turn it off is to start erlang with
erl -mode minimal


Not really sure where -mode minimal is documented, though,
but rpc is not all it turns off - you get no Distributed Erlang
at all. So I don't think that solves your problem.

You should see this as an example of how difficult it is to make
Erlang safe if you allow remote processes to send messages. Since
any message can be sent to any process, 'rex' is just the most
obvious vulnerability to exploit.

You are much better off setting up a narrow pipe and allowing
only a small set of messages. Since most communication is
wrapped inside function calls, it really isn't as limiting as
you might suspect at first.

BR,
Ulf W

>
> Ulf Wiger wrote:
>> Jacob Torrey wrote:
>>> Could perhaps the pid generation in the VM be made more random,
>>> therefore you can only gain access to pids that you know the name to?
>>> This seems like an obvious (and pretty trivial) solution to obscure and
>>> increase the security of the Erlang system.
>> You don't even need to bother with the pids:
>>
>> {rex,Node} ! {'$gen_cast',{cast,M,F,A,user}}
>>
>> ...will allow you to execute any function on Node.
>>
>> BR,
>> Ulf W
>

--
Ulf Wiger
CTO, Erlang Training & Consulting Ltd
http://www.erlang-consulting.com

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[Max Lapshin-2]

Damn, it is impossible to establish security through obscurity. Just
imagine how funny would be, if any open
file in operation system has its unique file id and if you know this
file descriptor, you can write there.

Yes, Erlang lacks secure remoting, like any platform lacks. One of the
easiest way to build it is HTTP-based service.

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[Yogish Baliga]

We are using Erlang across data center boundary. We are using proto_dist as inet_ssl for communication between erlang nodes.  Also using min and max port setup provided by inet to limit the communication on a specific set of ports.

On each physical box, we have setup iptable based firewall.

-- baliga
 
"Point of view is worth 80 IQ points" --Alan Kay

http://dudefrommangalore.blogspot.com/





________________________________
From: Calum <caluml@...>
To: erlang-questions@...
Sent: Sun, October 11, 2009 2:55:11 PM
Subject: [erlang-questions] A less trusting Erlang.

Hello all,

I am an Erlang beginner, although I've been dipping in and out of it
for a while.

I'd like to use Erlang, and the built-in distributed meshing effect of
it to build a sort of IRC-plus distributed storage/messaging system
platform, of which each node would run the Erlang app.
However, I'd like to use avoid using lib_chan if possible, and just
use the native Erlang connectivity/distribution mechanisms.

The big problem then is that Erlang is way too trusting for connecting
to random people in the default
if-you-know-my-cookie-you-can-do-whatever-you-like mode.

The obvious thing (to me anyway) would be to limit the calls that
remote nodes can make - Erlang Untrusting, if you will, or Paranoid
Erlang.

Would it be possible to patch the core libraries that "accept/receive"
the spawn requests, and check them against a list of "allowed"
functions.
For example, if erl was run with the -paranoid parameter, it would
only allow calls which are listed in .erlang.allowed to be made from
remote nodes. Such a file might look like public:*, mystuff:another/1,
etc etc.

Would it require patching and recompiling of the source to Erlang, or
could the "receive" function be "overwritten" from the
shell/programatically?

Is this approach one that could work? Are there sufficiently few
places that could be restricted to make this solution secure? How much
of a patch would this be, or are there too many places to be able to
secure it with any degree of confidence?

And even if these restrictions were in place, would it provide a
high-enough level of security to prevent ne'er-do-wells doing things
like drain resources, insert code somehow, etc? Or would it be too
hard to prevent people passing in Funs, or doing other unexpected
things?

Hoping some Erlang heavyweights can provide some thoughts onto this
approach, and give some feedback on this idea.

C

PS. Apologies if this functionality already exists somewhere.

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[Calum-3]

On Wed, Oct 14, 2009 at 5:25 PM, Yogish Baliga <yogishb@...> wrote:
> We are using Erlang across data center boundary. We are using proto_dist as
> inet_ssl for communication between erlang nodes.  Also using min and max
> port setup provided by inet to limit the communication on a specific set of
> ports.
> On each physical box, we have setup iptable based firewall.
> -- baliga

Well, that would certainly make traversing unsecured networks fine -
but what about asking people to share computing resources who don't
necessarily trust each other with being able to run shell commands on
each other's machines?

I'm a little confused about the whole Pid conversation earlier though
- surely if you're only able to spawn a single function on my box that
I've defined, then Pids don't really come into it?

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[Bengt Kleberg]

Greetings,

The function you have allowed somebody to spawn on your machine can send
messages to any Pid.


bengt

On Wed, 2009-10-14 at 20:11 +0100, Calum wrote:

> On Wed, Oct 14, 2009 at 5:25 PM, Yogish Baliga <yogishb@...> wrote:
> > We are using Erlang across data center boundary. We are using proto_dist as
> > inet_ssl for communication between erlang nodes.  Also using min and max
> > port setup provided by inet to limit the communication on a specific set of
> > ports.
> > On each physical box, we have setup iptable based firewall.
> > -- baliga
>
> Well, that would certainly make traversing unsecured networks fine -
> but what about asking people to share computing resources who don't
> necessarily trust each other with being able to run shell commands on
> each other's machines?
>
> I'm a little confused about the whole Pid conversation earlier though
> - surely if you're only able to spawn a single function on my box that
> I've defined, then Pids don't really come into it?
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[Valentin Micic]

How about this:

(scon2@mmaker2)2> {ok, Pid} = yourmodule:start().
(scon2@mmaker2)3> unregister( rex ).
true
(scon2@mmaker2)4> register( rex,  Pid).
true

Original rex keeps running, but traffic is redirected to "yourmodule", which
is impersonating rpc server (rex).
Does not really turn the rpc server off, but the effects may be considered
the same.

V/

----- Original Message -----
From: "Ulf Wiger" <ulf.wiger@...>
To: "Jacob Torrey" <discipleofranok@...>
Cc: "Erlang Questions" <erlang-questions@...>
Sent: Wednesday, October 14, 2009 5:30 PM
Subject: Re: [erlang-questions] A less trusting Erlang.

> Jacob Torrey wrote:
>> Ulf,
>> If rex a required process? Is there any way to turn it off, or replace
>> it with a module of my choosing? Could you please point me to a
>> reference on rex, all I can find is a passing reference in erl_call.
>>
>> Jacob
>
> Rex is the registered name of the rpc server.
>
> The one way I know of to turn it off is to start erlang with
> erl -mode minimal
>
>
> Not really sure where -mode minimal is documented, though,
> but rpc is not all it turns off - you get no Distributed Erlang
> at all. So I don't think that solves your problem.
>
> You should see this as an example of how difficult it is to make
> Erlang safe if you allow remote processes to send messages. Since
> any message can be sent to any process, 'rex' is just the most
> obvious vulnerability to exploit.
>
> You are much better off setting up a narrow pipe and allowing
> only a small set of messages. Since most communication is
> wrapped inside function calls, it really isn't as limiting as
> you might suspect at first.
>
> BR,
> Ulf W
>
>
>>
>> Ulf Wiger wrote:
>>> Jacob Torrey wrote:
>>>> Could perhaps the pid generation in the VM be made more random,
>>>> therefore you can only gain access to pids that you know the name to?
>>>> This seems like an obvious (and pretty trivial) solution to obscure and
>>>> increase the security of the Erlang system.
>>> You don't even need to bother with the pids:
>>>
>>> {rex,Node} ! {'$gen_cast',{cast,M,F,A,user}}
>>>
>>> ...will allow you to execute any function on Node.
>>>
>>> BR,
>>> Ulf W
>>
>
>
> --
> Ulf Wiger
> CTO, Erlang Training & Consulting Ltd
> http://www.erlang-consulting.com
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[Garry Hodgson-2]

Yogish Baliga wrote:
> We are using Erlang across data center boundary. We are using proto_dist as inet_ssl for communication between erlang nodes.  Also using min and max port setup provided by inet to limit the communication on a specific set of ports.
>  
just curious.  have you noticed any significant performance degradation
going this route?


--
Garry Hodgson
AT&T Chief Security Office (CSO)

"This e-mail and any files transmitted with it are AT&T property, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited."



________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[Tony Arcieri]

On Sun, Oct 11, 2009 at 3:55 PM, Calum <caluml@...> wrote:

> The big problem then is that Erlang is way too trusting for connecting
> to random people in the default
> if-you-know-my-cookie-you-can-do-whatever-you-like mode.
>
> The obvious thing (to me anyway) would be to limit the calls that
> remote nodes can make - Erlang Untrusting, if you will, or Paranoid
> Erlang.
>

I was too lazy to search the thread, so sorry if this was already mentioned.

Are you looking for a capabilities model?  It seems like the Erlang
environment might be ideal for implementing one.  Does one already exist?

http://en.wikipedia.org/wiki/Object-capability_model

--
Tony Arcieri
Medioh/Nagravision