Jordan Harband

Nas funções `nvm ls remote index tab`, `nvm remote version` e `nvm ls cached`, o padrão de versão solicitado é passado ao `grep` como um argumento simples, sem a flag `-e`. Um arquivo `.nvmrc` cuja primeira linha comece com `-`, como `-Rohenpm [A-Za-z0-9]*`, pode ser interpretado como opções do `grep`. Com o GNU grep, a opção `-R` realiza uma busca recursiva no diretório atual. Em um comando `nvm install` simples, o nvm trata qualquer string correspondente desses arquivos como a versão, exibindo-a e solicitando-a ao espelho configurado. Isso pode resultar na exposição de informações sensíveis, como um token do npm, vazando-o para o terminal e para os logs do espelho ou de qualquer proxy. A exposição é apenas de leitura e limitada aos caracteres `0-9A-Za-z. +-`.

Existe um problema onde o `nvm ls-remote` e outros comandos que atualizam aliases LTS remotos armazenam a coluna de versão do `index.tab` do espelho em `$NVM DIR/alias/lts/` sem validação. A função `nvm normalize lts()` posteriormente avalia qualquer sufixo de um valor `lts/-N` dentro da aritmética de shell `$((N+1))`. No bash e zsh, essa avaliação aritmética expande substituições de comando em subscripts de array, permitindo que um valor armazenado como `lts/-10*path[$(cmd)1]` execute `cmd` como o usuário. Isso ocorre quando o alias é resolvido por comandos locais como `nvm ls`, `nvm alias`, `nvm use --lts` e `nvm which lts/`, ou em cada novo shell se o alias `default` estiver definido como `lts/*`. Isso também pode ser acionado via um arquivo `.nvmrc` do projeto. A exploração requer o uso de um espelho hostil, que pode ser alcançado através de um espelho ou CDN comprometido, um ataque de man-in-the-middle de rede em um espelho `http://` ou uma variável `NVM NODEJS ORG MIRROR` configurada maliciosamente.

A função `nvm download artifact` baixa um arquivo de lançamento para `$NVM DIR/.cache` e verifica a soma de verificação (checksum) após a conclusão do download. Se ocorrer uma divergência na soma de verificação, o sistema relata um erro, mas mantém o arquivo rejeitado no cache. Um comando `nvm install --offline` subsequente para a mesma versão instala o arquivo em cache sem realizar a verificação da soma de verificação. Isso permite que um invasor que possa modificar o tarball baixado, como por meio de um CDN envenenado ou objeto de cache, execute código quando a vítima executar a instalação offline após uma tentativa de soma de verificação malsucedida.

Quando a variável `NVM AUTH HEADER` está configurada, a função `nvm download()` passa as credenciais para o curl ou wget como um argumento de linha de comando. Como os argumentos do processo são visíveis para todos os usuários locais no Linux e macOS, uma conta sem privilégios na mesma máquina pode ler o token durante a execução de comandos como `nvm ls-remote` e `nvm install`. Isso permite que o invasor obtenha acesso não autorizado ao espelho privado. Este problema afeta especificamente usuários que definem `NVM AUTH HEADER` em hosts compartilhados com outras contas locais.

Ao utilizar os comandos `nvm use --save` e `nvm install --save` (ou `-w`), o software grava a versão resolvida no arquivo `.nvmrc` usando `tee`, que segue links simbólicos. Se um repositório contiver um arquivo `.nvmrc` que seja um link simbólico para um caminho fora do repositório, a operação `--save` pode truncar qualquer arquivo que o usuário tenha permissão para gravar — como arquivos de inicialização do shell ou `~/.ssh/authorized keys` — e substituir seu conteúdo pela string da versão. Isso também pode criar o destino de um link pendente. Como o link simbólico em si permanece inalterado, a ação não aparece no `git status`. Este problema resulta em perda de dados, e não em execução de código, pois o invasor não pode controlar o conteúdo gravado.

O Node Version Manager (nvm) não verifica se o arquivo `.nvmrc` é um link simbólico. Um invasor pode fornecer um repositório ou arquivo que contenha um `.nvmrc` apontando para arquivos sensíveis, como `../../.npmrc` ou `/proc/self/environ` no Linux. Quando um usuário executa comandos como `nvm use`, `nvm install`, `nvm which`, `nvm exec`, `nvm run` ou `nvm-exec`, o conteúdo do arquivo vinculado é exibido em mensagens de erro ou de confirmação de versão. Isso pode resultar na exposição de informações se a saída for visível para o invasor, como em logs de CI. Além disso, usuários que utilizam o hook `load-nvmrc` do zsh ou o hook `cdnvm` do bash podem acionar esse comportamento apenas ao entrar no diretório.

Quando o arquivo `.npmrc` de um projeto define a variável `prefix`, o comando `nvm use` solicita que o usuário execute `nvm use --delete-prefix`. Esta ação aciona `npm config delete prefix` e `npm config delete globalconfig` no diretório atual sem especificar um arquivo de configuração. Como o npm carrega o `.npmrc` do projeto antes de determinar qual arquivo editar, um invasor pode manipular o arquivo alvo. Por exemplo, definir `userconfig=~/.bashrc` faz com que o npm reescreva o `~/.bashrc` como um arquivo ini, resultando em corrupção. Alternativamente, definir `location=global` e `globalconfig=` pode deixar o arquivo selecionado com permissões 0666, permitindo que outros usuários locais em uma máquina compartilhada escrevam nele. Isso pode ser explorado pelo autor de um repositório clonado ou por um usuário local com acesso de escrita a um diretório pai compartilhado.

O software mescla configurações do repositório de destino, especificamente do arquivo `.auto-changelog` e da chave `auto-changelog` no `package.json`, em suas opções e aceita configurações sensíveis de segurança dessas fontes não confiáveis. Isso permite a execução remota de código se a ferramenta for executada em conteúdo controlado por um invasor, como em fluxos de trabalho de CI que fazem o checkout de pull requests não confiáveis ou localmente em repositórios de terceiros. Especificamente, a opção `handlebarsSetup` é passada para `require()` e a opção `plugins` carrega módulos do repositório, ambos podendo executar código arbitrário com os privilégios do usuário ou do job de CI. Além disso, `appendGitLog` e `appendGitTag` permitem a injeção de argumentos do git, que podem ser usados para gravar arquivos arbitrários via flag `--output=`. A opção `output` permite gravar conteúdo influenciado por invasores em caminhos arbitrários, e a opção `template` pode disparar requisições externas para URLs escolhidas pelo invasor.

O fallback de JavaScript em `lib/sync.js` re-processa senhas que excedem o tamanho do bloco do digest (64 bytes, ou 128 bytes para sha384 e sha512) em cada iteração. Isso acontece porque a senha é passada ao HMAC como a chave em cada iteração, e o HMAC processa tais chaves integralmente todas as vezes. O custo computacional resultante é de O(iterações × comprimento da senha), o que pode bloquear o event loop ao processar senhas longas. Este fallback é acionado por `pbkdf2Sync()` e `pbkdf2()` no Bun versões 1.0.0 até 1.1.34 e 1.2.6 em diante, Deno 2.9.0 em diante, e Node.js versões anteriores a 0.12, bem como quando `lib/sync.js` é importado diretamente.

A função `quote()` emite um token `{ comment }` iniciando com `#`, que comenta o restante da linha do shell, incluindo as aspas de abertura de tokens de string subsequentes. Se uma string posterior contiver um terminador de linha (como ` `, `r`, `U+2028` ou `U+2029`), o comentário é encerrado e o restante da string é executado como entrada do shell. Além disso, a função `parse()` gera um token de comentário quando um caractere `#` aparece no meio de uma palavra. Isso pode causar problemas quando os chamadores combinam a saída de `parse()` com outras strings não confiáveis.

Existe um problema onde o comando `nvm ls-remote` e outros comandos que atualizam aliases LTS remotos, como `nvm install --lts`, analisam o arquivo `index.tab` do espelho do node.js e utilizam o campo de codinome LTS como um nome de arquivo de alias sem validação. Um espelho comprometido ou um ataque de man-in-the-middle pode retornar um codinome LTS contendo sequências de path-traversal, como `../../../.bashrc`. Isso permite que o software escreva strings de versão em caminhos fora do diretório `$NVM DIR/alias`. Em configurações padrão onde `$NVM DIR` é `~/.nvm`, isso pode resultar na criação ou sobrescrita de arquivos no diretório home do usuário, incluindo arquivos de inicialização do shell, potencialmente levando à execução de código em sessões de shell subsequentes. A exploração requer o uso de um espelho hostil via CDN comprometido, man-in-the-middle de rede ou uma configuração maliciosa das variáveis `NVM NODEJS ORG MIRROR` ou `NVM IOJS ORG MIRROR`.

A função `quote()` não valida as entradas de tokens de objeto em relação ao modelo de operador usado por `parse()`. Especificamente, o campo `.op` é escapado usando uma expressão regular que não corresponde a terminadores de linha, como ` `, `r`, `U+2028` e `U+2029`. Isso permite que terminadores de linha passem sem escape para a saída. Como os shells POSIX tratam novas linhas literais como separadores de comando, qualquer conteúdo após a nova linha é executado como um comando separado, resultando em injeção de comando. Este problema é acessível por meio da construção direta de `{ op: '... ...' }` a partir de entradas externas ou via `parse(cmd, envFn)` quando `envFn` retorna tokens de objeto cujo campo `.op` é influenciado por um invasor.

Nome do Software Vulnerável e Versões Afetadas Lodash versões 4.0.0 a 4.17.22 Descrição As versões 4.0.0 a 4.17.22 do Lodash são vulneráveis à poluição de protótipo nas funções ` .unset` e ` .omit`. Um atacante pode explorar caminhos elaborados para disparar a exclusão de métodos dos protótipos globais. O problema permite a exclusão de propriedades, mas não permite a modificação do comportamento original dessas propriedades. Recomendações Atualize para a versão 4.17.23 do Lodash ou posterior.