⚡ Não perca: notícia importante no ar! ⚡
Confira agora e compartilhe com seus amigos!
Apoie esse projeto de divulgacao de noticias! Clique aqui
Uma leitura excessiva de heap no proxy web Squid pode vazar a solicitação HTTP de texto não criptografado de outro usuário, incluindo quaisquer credenciais ou tokens de sessão que ele carrega, para qualquer pessoa que já tenha permissão para enviar tráfego através do mesmo proxy.
O bug remonta a uma alteração na análise de FTP de 1997 e ainda está ativo na configuração padrão do Squid. Pesquisadores do Calif.io revelaram-no em junho e o chamaram de Squidbleed (CVE-2026-47729), em homenagem a Heartbleed, que vazou memória da mesma forma.
O Squid descreve isso como um ataque de um cliente confiável: alguém que já tem permissão para usar o proxy, e não qualquer host aleatório na Internet. Isso corresponde à casa habitual do Squid, redes compartilhadas como escolas, escritórios e Wi-Fi público. Nessas configurações, o invasor é apenas outro usuário do mesmo proxy.
O vazamento também atinge apenas o tráfego que o Squid consegue ler. O HTTPS normal percorre um túnel CONNECT opaco, então o Squid nunca vê dentro dele; o tráfego exposto é HTTP de texto simples, além de configurações de terminação TLS onde o Squid descriptografa e inspeciona.
O invasor também precisa do proxy para acessar um servidor FTP que ele controla na porta 21. Tanto o FTP quanto essa porta estão ativados por padrão.
Como funciona o vazamento
O bug está no analisador de listagem de diretórios FTP do Squid. Para lidar com servidores NetWare antigos que preenchiam listagens com espaços extras, o código ignora os espaços em branco com um loop: while (strchr(w_space, *copyFrom)) ++copyFrom;.
Se o servidor FTP do invasor enviar uma linha de listagem que termina logo após o carimbo de data/hora, sem nome de arquivo, copyFrom chegará ao terminador nulo da string. strchr trata esse término NUL como parte da string que pesquisa, portanto retorna um ponteiro em vez de NULL e o loop nunca para. Ele sai do final do buffer e o xstrdup copia o que segue de volta para o invasor como um nome de arquivo.
Os bytes vazados são a parte útil. O Squid reutiliza buffers de memória liberados sem zerá-los, portanto, um buffer de 4 KB que continha recentemente uma solicitação HTTP da vítima ainda contém a maior parte dele. Uma linha FTP curta substitui apenas os primeiros bytes; a leitura excessiva retorna o resto.
A demonstração do Calif extrai um cabeçalho de autorização de uma vítima que compartilha o mesmo proxy, o suficiente para agir como esse usuário. O código de prova de conceito é público e nenhuma exploração em estado selvagem foi relatada até o momento.
O que fazer
Se você corrigir, verifique a correção, não apenas a versão. Confirme se o guarda está em FtpGateway.cc, ou verifique o backport da sua distribuição, já que as distros enviam suas próprias compilações (pacotes Debian Squid 5.7).
O tópico público ainda é inconsistente: o mantenedor Amos Jeffries primeiro disse que o Squid 7.6 trazia a correção, depois corrigiu para 7.7 e, em 22 de junho, Salvatore Bonaccorso do Debian notou que o commit referenciado parece já estar na versão 7.6.
A correção é pequena, uma verificação de terminador nulo antes das chamadas strchr vulneráveis, mesclada ao branch de desenvolvimento em abril e à versão 7 em maio. O Squid 7.6 corrige separadamente o CVE-2026-50012, um estouro de heap cache_digest não relacionado.
A atitude mais limpa é aquela que os pesquisadores recomendam: desligar o FTP. O Chromium abandonou o FTP anos atrás, e a maioria das redes não carrega quase nada dele, portanto, desativá-lo remove essa superfície de ataque gratuitamente, qualquer que seja a versão que você execute.
O risco é real, mas limitado. A SUSE classifica-o como moderado, CVSS 6.5, e o vetor explica a pontuação: o invasor precisa de acesso proxy (privilégios baixos) e o único impacto é a confidencialidade, nada na integridade ou disponibilidade.
Calif credita ao Claude Mythos Preview da Anthropic, o modelo por trás do Projeto Glasswing, por capturar a peculiaridade do strchr quase imediatamente, o mesmo tipo de bug de analisador enterrado que os agentes de IA vêm surgindo em outros lugares, inclusive no FFmpeg. Calif sugere que o código FTP do Squid pode não ser o último lugar onde ele se esqueceu de parar de ler.
O bug remonta a uma alteração na análise de FTP de 1997 e ainda está ativo na configuração padrão do Squid. Pesquisadores do Calif.io revelaram-no em junho e o chamaram de Squidbleed (CVE-2026-47729), em homenagem a Heartbleed, que vazou memória da mesma forma.
O Squid descreve isso como um ataque de um cliente confiável: alguém que já tem permissão para usar o proxy, e não qualquer host aleatório na Internet. Isso corresponde à casa habitual do Squid, redes compartilhadas como escolas, escritórios e Wi-Fi público. Nessas configurações, o invasor é apenas outro usuário do mesmo proxy.
O vazamento também atinge apenas o tráfego que o Squid consegue ler. O HTTPS normal percorre um túnel CONNECT opaco, então o Squid nunca vê dentro dele; o tráfego exposto é HTTP de texto simples, além de configurações de terminação TLS onde o Squid descriptografa e inspeciona.
O invasor também precisa do proxy para acessar um servidor FTP que ele controla na porta 21. Tanto o FTP quanto essa porta estão ativados por padrão.
Como funciona o vazamento
O bug está no analisador de listagem de diretórios FTP do Squid. Para lidar com servidores NetWare antigos que preenchiam listagens com espaços extras, o código ignora os espaços em branco com um loop: while (strchr(w_space, *copyFrom)) ++copyFrom;.
Se o servidor FTP do invasor enviar uma linha de listagem que termina logo após o carimbo de data/hora, sem nome de arquivo, copyFrom chegará ao terminador nulo da string. strchr trata esse término NUL como parte da string que pesquisa, portanto retorna um ponteiro em vez de NULL e o loop nunca para. Ele sai do final do buffer e o xstrdup copia o que segue de volta para o invasor como um nome de arquivo.
Os bytes vazados são a parte útil. O Squid reutiliza buffers de memória liberados sem zerá-los, portanto, um buffer de 4 KB que continha recentemente uma solicitação HTTP da vítima ainda contém a maior parte dele. Uma linha FTP curta substitui apenas os primeiros bytes; a leitura excessiva retorna o resto.
A demonstração do Calif extrai um cabeçalho de autorização de uma vítima que compartilha o mesmo proxy, o suficiente para agir como esse usuário. O código de prova de conceito é público e nenhuma exploração em estado selvagem foi relatada até o momento.
O que fazer
Se você corrigir, verifique a correção, não apenas a versão. Confirme se o guarda está em FtpGateway.cc, ou verifique o backport da sua distribuição, já que as distros enviam suas próprias compilações (pacotes Debian Squid 5.7).
O tópico público ainda é inconsistente: o mantenedor Amos Jeffries primeiro disse que o Squid 7.6 trazia a correção, depois corrigiu para 7.7 e, em 22 de junho, Salvatore Bonaccorso do Debian notou que o commit referenciado parece já estar na versão 7.6.
A correção é pequena, uma verificação de terminador nulo antes das chamadas strchr vulneráveis, mesclada ao branch de desenvolvimento em abril e à versão 7 em maio. O Squid 7.6 corrige separadamente o CVE-2026-50012, um estouro de heap cache_digest não relacionado.
A atitude mais limpa é aquela que os pesquisadores recomendam: desligar o FTP. O Chromium abandonou o FTP anos atrás, e a maioria das redes não carrega quase nada dele, portanto, desativá-lo remove essa superfície de ataque gratuitamente, qualquer que seja a versão que você execute.
O risco é real, mas limitado. A SUSE classifica-o como moderado, CVSS 6.5, e o vetor explica a pontuação: o invasor precisa de acesso proxy (privilégios baixos) e o único impacto é a confidencialidade, nada na integridade ou disponibilidade.
Calif credita ao Claude Mythos Preview da Anthropic, o modelo por trás do Projeto Glasswing, por capturar a peculiaridade do strchr quase imediatamente, o mesmo tipo de bug de analisador enterrado que os agentes de IA vêm surgindo em outros lugares, inclusive no FFmpeg. Calif sugere que o código FTP do Squid pode não ser o último lugar onde ele se esqueceu de parar de ler.
Fonte: https://thehackernews.com
#samirnews #samir #news #boletimtec #bug #do #squid #proxy #de #29 #anos #‘squidbleed’ #pode #vazar #solicitações #http #de #texto #não #criptografado
💡 Compartilhe e ajude nosso projeto a crescer!
Postar um comentário