Erlang: binary_to_atom filling up atom table space security issue

I heard that an atom table can fill up in Erlang, leaving the system open for DDoS unless you increase th开发者_Go百科e number of atoms that can be created. It looks like binary_to_existing_atom/2 is the solution to this.

Can anyone explain exactly how binary_to_atom/2 is a security implication and how binary_to_existing_atom/2 solves this problem?

---

When an atom is first used it is given an internal number and put in an array in the VM. This array is allocated statically and can fill up if enough different atoms are used. binary_to_existing_atom will only convert a binary string to an atom which already exists in the array, if it does not exist the call will fail.

If you are converting input data directly to atoms without doing any sanity checks it would be possible for an external client to send <<"a">> and <<"b">> until the array is full at which point the vm will crash.

Another way to avoid this is to simply not use binary_to_atom and instead pattern match on different binaries and return the desired atom.

---

list_to_atom/1 and binary_to_atom/1 are very serious bugs in erlang code. Always create a major function like this:

to_atom(X) when is_list(X) -> 
  try list_to_existing_atom(X) of
     Atom -> Atom
  catch
    _Error:_ErrorReason -> list_to_atom(X)
  end.

In this way, if the atom already exists in the Atom table, the try body avoids creating the atom again. Its only created the first time this function is called.