Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do 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

Fechada
  • Algo errado?
#420 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
65/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
ruby, rust
Domínio
cli, security

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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

Linguagem predominante
Rust
Estrelas
8
Forks
0
Merge médio
1d 1h
PRs com merge (30d)
257

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de SocketDev/socket-patch

Todas as issues de SocketDev/socket-patch

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.