Relatório de segurança do curl gerado por IA

• O projeto curl mantém um bug bounty e, com o aumento de relatórios de segurança que parecem ter sido feitos com LLMs, o tempo dos desenvolvedores está sendo gasto validando denúncias falsas em vez de lidar com vulnerabilidades reais
• Até agora, o curl já pagou mais de US$ 70 mil e recebeu 415 relatórios, mas apenas 64 eram problemas reais de segurança e 77 foram classificados como informativos
• O ponto central do problema é que os relatórios parecem plausíveis, com inglês convincente, explicações detalhadas e até sugestões de correção, o que eleva bastante o custo de revisão
• Em 2023, foram recebidos um relato dizendo que as mudanças de código do CVE-2023-38545 haviam sido divulgadas e outro sobre um suposto overflow de buffer no WebSocket, mas em ambos os casos não havia nem divulgação real nem overflow de buffer
• A IA pode ser útil como apoio em tradução, redação e até em ferramentas de detecção de vulnerabilidades, mas enviar saídas de LLM sem validação humana transfere para o projeto o custo da resposta de segurança em código aberto

---

Relatórios de baixa qualidade enfrentados pelo bug bounty do curl

• O projeto curl mantém um bug bounty que paga recompensas reais a hackers que reportam problemas de segurança
• A possibilidade de recompensa atrai “luck seekers”, que fazem grep em padrões no código-fonte ou apenas executam scanners básicos de segurança e enviam o resultado sem análise suficiente
• No passado, os relatórios de baixa qualidade em geral podiam ser identificados e descartados rapidamente, então o desperdício de tempo não virava um grande problema para o projeto
• Resultados do bug bounty do curl até agora:
  • Mais de US$ 70 mil pagos em recompensas
  • 415 relatórios de vulnerabilidade recebidos
  • 64 casos confirmados como problemas reais de segurança
  • 77 casos classificados como informativos, como bugs comuns
  • 66% de todos os relatórios não eram nem problema de segurança nem bug comum

Por que relatórios falsos plausíveis são mais perigosos

• Quanto mais sofisticado for o relatório falso, mais tempo de investigação e energia serão necessários até descartá-lo
• Todo relatório de segurança precisa ser lido por uma pessoa e ter seu significado real avaliado
• Como o trabalho de segurança costuma receber alta prioridade, até relatórios falsos podem empurrar outras tarefas de desenvolvimento para depois
• Relatórios que não melhoram a segurança real tomam tempo que poderia ser usado em corrigir bugs incômodos ou desenvolver novos recursos
• Lidar repetidamente com relatórios de baixa qualidade também aumenta o desgaste dos desenvolvedores

Relatórios de segurança que parecem feitos por IA

• A IA é uma ferramenta de uso geral e pode ser usada para coisas boas, mas também de forma inadequada
• Pode haver potencial para usar IA de forma produtiva na detecção e no reporte de problemas de segurança, mas o projeto curl ainda não encontrou bons exemplos disso
• No momento, o que se vê é gente colocando o código do curl em um LLM e enviando sua saída como relatório de vulnerabilidade
• Como os usuários não apenas colam a saída da IA, mas também misturam frases próprias, a detecção fica mais difícil
• Mesmo que o texto inteiro do relatório não seja idêntico ao texto gerado por IA, o resultado ainda pode ser um relatório inválido

Por que é difícil descartar só por traços de IA

• Entre os reportantes, há casos de pessoas que não têm fluência em inglês e exigem várias rodadas de perguntas e respostas até que a intenção fique clara
• Barreiras de idioma e cultura existem de fato, e esse processo de comunicação pode ser aceito como algo natural
• Alguns reportantes usam IA ou outras ferramentas como apoio de tradução e redação para se comunicar melhor em língua estrangeira
• Mesmo sem falar bem inglês, um reportante pode encontrar e denunciar um problema real de segurança
• Por isso, é difícil descartar imediatamente um relatório só porque partes do texto parecem geradas por IA, e relatórios falsos bem escritos levam ainda mais tempo para serem avaliados

Caso A: alegação de divulgação de mudanças de código do CVE-2023-38545

• No outono de 2023, a comunidade do curl foi informada sobre a divulgação iminente do CVE-2023-38545, avaliado com severidade high
• Um dia antes da divulgação pública do problema, chegou ao HackerOne o relatório “Curl CVE-2023-38545 vulnerability code changes are disclosed on the internet”
• Só pelo título, era algo que poderia ser muito sério se fosse real
• Mas o relatório parecia uma típica alucinação de IA, misturando fatos e detalhes de problemas de segurança antigos para criar um novo conteúdo sem ligação com a realidade
• As mudanças do CVE-2023-38545 não haviam sido divulgadas na internet, e as mudanças que estavam públicas eram, como pretendido, referentes a um problema antigo anterior
• O reportante disse que havia encontrado o problema usando o Bard, o que facilitou identificar o erro e encerrar o relatório

Caso B: alegação de overflow de buffer em WebSocket

• Na manhã de 28 de dezembro de 2023, o HackerOne recebeu o relatório “Buffer Overflow Vulnerability in WebSocket Handling”
• Pelo título parecia grave, mas o código de WebSocket do curl ainda era um recurso experimental, portanto fora do escopo do bug bounty
• O reportante era um usuário até então desconhecido, mas tinha boa reputação no HackerOne e não era seu primeiro relatório de segurança
• O relatório estava bem organizado e incluía detalhes, frases adequadas em inglês e até uma correção sugerida
• Num primeiro momento, pareceu melhor do que um relatório inicial típico e dava a impressão de que o reportante entendia o problema e até propunha uma solução
• Após 19 minutos e várias revisões do código, não foi possível encontrar o overflow de buffer alegado
• Depois de perguntas repetidas e várias respostas com sinais de alucinação, concluiu-se que não se tratava de um problema real, e o caso foi fechado como not applicable naquela mesma tarde
• Não é certo que essas respostas tenham sido geradas por LLM, mas vários indícios permaneceram

Recurso de bloqueio no HackerOne e penalidade de reputação

• A princípio, concluiu-se que o HackerOne não tinha um recurso para bloquear explicitamente o reportante de futuras comunicações com o projeto
• Foi dito que, se esse recurso existisse, ele teria sido usado
• Quando um caso é fechado como not applicable, a reputação do pesquisador no HackerOne cai, mas se isso acontece apenas uma vez em um único projeto, o efeito punitivo é muito pequeno
• Em uma atualização posterior, foi acrescentado que o recurso de fato existia, mas não havia sido procurado no lugar certo

Mais relatórios gerados por LLM virão

• Espera-se que esse tipo de relatório se torne mais comum com o tempo
• O projeto pode aprender a detectar melhor sinais de conteúdo generated-by-AI e a descartar relatórios com base nisso
• Ainda assim, isso pode acabar prejudicando também casos em que a IA foi usada de forma apropriada, como apoio em tradução ou formulação de frases
• No futuro, podem surgir algumas ferramentas que usem IA para encontrar problemas de segurança e que realmente funcionem melhor
• A expectativa é que, com um nível mínimo que seja de validação humana, a usabilidade e os resultados dessas ferramentas melhorem bastante
• A busca por atalhos para conseguir recompensas rápidas provavelmente continuará e, com o fácil acesso a LLMs poderosos, a caixa de entrada do HackerOne deve receber mais relatórios de baixa qualidade

[GN⁺]

Comentários do Hacker News

• Frases como “Claro! Vou explicar com mais detalhes as preocupações levantadas pelo responsável pela triagem” são um jeito de falar típico de LLM e soam como um mordomo robô
  Quase nunca vi uma pessoa escrever assim, e também é estranho mencionar o “responsável pela triagem” em terceira pessoa, como se houvesse outro agente induzindo a resposta
  Não tem problema um LLM ter um jeito de falar identificável, mas o preocupante não é que LLMs falem como humanos, e sim que as pessoas comecem a falar como LLMs

  • Daniel Stenberg[1] levantou um ponto importante: como o curl é usado no mundo todo, não é nada estranho que alguém que não tenha o inglês como língua nativa use a ajuda de um LLM para escrever um bug report
    Então, só por indícios superficiais de que o texto em inglês parece gerado por LLM, não dá para concluir que o conteúdo do relatório em si também foi criado por um LLM

    [1] https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-f...

  • Eu queria que alguém estivesse escrevendo uma ficção científica distópica em que os dominadores robôs ficam pedindo desculpas o tempo todo enquanto dizem coisas como “Em última análise, a rendição ou não depende das suas necessidades e preferências específicas”

  • Ao ver “soa como um mordomo robô”, de repente entendi a expressão Butlerian Jihad

  • Na Índia, às vezes o inglês é ensinado no estilo britânico colonial da classe servil, o chamado “estilo de mordomo”
    Se você nunca tinha visto esse jeito de falar até agora, provavelmente nunca lidou com o suporte técnico corporativo da Microsoft

  • É com certeza um grande sinal de alerta, mas se aquilo foi mesmo transmitido por uma pessoa real, bastaria apagar aquela linha
    O conteúdo ainda pareceria suspeito, mas haveria bem menos pistas para perceber

• Gente atrás de “recompensa mendigada” já vinha tornando programas de bug bounty bastante difíceis de operar
  Naquela época, pelo menos uma pessoa de verdade precisava gastar tempo para montar um “bug report” que na prática não era nada, mas com LLMs é possível gerar relatórios falsos quase sem custo, então isso pode realmente sair do controle
  Pessoalmente, acho que isso pode significar o fim dos programas de bug bounty
  Ou talvez eles precisem ficar mais fechados: receber candidaturas para participar do programa, verificar de forma barata se a pessoa é real, se é de fato um pesquisador de segurança e se pretende encontrar bugs de segurança relevantes, e então permitir que só os aprovados enviem bugs e recebam recompensa em dinheiro

  • Já existem plataformas que oferecem esse tipo de recurso
    Elas mantêm um pool de pesquisadores conhecidos, acompanham seu status e permitem ajustar o quão publicamente o programa será operado
    Algumas também têm triagem, mas o sucesso varia bastante dependendo de quão típico é o projeto
  • Outra possibilidade seria cobrar uma taxa de envio
    Não sei se ajudaria, mas pode funcionar como um desincentivo contra envios em massa de lixo gerado por máquina
    O pior cenário é uma enxurrada de lixo de IA e, para “resolver” isso, adotarem uma filtragem por IA igualmente ruim, reduzindo a qualidade geral para todo mundo que quer participar de boa-fé

• No começo achei que este post fosse duplicado de https://news.ycombinator.com/item?id=37904047, mas na verdade era mais um relatório falso de vulnerabilidade gerado por LLM enviado contra o curl no HackerOne

  • Ainda bem que eu não estava maluco
    Enquanto lia, tinha certeza de que já tinha visto aquilo antes, e é estranho o quanto isso se parece com o caso anterior
    Em projetos populares como o curl, será que as pessoas vão continuar abrindo denúncias de incidentes escritas por LLM só para colocar uma linha no currículo
  • Os clientes do HackerOne são empresas que operam programas de bug bounty
    Parece que eles precisam ser bem mais cuidadosos com quem pode enviar spam de lixo gerado por LLM para seus clientes só em busca de visibilidade
  • Eu não fazia a menor ideia de que isso já tinha acontecido antes
    Nesse caso, o ocorrido de agora vira um precedente ainda mais claro

• O que mais preocupa é que alguns centavos de custo de LLM desperdiçaram muito tempo caro e importante de engenharia
  Quando você imagina quanto esforço vai ser necessário para desmontar todo tipo de informação falsa que está sendo gerada agora, isso lembra a lei de Brandolini

  • Sim, os LLMs têm potencial para estragar uma parte enorme da internet, e não sei se isso é um problema solucionável
    Os modelos atuais ainda deixam pistas perceptíveis, mas os futuros serão diferentes e melhores
    Detecção e bloqueio podem virar uma corrida armamentista, num ponto em que muita gente produtiva e muitas plataformas não consigam acompanhar

• É interessante que tenhamos tornado a escrita, o meio de menor largura de banda para demonstrar ação e esforço, em algo muito mais trabalhoso de usar para julgar se realmente houve ação ou esforço
  Os efeitos em cascata provavelmente serão enormes
  Aqui, tanto o denunciante quanto os administradores desperdiçaram tempo que poderia ter sido usado em coisas mais úteis, e todo o ecossistema de bug bounty e do processo de CVE baseado em crowdsourcing é prejudicado pela piora da relação sinal-ruído
  Como resultado, aumenta a chance de que a barreira para envio suba para combater spam, o que pode levar à descoberta e correção de menos bugs, ao aumento de vulnerabilidades de segurança e a todos os problemas decorrentes disso
  A mesma dinâmica vale em outras áreas, tornando cada vez mais difícil confiar em avaliações de produtos, documentos enviados a tribunais, receitas, guias de instrução, aconselhamento médico e assim por diante
  Uma das promessas da internet era a rápida expansão de conteúdo pela democratização da publicação, mas parece que estamos vendo até mesmo as vantagens restantes serem esvaziadas por dentro

• Chamar atenção aqui para checagem de limites de comprimento é especialmente estranho
  Isso porque não há uso algum de dados fornecidos pelo usuário, e todos os tamanhos são estáticos em tempo de compilação
  O curl está colocando em um buffer estático de 40 bytes um valor composto por uma string aleatória de 16 bytes codificada em base64, isto é, 25 bytes ASCII, mais o terminador nulo \0

  https://github.com/curl/curl/blob/1d8e8c9ad1ff3351386422535f...

E, perguntando por pura curiosidade: alguém que conhece C melhor do que eu consegue explicar por que aqui se usa a variável local keyval?
Por que não simplesmente definir heads[3].val = randstr e depois dar free() quando o processamento dos headers terminar?
E por que keyval tem 40 bytes, e não 26 ou 32?

• Provavelmente a intenção é reduzir os pontos em que seria preciso chamar free e diminuir a chance de esquecer isso
  Embora dê para imaginar que isso já possa acontecer na linha 580, na prática talvez esse caso nunca ocorra

• Se for isso, então daria para eliminar tanto randstr quanto keyval e, já que de qualquer forma há alocação, codificar direto em &heads[3].val
  Ainda assim seria preciso passar o randlen inútil, senão dá erro
  A beleza típica dos parâmetros de saída em C
  Essa dança de “copiar do heap para uma variável da stack” também não reduz o trabalho de limpeza
  Porque depois da codificação sempre existe apenas um caminho de retorno
  Mas, se alguém primeiro “deixou preparadas” as variáveis necessárias lá em cima e só depois percebeu que Curl_base64_encode sempre faz alocação, dá para entender como o código atual surgiu

• Usar a stack é quase de graça, porque o espaço já é reservado na preparação da função e é limpo automaticamente quando ela retorna
  Usar o heap exige mais trabalho, pode falhar e requer limpeza manual

• Uma das lições importantes que aprendi no ensino médio foi saber distinguir entre uma mentira expressa com elegância e uma verdade expressa de forma tosca
  Mas isso pode ser difícil
  As pessoas tendem a usar gramática e estilo corretos como um primeiro filtro para discurso inteligente, e os LLMs são muito, muito bons em dar à linguagem uma forma plausível

  • Fico curioso sobre o quanto essa lição realmente marcou a mim e aos meus colegas na época
    Esse é um problema muito traiçoeiro, e acho que a maioria dos adultos também não está preparada para lidar com ele
    A pessoa média tem capacidade suficiente para distinguir os dois, mas o problema é que isso exige hábito de ler textos de forma sistemática e algum esforço
    Quando você está rolando o feed no celular tarde da noite, é muito difícil fazer isso

• Se não fosse tão irritante e uma perda de tempo, teria sido engraçado ver dineshsec / dinesh_b tentando ensinar o Daniel a usar strncpy
  Primeiro marcaram o Daniel com um handle aleatório e depois inventaram um código inexistente com “o código problemático é o seguinte:”

  • Esse é um problema clássico de mau uso de LLM
    O usuário quer analisar alguma coisa, mas ela é longa demais, então ele cola em várias partes em pedidos separados
    Quando chega perto do ponto principal, o trecho de código original já saiu do contexto, e o modelo começa a soltar com confiança coisas plausíveis que na verdade nunca existiram

• Em vez de strcpy ou strncpy, o certo é simplesmente usar memcpy
  Em especial, strncpy é com certeza a pior escolha das três
  O código já conhece o tamanho do buffer de origem e também já verificou se cabe no buffer de destino, então não há motivo para chamar strcpy e medir o comprimento da string de novo sem necessidade
  Sinceramente, a recomendação do LLM é algo que eu desencorajaria ativamente
  Se você não souber o tamanho, não se importar com truncamento silencioso e também não se importar com desempenho, pode usar snprintf
strncpy preenche o resto do buffer desnecessariamente com zeros
  A menos que você esteja lidando com algo como UI, em geral precisa se importar com truncamento, e nesse caso strncpy não vai te salvar

• Isto parece relacionado: https://news.ycombinator.com/item?id=38840907