Atom-table exhaustion denial of service in Guardian via unbounded atom creation from binary keys
Summary
Allocation of Resources Without Limits or Throttling in ueberauth guardian allows denial of service via unbounded atom creation from attacker-influenced binary input.
Guardian.Plug.Keys derives connection and session namespace keys by passing arbitrary binaries to String.to\_atom/1. base\_key/1 in lib/guardian/plug/keys.ex converts any binary into the atom :"guardian\_<input>", and the derived helpers claims\_key/1, resource\_key/1, and token\_key/1 create a second atom on top of that. key\_from\_other/1 likewise converts a regex-captured binary through String.to\_atom/1. The public specs advertise String.t() as a valid argument, so passing a string is documented usage, and higher-level entry points such as Guardian.Plug.current\_token(conn, key: key) thread the caller-supplied key straight into these functions.
String.to\_atom/1 creates a brand-new atom for every previously unseen binary, atoms are never garbage collected, and the BEAM atom table is fixed at roughly 1,048,576 entries by default. An application that routes attacker-influenced data (a tenant identifier, header, or other request input) into a Guardian key therefore mints one permanent atom per distinct value. A modest stream of varied, unauthenticated input permanently consumes the atom table and crashes the BEAM node, taking down every application running on it.
This issue affects guardian: from 0.1.0 before 2.4.1.
Workaround
Do not derive Guardian keys from untrusted input. Use a fixed, hardcoded set of namespace keys, or validate the value against a bounded allowlist of known keys, before passing it as the :key option.
Configuration
Only applications that derive a Guardian key (the conn/session namespace) from attacker-influenced data are exploitable. This is the case when a caller-supplied value such as a tenant identifier, request header, or other request input is passed as the :key option to entry points like Guardian.Plug.current\_token/2. Applications that use a static namespace (the default :default key or hardcoded atoms) are not affected.
