GHSA-43hj-fxwj-49qw: Erlang/membrane_mp4_plugin vulnerability
Summary
membranemp4plugin interns every 4-byte MP4 box name as a BEAM atom while parsing container headers, with no validation against an allow-list. Any code path that calls Membrane.MP4.Container.parse/1 (or the bang variant) on attacker-controlled MP4 bytes can be made to exhaust the BEAM atom table, which is uncapped at the source but bounded by the runtime ceiling (around 1,048,576 atoms) and never garbage-collected. Once the ceiling is hit, the entire BEAM node aborts.
Details
The MP4 container parser walks the input stream box-by-box. For each box, Membrane.MP4.Container.Header.parse/1 in lib/membranemp4/container/header.ex extracts the 4-byte name field and delegates to the private helper parseboxname/1, which trims trailing spaces and passes the bytes through String.toatom/1. Because String.toatom/1 creates a new atom unconditionally, every distinct attacker-chosen 4-byte sequence becomes a permanent allocation in the global atom table. Atoms are not subject to garbage collection, so unique names accumulate for the lifetime of the node.
The fix replaces the unsafe interning with String.toexistingatom/1 and treats unknown names as the :unknown atom downstream (with related plumbing in parsehelper.ex, serializehelper.ex, and the ISOM/CMAF demuxer engines so the new error variant flows through cleanly).
PoC
1. Generate an MP4-shaped payload of roughly 1.1 million minimal box headers, each 8 bytes long (4-byte size of 8, followed by a unique 4-byte ASCII name produced by enumerating combinations in the printable range). 2. Concatenate them into a single binary (~8 MB total). 3. Call Membrane.MP4.Container.parse!/1 on the binary inside any process running under the target BEAM node. 4. The node aborts once the atom table ceiling is reached.
Impact
An attacker who can get a single crafted MP4 file in front of any system that demuxes user-supplied media with membranemp4plugin can crash the entire BEAM node hosting that pipeline, taking down every Erlang/Elixir application sharing the runtime. No authentication, network position, or user interaction is required beyond delivering the file to whatever processing path eventually calls the parser.
References
Introduction commit: https://github.com/membraneframework/membranemp4plugin/commit/ae4bf04c393aa1562f3df3d33e20bc5cb8130de2 Patch commit: https://github.com/membraneframework/membranemp4plugin/commit/56373d1ddc86968e55fbde795c14eeba24357b57
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
erlang/membrane_mp4_pluginto a version that resolves this vulnerability.Fixed in 0.36.7 - Upgrade
Upgrade
membrane_mp4_pluginto a version that resolves this vulnerability.Patch 56373d1ddc86968e55fbde795c14eeba24357b57 - Configuration
Apply the fix so MP4 box names parsed in lib/membrane_mp4/container/header.ex use String.to_existing_atom/1 instead of String.to_atom/1, and route names that do not exist to the downstream :unknown atom (with the related plumbing changes in parse_helper.ex, serialize_helper.ex, and the ISOM/CMAF demuxer engines so the new error/unknown variant is handled cleanly).
membrane_mp4_plugin (MP4 container header parsing) parse_box_name/1 atom interning behavior = String.to_existing_atom/1 (unknown names mapped to :unknown)
Event History
Frequently Asked Questions
Which deployments are realistically exposed?
Any BEAM node that parses attacker-controlled MP4 bytes through Membrane.MP4.Container.parse/1 or its bang variant is exposed. An attacker can supply MP4 container headers containing many distinct 4-byte box names.
What does an attacker need to trigger the denial of service?
The attacker needs a code path that submits their MP4 data to the vulnerable container parser. No valid or recognized box names are required, because arbitrary distinct 4-byte names are converted into atoms.
What is the operational impact of successful exploitation?
Each distinct box name creates a permanent BEAM atom, and atoms are not garbage-collected. Repeated parsing of crafted inputs can fill the runtime atom table and cause the entire BEAM node to abort when its ceiling is reached.
What can be done if patching is not immediately possible?
Avoid parsing untrusted MP4 input with the affected parser until the fix is deployed. The fix uses String.to_existing_atom/1 and handles unknown names as :unknown rather than creating new atoms.