O incidente de segurança 12604 do curl da Apple

 (daniel.haxx.se)
1 pontos por GN⁺ 2024-03-10 | 1 comentários | Compartilhar no WhatsApp
  • O curl incluído pela Apple no macOS trata a opção --cacert de forma diferente da build open source, quebrando a expectativa de verificação TLS de confiar apenas na CA especificada pelo usuário
  • --cacert é uma opção que faz a verificação do certificado do servidor ser feita somente com o conjunto de certificados de CA especificado, e o curl deve retornar erro se a verificação falhar
  • O curl fornecido pela Apple parece verificar também o repositório de CAs do sistema mesmo quando a verificação com a CA especificada falha; esse comportamento não foi solicitado nem documentado
  • A Apple Product Security respondeu que o LibreSSL, o OpenSSL da Apple, usa intencionalmente o repositório de confiança embutido do sistema como fonte de confiança padrão e que isso não seria algo a corrigir
  • Como não é uma vulnerabilidade da distribuição do projeto curl, CVE não foi emitido, mas o resultado da verificação de CA no curl incluído no macOS pode diferir do que a documentação descreve

O início da issue 12604

  • Em 28 de dezembro de 2023, o bugreport 12604 foi registrado no rastreador de issues do curl
  • O título da issue era “flag --cacert behavior isn’t consistent between macOS and Linux”, e foi reportada por Yuedong Wu
  • Mesmo executando a mesma versão do curl na mesma máquina macOS, o comportamento diferia entre o curl incluído pela Apple e um binário de curl compilado a partir do open source

A garantia esperada de --cacert

  • A opção de linha de comando --cacert do curl é a forma de fazer com que o curl confie apenas no conjunto de certificados de CA exatamente especificado nas transferências seguintes
  • Se o servidor TLS não apresentar um certificado que possa ser validado por esse conjunto de certificados, o curl deve falhar e retornar erro
  • Essa opção foi adicionada ao curl em dezembro de 2000 e serve para garantir que o usuário esteja se comunicando com um servidor que conhece e em que confia
  • Em última análise, isso toca diretamente no papel básico que o TLS deve cumprir

O comportamento excepcional do curl incluído no macOS

  • O curl para macOS fornecido pela Apple aparentemente, ao usar --cacert, verifica também o repositório de CAs do sistema quando a validação com o conjunto de CAs especificado falha
  • Essa verificação auxiliar não é o comportamento solicitado pelo usuário e também não aparece na documentação, o que a torna difícil de prever
  • Mesmo que o usuário tente validar com um arquivo dedicado e reduzido de certificados de CA, a operação não falha se houver no repositório de CAs do sistema um certificado capaz de validar o servidor
  • Como resultado, uma verificação de certificado que não deveria passar pode acabar passando, o que é tratado como um problema de segurança

A resposta da Apple Product Security

  • Em 29 de dezembro de 2023 às 08:30 UTC, um e-mail reportando o problema de segurança foi enviado à Apple Product Security
  • A Apple Product Security respondeu em 8 de março de 2024
  • A resposta da Apple pode ser resumida em dois pontos
    • O LibreSSL, o OpenSSL da Apple, usa intencionalmente o repositório de confiança embutido do sistema como fonte de confiança padrão
    • Como o certificado do servidor pode ser validado com sucesso pelo repositório de confiança embutido do sistema, a Apple não considera isso um problema a ser tratado na plataforma
  • A Apple encerrou esse caso

Avaliação do projeto curl e impacto para usuários

  • Esse recurso não documentado no macOS faz com que a validação de certificados de CA no curl fique inconsistente com a documentação
  • Os usuários esperam que apenas o conjunto de certificados de CA especificado com --cacert seja usado, mas o curl fornecido pela Apple se comporta de forma diferente dessa expectativa
  • Esse problema não é uma vulnerabilidade de segurança nas versões do curl distribuídas pelo projeto curl
    • O projeto curl não emitiu um CVE para esse problema
    • O problema não se origina no código do curl em si, mas na versão do LibreSSL fornecida pela Apple na plataforma e usada na build do curl
  • Ao usar o curl fornecido pela Apple no macOS, o resultado da validação baseada em --cacert pode ser diferente do curl compilado a partir do open source

Leituras relacionadas

1 comentários

 
GN⁺ 2024-03-10
Comentários do Hacker News

  • Esse comportamento é totalmente idiota. Se eu especifico uma CA manualmente, é por um de dois motivos: ou minha CA não está no bundle do sistema operacional, ou eu quero validar apenas contra uma CA específica
    Ou seja, esse “recurso” da Apple ou adiciona processamento inútil, ou quebra o modelo de validação esperado. Nenhum dos dois é um resultado aceitável

    • Pequena correção: ele faz fallback para o repositório de CAs da Apple quando a primeira verificação falha. Então provavelmente não adiciona processamento inútil
      Ainda assim, concordo que é um comportamento ruim porque não é o resultado esperado. Considerando que a Apple costuma preferir mudanças que quebram compatibilidade retroativa, e que esse recurso foi adicionado ao curl, parece que há alguma circunstância não revelada pela Apple. Talvez seja usado em ferramentas internas de diagnóstico de desenvolvedor ou na validação da App Store
    • Existe o ditado de não atribuir à malícia o que pode ser explicado por estupidez, mas é preciso ter cuidado extra quando um agente malicioso usa a navalha de Hanlon como defesa

  • Infelizmente, esse tipo de comportamento em que a política da Apple sempre tem prioridade, não importa o que o “dono” do dispositivo Apple tente fazer, não é surpreendente e é algo que sempre se deve esperar da Apple

    • É por isso que eu não uso Apple. Os dispositivos parecem muito bem construídos e o sistema operacional é polido, mas esse aprisionamento ao jeito deles e ao ecossistema deles, além de bloquear o acesso ao próprio hardware, não combina com viver como hacker no sentido do HN
      Pelo menos não nessa parte da vida digital, e pelo preço fica difícil até comprar como aparelho secundário. Eu continuo pensando se deveria testar produtos da Apple, e recentemente pensei isso sobre o headset de AR, mas até agora tudo parece hostil demais para desenvolvedores ou pessoas que gostam de mexer
    • Se você executar o curl open source, consegue o comportamento desejado
    • Infelizmente, sempre existem pessoas que leem demais uma decisão técnica de baixo nível para “provar” seus próprios preconceitos
      Achar que uma empresa do tamanho da Apple tomou uma decisão dessas por causa de uma visão maior de “possuir os dispositivos dos usuários” é atribuir à Apple um nível gigantesco de organização e coordenação. Nunca vi isso nem em organizações com um décimo do tamanho da Apple. Mas é a Apple, então deve ser isso mesmo, né!?
    • O proprietário é a Apple, você é só o usuário ;)

  • Talvez seja a Apple que esteja configurando isso?[0] o destaque é meu
    CURLSSLOPT_NATIVE_CA
    Instrui o libcurl a usar o armazenamento padrão de CAs do sistema operacional para validação de certificados. Se essa opção for definida junto com um arquivo de certificado CA ou diretório, esses certificados também serão pesquisados durante a validação junto com o armazenamento padrão de CAs
    Quando --cacert é combinado com essa opção, parece que o libcurl tenta respeitar ambos. Eles não deveriam ser mutuamente exclusivos?

    • Não, não nesse caso. O binário curl sabe como deve chamar a biblioteca libcurl

  • Isso é um backdoor
    Não estou dizendo que foi intencional ou malicioso. Mas na prática é um backdoor. Se você começou a adicionar chaves ao sistema de autenticação do usuário, então adicionou um backdoor

    • Isso se parece exatamente com o tipo de coisa que a NSA pressionaria grandes empresas de tecnologia dos EUA a fazer

  • O comportamento padrão é suspeito, mas não concordo totalmente com essa avaliação. Na verdade isso é um problema de documentação do curl
    O curl é uma biblioteca multiprotocolo, então ele não implementa diretamente todos os protocolos e, na maioria dos casos, depende de “backends” como dependências transitivas, delegando a eles a interpretação dos bits de nível mais baixo. Alguns protocolos incluem suporte a várias bibliotecas alternativas por motivos legítimos
    A desvantagem dessa abordagem é que garantir comportamento comum entre backends independentes é difícil ou impossível. Eles podem não oferecer todos os mesmos recursos, a API pode ser incompleta ou, como neste caso, pode não fornecer um meio de ajustar parte do comportamento padrão. O LibreSSL não é uma reimplementação bit a bit do OpenSSL, e não tem obrigação de reproduzir completamente sua API
    Nesses casos, se o upstream não quiser corrigir, o curl fica com duas opções: encerrar o suporte a essa biblioteca ou documentar esse comportamento peculiar. A primeira pode quebrar código dos usuários, então no mínimo a segunda deveria ser feita
    Dito isso, concordo com a linha geral de que isso é uma falha do ponto de vista de segurança do LibreSSL, e provavelmente há motivo para abrir um CVE. Só que o alvo deveria ser o LibreSSL

    • Se a causa raiz está na biblioteca SSL do sistema, não entendo bem como compilar o curl a partir do código-fonte evita esse problema

  • Isso me lembra o caso do F_BARRIERFSYNC do SQLite
    Eles simplesmente não ligam
    https://bonsaidb.io/blog/acid-on-apple/

    • Isso me lembra de quando a Apple realmente quebrou uma das antigas ferramentas Unix que ela distribuía junto, enfiando alguma opção de forma descuidada
      A postura de manutenção deles está uns dois níveis abaixo da do pessoal do Debian quando estragou o OpenSSL

  • Se o Daniel diz que o curl de vocês está quebrado, então consertem, Apple. É simples assim

    • O Daniel também pode estar errado. Pode até estar errado sobre o curl
      Pelo que verifiquei aqui em dois minutos, ele provavelmente está certo neste caso, mas “está certo porque é o Daniel” é uma péssima linha de raciocínio
      Isso me lembra velhas discussões sobre a história do C, especialmente em torno das “contribuições” de Eric S. Raymond: https://scienceblogs.com/deltoid/2011/10/14/dennis-ritchie-h...

  • Valeu pelo aviso. Para referência, eu substituo boa parte das ferramentas que vêm com o macOS usando o MacPorts. O curl é uma delas
    As ferramentas empacotadas normalmente estão desatualizadas ou quebradas de alguma outra forma. Perdi a confiança no software que a Apple empacota faz muito tempo

  • Fico me perguntando se a Apple não depende desse comportamento para alguma coisa importante

    • Não sei se isso foi sarcasmo, mas isso claramente é muito importante
      É totalmente razoável alguém criar um script para usar apenas uma CA privada interna. Ao executar esse comando, você sabe que está se comunicando apenas com recursos internos da empresa porque é uma CA interna da empresa
      Mas a Apple adiciona aqui um backdoor tão grave quanto a validação de domínio
      Indo além, também é perfeitamente razoável usar um nome fictício e confirmar que você está se conectando a um servidor da empresa apenas porque ele foi assinado pela CA da empresa. Mas a Apple quebra essa suposição totalmente razoável e cria uma vulnerabilidade de segurança. Isso não é bom
    • Pode ser para facilitar a interceptação TLS por empresas e governos
    • Ou é algo extremamente burro, ou é algo perverso

  • Então era até esse ponto que ia a conversa de que a Apple se importa com a segurança do usuário