Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Gem `vex` checks the `gem env gemdir` copy instead of the `Gem.path` copy Ruby loads, so it attests `not_affected` while an unpatched `--user-install` / `GEM_PATH` copy runs

Ouverte
  • Quelque chose ne va pas ?
#420 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
65/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
ruby, rust
Domaine
cli, security

Piste de recherche

Start with crates/socket-patch-core/src/crawlers/ruby_crawler.rs:236-263 and inspect how gem_env_gems_dirs orders gemdir and gempath. Then read crates/socket-patch-cli/src/commands/vex.rs:556 and the gem rule in vex_consumed.rs. Reproduce the user-install or GEM_PATH case, and consider the issue complete when manifest-basis VEX results reflect the copy RubyGems and Bundler load, including the reverse-direction case.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

agent:triaged bug bughunt pm:bundler priority:p1

[agent] Found by the scheduled Bundler (RubyGems) bug-hunt routine (ledger #316).

Summary

When one gem@version is installed in more than one gem home, vex (agent / manifest basis, with or without -g) verifies only the first copy the ruby crawler lists. That's always the gem env gemdir home (the Ruby install's gem dir, or GEM_HOME). RubyGems and Bundler load the copy from the first Gem.path entry instead. Gem.path lists the user gem dir (gem install --user-install) and every GEM_PATH entry before GEM_HOME. So when the loaded copy is unpatched and the gemdir copy is patched, vex writes not_affected for code that is actually vulnerable at runtime. In the reverse case (loaded copy patched, gemdir copy not), it refuses to attest a patched install.

apply / get / rollback are fine. They fan out to every copy (#222), so right after get -g both copies are patched. The bug appears as soon as the loaded copy is reinstalled: gem install --user-install <gem> again, gem pristine --user-install, or a reinstall into a GEM_PATH home.

Impact

A false OpenVEX not_affected statement (inline_mitigations_already_exist) for a package whose loaded code is unpatched. This is the "VEX attestation for a patch that isn't actually applied" class. It hits both vex -g and plain vex in a Bundler project that uses system gems (no BUNDLE_PATH), because bundle exec also loads the user-dir copy.

Repro (Linux; a local mock of the patch API serves one patch for [email protected] that appends # SOCKET-PATCHED to lib/colorize.rb)

gem install colorize -v 0.8.1 --no-document                  # system gem home (gem env gemdir)
gem install --user-install colorize -v 0.8.1 --no-document   # ~/.local/share/gem/ruby/X (first in Gem.path)
SP="socket-patch --api-url http://127.0.0.1:18999 --api-token fake --org org"
$SP get -g 11111111-2222-4333-8444-555555555555 --yes        # patches BOTH copies (2 "Patched packages" lines)
gem install --user-install colorize -v 0.8.1 --no-document   # user reinstalls -> the copy Ruby loads is pristine again
ruby -e 'require "colorize"; f=$LOADED_FEATURES.grep(/colorize.rb/)[0]; puts f, File.read(f)[/SOCKET-PATCHED/] ? "PATCHED" : "UNPATCHED"'
#   /root/.local/share/gem/ruby/3.3.0/gems/colorize-0.8.1/lib/colorize.rb
#   UNPATCHED
$SP vex -g --product pkg:gem/[email protected] --output vex.json
#   Using ruby gem paths at: /opt/rbenv/versions/3.3.6/lib/ruby/gems/3.3.0/gems
#   Wrote OpenVEX document with 1 statement   (exit 0)
grep -o '"status": "[a-z_]*"' vex.json
#   "status": "not_affected"

The same thing happens with:

  • an explicit GEM_HOME=/tmp/gh GEM_PATH=/tmp/gp (Ruby loads /tmp/gp/..., vex -g checks /tmp/gh/...);
  • a plain Bundler project (gem "colorize", "0.8.1", no BUNDLE_PATH) with get <uuid> --mode agent and then vex. bundle exec loads the user-dir copy, and vex still says not_affected.

Reverse direction: when only the loaded user copy is patched, vex -g says omitting … (not_applied) and exits 1.

Expected vs actual

  • Expected: vex only attests what's applied to the code that runs. crates/socket-patch-cli/src/commands/vex_consumed.rs already states the gem rule for hosted-basis purls: "bundler loads whichever Gem.path home it hits first: ALL must verify". #222 also says the single-representative consumers pick "the copy bundler actually loads".
  • Actual: for manifest-basis purls, vex hashes only the crawler's first copy, and for gem homes that's always the gemdir copy, which isn't the one Gem.path resolves first.

OS × version (probe run below, plus local Linux)

OS Ruby / RubyGems / Bundler Gem.path[0] (loaded) vex -g after user-copy reinstall
Linux (sandbox) 3.3.6 / 3.5.22 / 4.0.17 ~/.local/share/gem/ruby/3.3.0 not_affected (also via GEM_PATH and plain vex)
ubuntu-latest 2.7.8 / 3.1.6 / 2.4.22 ~/.gem/ruby/2.7.0 not_affected
ubuntu-latest 3.3.10 / 3.5.22 / 2.5.22 ~/.local/share/gem/ruby/3.3.0 not_affected
ubuntu-latest 3.4.9 / 3.6.9 / 2.6.9 ~/.local/share/gem/ruby/3.4.0 not_affected
macos-latest (arm64) 2.7.8 / 3.1.6 / 2.4.22 ~/.gem/ruby/2.7.0 not_affected
macos-latest (arm64) 3.3.10 / 3.5.22 / 2.5.22 ~/.local/share/gem/ruby/3.3.0 not_affected
macos-latest (arm64) 3.4.9 / 3.6.9 / 2.6.9 ~/.local/share/gem/ruby/3.4.0 not_affected
windows-latest 2.7 / 3.3 / 3.4 user gem dir not reached: global discovery itself is broken on Windows (#421)

First bad version

This isn't a v5 regression. gem_env_gems_dirs already put gemdir first in v4.0.0 and v3.3.0 (checked in the source only).

Suspect code

  • crates/socket-patch-core/src/crawlers/ruby_crawler.rs:236-263 (gem_env_gems_dirs) pushes gem env gemdir first and then appends gem env gempath (which is already in Gem.path order and starts with the user dir / GEM_PATH). Using gempath order alone (it always contains gemdir) would match RubyGems.
  • crates/socket-patch-cli/src/commands/vex.rs:556 (collapse_to_first) verifies manifest-basis gem purls against one copy only. The hosted path in vex_consumed.rs already requires every gem copy to verify.

Probe run (macOS/Windows/Linux × Ruby 2.7/3.3/3.4): https://github.com/SocketDev/socket-patch/actions/runs/36816092864

Langage dominant
Rust
Étoiles
8
Forks
0
Merge moyen
18 h 4 min
PR mergées (30 j)
70

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de SocketDev/socket-patch

Toutes les issues de SocketDev/socket-patch

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.