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

[Eric Merritt]

 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.

This is mostly outside of what is possible with source code analysis
so I wouldn't worry to much about it.



> 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.

For the most part Erlang's distribution model is just not suitable for
production use in the comment network environment. There are pieces
you can use if you are careful but I end up mostly rolling my own. I
think this is due to the nature of the environment Distributed Erlang
was built for. I think that this environment consisted of a small
number of hardware nodes connected by a hardware tcp backbone. I think
this is pretty common inside telecom switches. Unfortunately, things
like network partitioning doesn't happen in that environment and so
wasn't addressed in the design. So distributed erlang is right out as
well ;)


> 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
>