5

I heard that an atom table can fill up in Erlang, leaving the system open for DDoS unless you increase the 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?

Kijewski
  • 25,517
  • 12
  • 101
  • 143
randombits
  • 47,058
  • 76
  • 251
  • 433

2 Answers2

12

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.

Lukas
  • 5,182
  • 26
  • 17
-4

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.
Muzaaya Joshua
  • 7,736
  • 3
  • 47
  • 86
  • 8
    I'm fairly sure this is not right. The call to `list_to_atom` will *not* create a new atom if one already exists with the same 'name'. Therefore the `to_atom` function here will save nothing. The real problem here is creating atoms at all. If there is a way for an unlimited number of distinct atoms to be created then eventually you will run out of atom-space (they are never garbage-collected). Try to avoid this. – Steve Powell Jul 25 '11 at 20:22