[erlang-questions] Securing remote spawning

[Sean Hinde]

If you allow authentication and connection via the normal erlang  
distribution then everything is wide open.

If you do not allow this connection (e.g. by forewall, and having a  
secret cookie), and hence only allow a custom protocol then you can  
control it completely. There is no "default" remote spawning over my  
proposed protocol, or HTTP or...

Sean

On 23 Apr 2008, at 21:59, <maarten@REDACTED> wrote:
> That was what I was expecting (as a mechanism). This looks like  
> Erlang is vey powerful but the power cannot be contained easily in  
> non-closed (or non-trusted) environments.
>
> Because if I understand correctly, I'd also have to shut down the  
> "default" remote spawning mechanism on the receiving side.
>
> --Maarten
>
> ---------------------------------------------------------
>
>
> From:     Torbjorn Tornkvist <tobbe@REDACTED>
> Date:     4/23/08 20:49Subject:  Re: [erlang-questions] Securing  
> remote spawning
>
>
> Couldn't the ssh lib be used in order to do authenticated rpc calls ?
>
> --Tobbe
>
>
> Matthias Lang wrote:
>> Sean Hinde writes:
>>
>>> It is very easy to roll your own RPC:
>>>
>>> call(Sock, M,F,A) ->
>>>     gen_tcp:send(Sock, erlang:term_to_binary(M,F,A)).
>>>
>>> Then at the other end:
>>>
>>> receive
>>>     {tcp, Sock, Data} ->
>>>         case erlang:term_to_binary(Data) of
>>>             {M, F, A} when is_list(A) ->
>>> 	         case lists:member({M,F,length(A)}, Allowed_funcs) of
>>>                     true ->
>>>                         apply(M,F,A);
>>>                     false ->
>>>                          ignore
>>>                  end;
>>>             _ -> ignore
>>>        end
>>>
>>> etc
>>
>> This example illustrates the general idea, and you can (and should!)
>> robustify it in practice if you want to deal with potentially
>> malicious clients.
>>
>> A starting point would be to eliminate binary_to_term/1 (which is  
>> what
>> Sean meant to write in the 'receive' above, where he wrote
>> 'term_to_binary'). binary_to_term/1 is too general and too
>> powerful. Not only can a client launch a DOS attack using it (by
>> overflowing the atom table), but there have been quite a few examples
>> of how to crash the emulator with it:
>>
>>  http://www.erlang.org/pipermail/erlang-questions/2001-June/003332.html
>>  http://www.erlang.org/pipermail/erlang-questions/2006-February/018901.html
>>  http://www.erlang.org/pipermail/erlang-bugs/2008-February/ 
>> 000634.html
>>
>> Matt
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions