[erlang-questions] Automated Code Scanning of Erlang Source for Security

[Bruce Fitzsimons]

Eric Merritt wrote:
> So here is my question, finally. What type of, possibly detectable,
> security issues are related to Erlang? aside from the ones already
> mentioned.
>   
I think, given the distributed model that Erlang systems encourage, that 
the problem needs a little more definition. Are you defending against 
code you import containing [maliciousness, trojan horses, worms], 
compiled code you run on the same VM containign the same, systems you 
interwork with doing badness to your node, etc. It isn't just code, it 
is system architecture too, so my answer goes outside what Dialyzer may 
be able to analyse.

1. Someone started a discussion a while ago that pointed out the 
limitations of the distribution security; you can put a crispy shell 
over it (by changing the transport) but fundamentally the cookie system 
is a chewy centre. It is "good enough" for most systems but a 
defence-in-depth strategy would probably have a more secure mechanism 
for authentication, probably with some reaction mechanism for bad 
attempts (and that itself opening up DoS problems). I'm not aware that 
this exists today.

I don't think you can scan for this automatically. "Good cookie" 
selection, possibly per-node pair, and using ssl transport mitigates it 
a bit.

2. Darius (I think) noted that if you give outside code a chance to run 
on the VM then it can peer inside other modules.  This allows all kinds 
of mischief. A "blessed" security mode for some functions doesn't sound 
fine-grained enough, and shell only availability (yurk) would stop some 
useful programs from functioning.

You could obviously scan for the use of these functions programmatically.

3. I think the list has previously noted the DoS potential of queue 
slowdowns by sending unmatched messages to a process. Defensively you 
could do a generic match->throw away in the receive loops (gen_xxx 
templates already do this).

I think this is detectable, but it assumes the crispy shell has been 
penetrated.

4. OS calls of almost any type

5. File access, especially overwriting.

6. Port stuff, linked in drivers, etc

7. Hardcoded addresses/names in IP communication (e.g. getting the 
captured information out somewhere safe). This can be hidden quite well 
so that it is statically defined but not obviously so.

8. mnesia/dets destructive operations, mainly the "delete/clear the 
entire table/schema" ones

9. Access to commonly named mnesia tables ("user/s") from more than one 
module. Possibly human language dependent...so maybe broaden it to 
modules that write to the same table from different modules. There is 
the great risk of inflicting design guidelines on other people though, 
and I'm more cognisant that "other people are weird" after some of my 
discussions on #erlang. ;-)

This is fun :-) I'm sure there are more.

Cheers,
Bruce