Erlang: binary_to_atom fills atom tablespace security issue

Question

I heard that the atom table can be populated in Erlang, leaving the system open for DDoS unless you increase the number of atoms that can be created. Binary_to_existing_atom / 2 seems to be a solution.

Can someone explain how binary_to_atom/2 is a consequence of security and how binary_to_existing_atom/2 solves this problem?

Answer 1

When an atom is first used, it is assigned an internal number and placed in an array in a virtual machine. This array is distributed statically and can be filled if sufficiently different atoms are used. binary_to_existing_atom will only convert a binary string to an atom that already exists in the array, if it does not exist, the call will fail.

If you convert the input directly to atoms without any sanity checks, the external client can send <<"a" → and <"b" → until the array is full, at which point vm fails.

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

Answer 2

list_to_atom / 1 and binary_to_atom / 1 are very serious errors in erlang code. Always create an important function:

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

Thus, if an atom already exists in the Atom table, the try body avoids creating the atom again. It was created only at the first call of this function.