3 pontos por GN⁺ 2024-06-03 | 1 comentários | Compartilhar no WhatsApp
  • No início desta semana, foi detectado acesso não autorizado relacionado a secrets na plataforma Spaces, e há possibilidade de que alguns secrets tenham sido acessados externamente
  • Como resposta inicial, vários tokens HF incluídos nos secrets foram revogados, e os usuários afetados receberam orientação por e-mail
  • Recomenda-se que os usuários reemitam as keys e tokens relacionados e migrem para os fine-grained access tokens, que se tornaram o padrão
  • A Hugging Face está investigando o caso com especialistas externos em perícia de cibersegurança e também está revisando suas políticas e procedimentos de segurança
  • Na infraestrutura do Spaces, foram aplicados a remoção de org tokens, a adoção de KMS e o reforço na detecção e invalidação de tokens vazados, e o incidente também foi comunicado às autoridades competentes

Acesso não autorizado a Spaces secrets e medidas para usuários

  • A Hugging Face detectou acesso não autorizado relacionado a Spaces secrets na plataforma Spaces
  • Há possibilidade de que alguns Spaces secrets tenham sido acessados sem autorização
  • No processo inicial de recuperação, vários tokens HF incluídos nos secrets foram revogados
    • Usuários cujos tokens foram revogados já receberam orientação por e-mail
  • Recomenda-se que os usuários emitam uma nova key ou um novo token
  • Recomenda-se que os tokens HF sejam migrados para o novo padrão, os fine-grained access tokens

Reforço da segurança da infraestrutura do Spaces e resposta posterior

  • A Hugging Face está investigando o incidente com especialistas externos em perícia de cibersegurança e revisando suas políticas e procedimentos de segurança
  • Nos últimos dias, a segurança da infraestrutura do Spaces foi reforçada
    • Os org tokens foram completamente removidos, aumentando a rastreabilidade e a capacidade de auditoria
    • Foi introduzido um serviço de gerenciamento de chaves (KMS) para Spaces secrets
    • A capacidade do sistema de identificar tokens vazados e invalidá-los preventivamente foi reforçada e ampliada
    • A segurança geral foi aprimorada
  • Quando os fine-grained access tokens alcançarem equivalência funcional, há planos para descontinuar completamente os tokens “classic” de leitura/escrita em breve
  • A investigação sobre possíveis incidentes relacionados continua
  • A Hugging Face também comunicou este incidente às autoridades policiais e às autoridades de proteção de dados
  • Dúvidas podem ser enviadas para security@huggingface.co

1 comentários

 
GN⁺ 2024-06-03
Opiniões no Hacker News
  • Dois dias atrás, dei uma olhada nos slides de uma conferência de segurança, e Jossef Harush Kadouri mostrou que, ao usar modelos de lugares como a Hugging Face, o autor do modelo pode executar código arbitrário na minha máquina.
    Não sei se os slides foram publicados em outro lugar, mas o arquivo que recebi está aqui: https://dro.pm/c.pdf (45 MB), slide 188.
    Na hora, não percebi que isso também significa que a mesma coisa seria possível se a Hugging Face recebesse uma ordem judicial ou fosse hackeada. Especialmente se a invasão passasse despercebida por algum tempo¹.
    Estou fora do setor de IA e nunca rodei esses modelos diretamente, mas fiquei surpreso com a rapidez com que o setor padronizou os formatos. Eu achava que um arquivo de modelo seria uma grande matriz de números e um pouco de metadados, mas, olhando os slides 186 e 195, parece que o modelo é, na prática, um script Python capaz de fazer o que quiser, o que deve ter facilitado a padronização. Se você deixa cada um fazer o que quiser, o problema é contornado, mas há um custo para isso.
    ¹ Segundo https://www.verizon.com/business/resources/articles/s/how-to..., 20% demoram meses para perceber uma invasão. Claro que isso depende da situação e das ações do invasor.
    • Sobre a parte “eu achava que um arquivo de modelo seria uma grande matriz de números e um pouco de metadados”, o ONNX[1] em geral se aproxima bastante disso.
      Só que o problema que aparece logo em seguida são as camadas/operadores personalizados e sua lógica de inferência. É preciso implementar tudo apenas com as operações suportadas, o que na prática pode ser difícil ou impossível, ou então fornecer a implementação dos operadores em tempo de execução, e aí se volta à estaca zero.
      [1] https://onnx.ai/
    • Então não é por isso que existe o formato .safetensors, que não permite executar código no host?
    • Como outras pessoas apontaram, isso depende do formato. Entre os formatos que ainda não foram mencionados nesta thread como seguros, há o GGUF, usado pelo llama.cpp e projetos derivados.
      É um formato quase como “uma grande matriz de números e um pouco de metadados”, e algumas vulnerabilidades foram encontradas e corrigidas.
      [1] https://www.databricks.com/blog/ggml-gguf-file-format-vulner...
    • Pelo que sei, esse problema só ocorre quando o modelo é serializado/desserializado com pickle[0].
      [0]: https://huggingface.co/docs/hub/en/security-pickle
    • O link do dro.pm vai expirar em breve. É um link temporário, por isso é curto; talvez eu devesse ter usado um serviço mais permanente.
      Para quem for ler depois, encontrei o vídeo da apresentação: https://m.youtube.com/watch?v=8XysLIq-e3s
  • Começar com “eles suspeitam” é uma formulação que deixa brecha demais para escapar. Parece inadequado para uma frase nesse tipo de comunicação.
    • Na verdade, achei bem razoável. Normalmente, esses avisos de vazamento dizem algo como “não há evidências de que os segredos tenham sido acessados”, porque “não dá para saber” o que o hacker fez depois de entrar.
      A Hugging Face, ao menos, disse algo como “provavelmente houve possibilidade de acesso aos segredos, mas não conseguimos confirmar”, o que parece mais honesto.
  • Eles dizem que “melhoraram significativamente a segurança da infraestrutura do Spaces nos últimos dias”, com remoção completa de tokens de organização, melhoria de rastreabilidade e auditoria, introdução de KMS para segredos do Spaces, melhoria na identificação de tokens vazados e na invalidação proativa, além de melhorias gerais de segurança. Parece uma quantidade bem grande de trabalho para concluir em “alguns dias”.
    Esse tipo de mudança não deveria acionar processos mais demorados antes de entrar em produção, como auditoria de segurança ou teste de intrusão?
    • Espero que já fosse um trabalho em andamento havia algum tempo e que, como o dano já tinha ocorrido, eles tenham decidido colocá-lo em produção agora.
    • Isso faria sentido em uma organização maior, com um departamento de SRE que inclua uma equipe dedicada de segurança, mas minha impressão é que a Hugging Face ainda não é uma organização desse porte.
  • Minha chave da Anthropic vazou e alguém gerou uma cobrança de US$ 10 mil. Será que a Hugging Face vai me compensar por isso?
    • Minha chave da OpenAI também vazou, e descobri alguém a usando. Felizmente, o prejuízo foi bem menor, algo como alguns dólares em GPT-4, e meus apps nem usavam esse modelo na época.
      Tenho quase certeza de que vazou por meio dos segredos de um HF Space. Alguns dias atrás, recebi um aviso dizendo que alguns dos meus Spaces foram afetados.
    • Você tem certeza de que essa chave estava armazenada apenas nos segredos do Space? Variáveis são públicas, e o que é salvo em um arquivo .env também é público.
    • Eu achava que, em plataformas de provedores de nuvem, normalmente era possível configurar um limite máximo de gastos.
  • Algumas semanas atrás, percebi que algumas das minhas chaves da OpenAI tinham sido comprometidas, e essas chaves só estavam ativas como segredos em um Hugging Face Space.
    Alguns dias atrás, recebi um e-mail dizendo que aqueles Spaces tinham sido comprometidos, então parece que esse problema já vinha acontecendo havia pelo menos algumas semanas.
  • Não há menção a como eles vão lidar com custos indevidos. Se era possível acessar segredos, então não seria possível chamar APIs e acumular custos?
    Ou isso é puramente uma questão de roubo de dados/código?
    • As duas coisas são possíveis. No meu caso, a chave foi usada para chamadas à OpenAI, e tenho quase certeza de que vazou dos segredos do Spaces.
  • O que é um “Space”?
    • É uma forma abreviada de se referir ao Spaces da Hugging Face.
      https://huggingface.co/docs/hub/en/spaces-overview
      Parece ser a parte de frontend/portal, e imagino que seja escrita em Python. Talvez algo como Django.
    • É uma máquina virtual que executa o código do usuário.
  • Por que a HF armazena “segredos”?
    Não dava para armazenar só a chave pública, e fazer o usuário manter a chave secreta e assinar as requisições?
    • Você pode criar um app hospedado na HF e acessar APIs externas como OpenAI ou Anthropic. Nesse caso, a chave de API fica armazenada nos segredos da HF.
    • Normalmente, para algo funcionar de fato dentro de uma sessão de navegador, é preciso algum tipo de token. Este caso parece ser sobre tokens que precisaram ser revogados; eles são parecidos com senhas, mas não exatamente iguais.