Mcdope

pam usb provides hardware authentication for Linux using removable media. Prior to version 0.9.3, src/local.c reads XRDP SESSION with plain getenv(3) at the head of pusb local login while every other env consumer in the same function uses secure getenv(3). When pam usb.so loads into a setuid PAM host, the calling user controls the environment passed in. Clearing XRDP SESSION before invoking the host bypasses the explicit XRDP-deny rule. Other remote-detection signals (rmsvc, evdev, loginctl, utmp) may still catch the session, but the env-based detection alone is defeated. This issue has been patched in version 0.9.3.

pam usb provides hardware authentication for Linux using removable media. Prior to version 0.9.3, src/local.c (pusb get tty from display server) allocates a 4096-byte cmdline buffer, reads up to 4096 bytes from /proc//cmdline, then replaces every NUL separator with a space. When read(2) returns exactly 4096 bytes for any process the function inspects, the buffer ends without a terminator and the subsequent strstr() calls scan past the allocation boundary. The function is invoked during normal PAM authentication when DISPLAY is set, so the read fires for every process at auth time. Consequences are bounded: strstr output is a Boolean substring match (limited info-disclosure surface) but a hostile heap layout can produce a SIGSEGV that terminates the host PAM process. This issue has been patched in version 0.9.3.

pam usb provides hardware authentication for Linux using removable media. From version 0.8.0 to before version 0.9.3, the deny remote feature in pam usb uses /usr/bin/w -i to detect whether the authenticating user has an active remote tmux session. In pusb tmux has remote clients() (src/tmux.c), the IPv6 detection regex required exactly four explicit colon-separated groups of 1-4 hex digits (e.g. 2001:0db8:85a3:0000). Any IPv6 address in compressed notation — including loopback (::1), link-local (fe80::1), and global unicast addresses (2001:db8::1) — did not match this pattern. As a result the remote-client check silently returned "no remote clients" even when a remote tmux client was connected from such an address. This issue has been patched in version 0.9.3.

Existe uma condição de corrida de link simbólico (symlink race condition) na criação de diretórios de pad por dispositivo e por usuário. O software utiliza um padrão de verificação e ação (check-then-act), no qual chama `lstat()` para testar a existência e, em seguida, chama `mkdir()` separadamente para criar o diretório. Um invasor local pode vencer a corrida entre essas chamadas substituindo o caminho de destino por um link simbólico para um diretório sob seu controle. Se bem-sucedido, arquivos de bloco de notas de uso único (one-time pad) podem ser gravados em um local controlado pelo invasor, potencialmente expondo valores de pad futuros antes do uso ou interrompendo a autenticação.

O auxiliar de liberação de memória `xfree()` chama a função `free()` sem zerar previamente o conteúdo do buffer. Isso faz com que buffers alocados no heap contendo dados sensíveis, como bytes de one-time pad lidos do disco, sejam liberados sem serem limpos. Consequentemente, o conteúdo sensível permanece na memória heap liberada até que seja sobrescrito por uma alocação subsequente. Em cenários onde um primitivo de inspeção de heap esteja disponível ou exista uma condição de use-after-free, isso poderia permitir a recuperação de material de autenticação ou valores de pad de regiões de memória liberadas.

Existe um problema na função `pusb is loginctl local()` onde pode ocorrer um travamento por desreferência de NULL ao analisar a saída do loginctl. A função utiliza `popen()` para ler os resultados; se o campo Remote contiver apenas uma nova linha, o `fgets()` é bem-sucedido, mas o `strtok r(buf, " ", &saveptr)` retorna NULL. Um `strcmp(is remote, "no")` subsequente desreferencia esse valor NULL, levando a um comportamento indefinido, tipicamente um SIGSEGV (falha de segmentação), que trava o módulo PAM. Isso pode resultar no travamento de processos de autenticação, como `sudo` ou `login`, e pode negar o acesso a todos os usuários do serviço afetado, dependendo da configuração da pilha PAM.

Ocorre uma Negação de Serviço (DoS) por loop infinito durante a varredura da árvore de processos quando um processo pai é encerrado durante a autenticação. A função `usb get process parent id()` não inicializa a variável `*ppid` em caso de falha. Na função `pusb local login()`, a mesma variável é reutilizada como entrada e saída em um loop while; se o sistema não conseguir ler `/proc/<pid>/stat`, o PID não é atualizado, impedindo a terminação do loop. Isso faz com que o processo de autenticação, como sudo, sshd ou login, trave até que seja terminado forçadamente.

Este software fornece autenticação de hardware para Linux utilizando mídias removíveis. Existe uma falha onde a função `getenv()` permite a injeção de variáveis de ambiente na lógica de verificação local através das variáveis `XRDP SESSION`, `DISPLAY` e `TMUX`. Essas variáveis determinam se uma sessão é local ou remota. Quando um módulo PAM é executado no contexto de binários setuid, como `sudo` ou `su`, a função `getenv()` pode retornar valores controlados por um usuário local que manipulou o ambiente do processo.

O pam usb fornece autenticação de hardware para Linux utilizando mídias removíveis. O software chama a função `xmlReadFile()` com `flags=0` ao carregar o arquivo de configuração, o que permite que o libxml2 processe referências a entidades externas. Isso pode levar ao processamento de Entidades Externas de XML (XXE), onde o sistema pode realizar leituras de arquivos locais ou fazer conexões de rede externas durante a análise do XML a partir do contexto do processo de autenticação. A exploração requer que o arquivo de configuração contenha referências de entidades XML manipuladas. Como o arquivo de configuração pertence ao root, o acesso de escrita ao arquivo é necessário para a exploração; no entanto, o impacto é significativo, pois o módulo `pam usb.so` opera em contextos setuid, como `sudo` e `su`.

Este software fornece autenticação de hardware para Linux usando mídias removíveis. Existe uma condição de corrida ao atualizar um arquivo de bloco de notas de uso único (one-time pad), pois um arquivo temporário é criado usando a função `open()` sem a flag `O EXCL`. A falta de atomicidade permite que dois processos simultâneos abram o mesmo arquivo, fazendo com que a segunda gravação sobrescreva silenciosamente a primeira. Como o bloco de notas de uso único é o principal mecanismo de prevenção de replay, essa divergência pode causar falhas de autenticação ou criar uma janela para a reutilização do bloco.

Em `src/log.c`, um ponteiro estático de escopo de processo é gravado com o endereço de uma variável local de pilha durante cada invocação do PAM. Este comportamento viola o requisito de reentrada do PAM—a capacidade de uma função ser interrompida e chamada novamente de forma segura antes que sua invocação anterior tenha terminado—resultando em uma condição de corrida (data race) quando a pilha PAM é invocada simultaneamente por múltiplas threads.

O pam usb fornece autenticação de hardware para Linux usando mídias removíveis. O componente `pamusb-pinentry` lê a variável de ambiente `PINENTRY FALLBACK APP` e a executa sem validação. Um processo capaz de definir variáveis de ambiente antes que o `pamusb-pinentry` seja invocado pode apontar a `PINENTRY FALLBACK APP` para um binário ou script arbitrário, resultando na execução com os privilégios da cadeia de ferramentas do pam usb.

Em `src/device.c`, os valores de retorno das funções `udisks drive get serial()`, `udisks drive get vendor()` e `udisks drive get model()` são passados diretamente para `strcmp()` sem verificações de NULL. De acordo com a documentação da API GIO/UDisks, esses acessores podem retornar NULL para dispositivos que não expõem o campo correspondente. Passar um ponteiro NULL para `strcmp()` resulta em um comportamento indefinido, normalmente levando a um SIGSEGV (falha de segmentação), o que causa a falha do PAM e uma negação de serviço de login.

No arquivo `src/evdev.c`, a função `pusb has virtual input device()` ignora silenciosamente erros EACCES ao abrir os nós `/dev/input/event*`. Esse comportamento faz com que a função retorne 0, indicando que nenhum dispositivo virtual foi encontrado, mesmo que todas as chamadas `open()` tenham falhado devido a permissões insuficientes. Consequentemente, o chamador em `src/local.c` não consegue diferenciar entre a ausência real de dispositivos virtuais e uma varredura bloqueada por negação de permissão, levando o sistema a continuar a autenticação sem negar o acesso. Isso desativa efetivamente a detecção de desktop remoto durante a execução sem privilégios de root.

Existe um problema no sistema de autenticação de hardware para Linux onde pode ocorrer a injeção de shell. Um UUID manipulado na configuração pode levar à execução remota de código como root quando o comando `pamusb-conf --reset-pads` é executado. Este payload pode ser injetado durante o processo `--add-device` por meio de um dispositivo USB com um UUID de sistema de arquivos manipulado. Além disso, a variável `userName` da configuração XML é passada para a função `os.system()` no `pamusb-agent`, que invoca um shell.

No arquivo `src/tmux.c`, o software lê a variável de ambiente `$TMUX`, a divide por vírgulas e interpola o componente socket-path diretamente em um comando de shell executado através da função `popen()`. Como o valor é colocado entre aspas duplas sem a devida sanitização, um invasor pode usar um caractere de aspas duplas para encerrar a string e injetar sintaxe de shell arbitrária. Este processo é executado com privilégios de root dentro da pilha PAM, podendo levar à execução remota de código.

O recurso `deny remote` classifica incorretamente conexões remotas IPv6 mapeadas para IPv4 como sessões locais. Isso ocorre porque o sistema verifica o campo `ut addr v6` do `utmpx` usando uma guarda `if (utent->ut addr v6[0] != 0)`, que valida apenas a primeira palavra de 32 bits do campo de endereço de 128 bits. Endereços IPv6 mapeados para IPv4 (::ffff:x.x.x.x) armazenam o endereço IPv4 em `ut addr v6[3]` enquanto `ut addr v6[0]` permanece como 0. Em sistemas onde o daemon SSH escuta no curinga IPv6 (::) com AddressFamily any, como em configurações comuns do Ubuntu e Debian, as conexões IPv4 recebidas são registradas como endereços IPv6 mapeados para IPv4. Consequentemente, o bloco de detecção remota é ignorado e a sessão é tratada como local, permitindo que a configuração `deny remote=true` seja ignorada. Um invasor com acesso físico a um dispositivo USB registrado pode se autenticar via SSH como se estivesse em um terminal local.

Este problema ocorre no recurso `deny remote` do módulo PAM, que é carregado em processos do host como sudo, login, GDM e GNOME Shell. Em ambientes multi-threaded como o GDM, três funções utilizam a função não reentrante `strtok()`. Como a `strtok()` armazena o estado em um único ponteiro global, threads de autenticação simultâneas podem entrar em condição de corrida, permitindo que uma thread sobrescreva o ponteiro de tokenização de outra. Isso leva à análise incorreta de varreduras de ambiente `/proc` ou dados de sessão do tmux usados para detecção de sessão remota. Além disso, a função `pusb tmux get client tty()` passa um ponteiro bruto de `getenv(TMUX)` diretamente para a `strtok()`. Como a `strtok()` insere bytes NUL no bloco de ambiente do processo ativo, a variável `TMUX` é permanentemente corrompida para todo o código subsequente naquele processo. Consequentemente, quando `deny remote=true` está configurado, o sistema pode tomar decisões de autenticação incorretas para sessões remotas ou locais, dependendo do entrelaçamento de threads.

Em `src/mem.c`, proteções contra falta de memória para as funções `xmalloc()`, `xrealloc()` e `xstrdup()` foram implementadas usando `assert(data != NULL)`. Como as expressões `assert()` são removidas durante a compilação quando `NDEBUG` é definido no momento da construção—uma prática comum em builds de lançamento e empacotamento para Debian, Fedora e Arch—essas proteções são eliminadas em tais versões. Consequentemente, essas funções retornam NULL em caso de falha de alocação, que é então desreferenciado sem verificação, resultando em uma desreferência de ponteiro NULL e no travamento do módulo PAM. Isso cria uma condição de negação de serviço local, na qual um invasor que induza pressão de memória durante a autenticação pode bloquear todos os usuários do `sudo` e `login`.

A função `pusb pad compare()` em src/pad.c verifica apenas se o pad do lado do usuário (~/.pamusb/device.pad) pode ser lido, sem garantir que o pad do lado do sistema no dispositivo USB esteja presente e legível. Se o pad do usuário for excluído ou estiver ilegível, a função retorna uma falha que alguns caminhos de código tratam como não fatal, permitindo que a autenticação seja bem-sucedida sem a verificação do dispositivo USB. Consequentemente, um usuário local pode excluir seu próprio `~/.pamusb/device.pad` para ignorar a exigência do dispositivo USB físico.