[erlang-questions] Automated Code Scanning of Erlang Source for Security
Sat Jul 7 00:47:28 CEST 2007
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
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
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
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.
More information about the erlang-questions