Am I affected?
Description
Protection Mechanism Failure vulnerability in hexpm hex allows the owner of a package, or an attacker who has taken over the owner's account, to get a newly published release past the release-age cooldown.
The cooldown (cooldown config, HEX_COOLDOWN) withholds versions younger than the configured age during dependency resolution. When the release of a package locked in mix.lock is retired or has a security advisory, Hex.RemoteConverger.build_cooldown_bypass/3 and Hex.RemoteConverger.unsafe_lock_bypass/1 lift the cooldown for every version of that package and of every package the locked release depends on, so that mix deps.update can move off the unsafe release. Retiring a release needs the same package owner permission as publishing one. An attacker who publishes a malicious release can retire the currently locked release, and the next mix deps.update that unlocks the package selects the new release regardless of its age. Hex.Registry.Cooldown.versions/2 checks the bypass by package name alone, so the bypass also covers packages with the same name in other repositories. Cooldown configured through an organization dependency policy is not affected.
This issue affects hex: from 2.5.0 before 2.5.2.
Technical analysis
Hex.RemoteConverger.build_cooldown_bypass/3addsunsafe_lock_bypass(old_lock)to the set of packages exempt from the cooldown.unsafe_lock_bypass/1adds a package's name, and the names of its locked children, wheneverRegistry.retired/3orRegistry.advisories/3reports the locked version as unsafe.Hex.Registry.Cooldown.versions/2returns every version unfiltered for any package name in that set, so freshly published versions become eligible as soon as the package is unlocked.- hex.pm lets the package owner retire any of their releases, so the owner controls the trigger.
Hex.Policy.Filterapplies policy cooldowns without consulting the bypass set.
Proof of concept
- Lock
foo 1.0.0in a project withHEX_COOLDOWN=7d. - Publish
foo 1.0.1;mix deps.update fooreports it as filtered by cooldown and keeps 1.0.0. - Retire
foo 1.0.0. - Run
mix deps.update fooagain; it upgrades to the 1-hour-old 1.0.1.
Weaknesses & attack patterns
Weakness
CWE-693
·
Protection Mechanism Failure
in catalog →
MITRE ↗
Attack patterns
CAPEC-538
·
Open-Source Library Manipulation
MITRE ↗
The cooldown exists to keep a compromised release out of projects until it can be detected and retired. An attacker who controls a package owner account can defeat it by also retiring the currently locked release, so a malicious release reaches projects that rely on the local cooldown as soon as they run mix deps.update, including automated dependency update jobs. The malicious release's code then runs when the dependency is compiled.
Affected — Hex Mix Integration Repository ↗
modules · source files · routines
Affected — GitHub / hexpm/hex Repository ↗
modules · source files · routines
Workarounds
Enforce the cooldown through an organization dependency policy instead of the local cooldown setting, or run mix hex.audit before mix deps.update and don't update a package whose locked release was retired until its replacement has been reviewed.
Configurations
Affects projects that set the cooldown config or HEX_COOLDOWN and update dependencies with mix deps.update, or otherwise unlock the package during resolution. Cooldowns enforced through an organization dependency policy aren't affected.
Solutions
Upgrade Hex to 2.5.2 or later, for example with mix local.hex. A retired locked release then no longer lifts the release-age cooldown for its package. A locked release with a security advisory still lifts it for its package and the direct dependencies of the locked release, only in the repository the package is locked from.
References
Credits
CVSS breakdown
CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N