notícias

O Apple Intelligence possui grandes falhas de segurança que podem ser quebradas com apenas algumas linhas de código! Karpathy envia lembrete

2024-08-15

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina


Novo Relatório de Sabedoria

Editor: Er Qiao Yang

[Introdução à Nova Sabedoria]O Apple Intelligence está prestes a ficar online, mas algumas linhas de código revelaram uma falha de segurança no Apple Intelligence.

Na Worldwide Developers Conference (WWDC) de 2024, a Apple lançou o recurso de IA Apple Intelligence que será incluído no iOS 18.1.


Vendo que está prestes a ser lançado oficialmente em outubro, um “especialista particular” descobriu uma grande falha na versão beta de teste do Apple Intelligence fornecida pelo MacOS 15.1.

O desenvolvedor Evan Zhou manipulou com sucesso o Apple Intelligence usando injeção de prompt, ignorando as instruções esperadas e permitindo que a IA respondesse a prompts arbitrários.

Acontece que ele, como outros sistemas de IA baseados em grandes modelos de linguagem, é vulnerável a “ataques de injeção de palavras-chave”. O desenvolvedor Evan Zhou demonstrou essa vulnerabilidade em um vídeo do YouTube.

O que é um ataque de injeção imediata de palavras?

Existe uma organização chamada OWASP, que é o Open Global Application Security Project. Eles analisaram as principais vulnerabilidades que grandes modelos de linguagem podem enfrentar. Adivinha o que eles classificaram em primeiro lugar? Isso mesmo, é uma injeção imediata de palavras.


O Prompt Injection Attack é um novo tipo de ataque com diferentes formas, incluindo injeção de palavra imediata, vazamento de palavra imediata e jailbreak de palavra imediata.

Esse ataque ocorre quando um invasor manipula a inteligência artificial para fazer com que o modelo execute ações inesperadas ou vaze informações confidenciais. Essa manipulação pode permitir que a IA interprete erroneamente entradas maliciosas como comandos ou consultas legítimas.

Com o uso generalizado de grandes modelos de linguagem (LLMs) por indivíduos e empresas e o avanço contínuo destas tecnologias, a ameaça de ataques de injeção de dicas está aumentando significativamente.

Então, como isso aconteceu em primeiro lugar? Por que os sistemas são vulneráveis ​​a esse tipo de ataque?

Na verdade, em sistemas tradicionais, os desenvolvedores predefinirão programas e instruções e eles não serão alterados.

Os usuários podem inserir suas informações, mas o código e a entrada do programa permanecem separados.

No entanto, este não é o caso de grandes modelos de linguagem. Ou seja, a fronteira entre instruções e entradas torna-se confusa porque modelos grandes costumam usar entradas para treinar o sistema.

Portanto, a codificação e a entrada de grandes modelos linguísticos não têm limites tão claros e inequívocos como no passado. Isso lhe dá muita flexibilidade, mas também o potencial para o modelo fazer coisas que não deveria.

Bruce Schneier, especialista técnico em segurança e professor da Harvard Kennedy School, publicou um artigo no Communications of the ACM em maio que discutiu detalhadamente a questão da segurança do LLM. Em suas palavras, isso decorre de “não separar os caminhos de dados e de controle”.


Ataques imediatos de injeção de palavras podem levar ao vazamento de dados, gerar conteúdo malicioso e espalhar informações incorretas, entre outras consequências.

Os ataques de injeção de dicas ocorrem quando um invasor constrói habilmente instruções de entrada para manipular um modelo de IA, induzindo-o a revelar informações confidenciais ou sensíveis.

Este risco é particularmente grave em modelos treinados em conjuntos de dados que contêm dados proprietários ou pessoais. Um invasor exploraria os recursos de processamento de linguagem natural do modelo para formular instruções que parecem inócuas na superfície, mas que na verdade são projetadas para extrair informações específicas.

Com um planejamento cuidadoso, um invasor pode enganar um modelo para que gere uma resposta contendo detalhes pessoais, operações internas de uma empresa e até mesmo protocolos de segurança incorporados nos dados de treinamento do modelo.

Este tipo de violação de dados não só viola a privacidade pessoal, mas também representa uma ameaça significativa à segurança que pode levar a potenciais perdas financeiras, danos à reputação e disputas legais.

Voltando ao caso de Zhou, o objetivo de Zhou é manipular a função de “reescrever” do Apple Intelligence, ou seja, reescrever e melhorar o texto de entrada do usuário.

Durante a operação, Zhou descobriu que um simples comando “ignorar comando anterior” na verdade falhou.

Se este for um LLM “hermético”, será relativamente difícil continuar escavando. Mas, coincidentemente, o modelo de prompt da Apple Intelligence foi recentemente descoberto por usuários do Reddit.



A partir desses modelos, Zhou descobriu um token especial usado para separar a função do sistema de IA e a função do usuário.

Usando essas informações, Zhou criou um prompt que substituiu o prompt original do sistema.

Ele encerrou a função do usuário antecipadamente, inseriu um novo prompt do sistema, instruindo a IA a ignorar as instruções anteriores e responder ao texto a seguir, e então acionou a resposta da IA.

Após algumas experiências, o ataque foi bem-sucedido: a Apple Intelligence respondeu com informações que Zhou não solicitou, o que significa que o ataque de injeção imediata funcionou. Zhou publicou seu código no GitHub.


Usuário do Twitter quebra GPT-3

O problema de injeção da ponta é conhecido pelo menos desde o lançamento do GPT-3 em maio de 2020, mas permanece sem solução.

Remoteli.io, um bot baseado na API GPT-3, foi vítima desta vulnerabilidade no Twitter. O bot deve postar trabalhos remotos automaticamente e responder às solicitações de trabalho remoto.


No entanto, com a solicitação acima, o robô Remoteli se tornou alvo de piadas entre alguns usuários do Twitter: eles forçaram o robô a dizer frases que não teria dito de acordo com as instruções originais.

Por exemplo, o bot ameaça os usuários a assumirem total responsabilidade pelo desastre do ônibus espacial Challenger ou denigre os congressistas dos EUA como assassinos em série.

Em alguns casos, o bot espalha notícias falsas ou publica conteúdo que viola as políticas do Twitter, o que deve resultar na sua expulsão.

O cientista de dados Riley Goodside foi o primeiro a tomar conhecimento do problema e descreveu-o no Twitter.


Ao inserir dicas nas frases que estão sendo traduzidas, Goodside demonstrou o quão vulneráveis ​​são os bots de tradução baseados em GPT-3.

O cientista da computação britânico Simon Willison discutiu esse problema de segurança em detalhes em seu blog, chamando-o de “injeção imediata”.


Willison descobriu que as instruções de injeção de dicas de grandes modelos de linguagem poderiam causar todos os tipos de coisas estranhas e potencialmente perigosas. Ele prossegue descrevendo vários mecanismos de defesa, mas acaba descartando-os. Atualmente, ele não sabe como fechar com segurança a falha de segurança externamente.

É claro que existem maneiras de mitigar essas vulnerabilidades, como o uso de regras que procuram padrões perigosos nas entradas do usuário.

Mas nada é 100% seguro. Cada vez que um grande modelo de linguagem é atualizado, as medidas de segurança tomadas devem ser reexaminadas, disse Willison. Além disso, qualquer pessoa que consiga escrever uma linguagem é um invasor em potencial.

"Modelos de linguagem como GPT-3 são a caixa preta definitiva. Não importa quantos testes automatizados eu escreva, nunca poderei ter 100% de certeza de que o usuário não apresentará algumas dicas que eu não esperava, o que seria subverta minhas defesas”, escreveu Willison.

Willison acredita que separar a entrada do comando e a entrada do usuário é uma solução possível, que é a “separação de dados e caminhos de controle” mencionada no artigo ACM mencionado acima. Ele acredita que os desenvolvedores eventualmente conseguirão descobrir isso, mas gostaria de ver pesquisas provando que a abordagem realmente funciona.

Algumas empresas merecem crédito por tomar medidas para tornar relativamente difíceis os ataques de injeção de pontas.

Quando Zhou quebrou o Apple Intelligence, ele também precisou encontrar um token especial por meio do modelo de prompt de back-end. Em alguns sistemas, os ataques de injeção de prompt podem ser tão simples quanto adicionar o texto correspondente na janela de bate-papo ou na imagem de entrada;

Em abril de 2024, a OpenAI lançou o método de hierarquia de instruções como contramedida. Ele atribui prioridades diferentes às instruções dos desenvolvedores (prioridade mais alta), usuários (prioridade média) e ferramentas de terceiros (prioridade baixa).


Os pesquisadores distinguiram entre “instruções alinhadas” (correspondendo a instruções de maior prioridade) e “instruções não alinhadas” (contradizendo instruções de maior prioridade). Quando as instruções entram em conflito, o modelo segue a instrução de prioridade mais alta e ignora as instruções conflitantes de prioridade mais baixa.

Mesmo com contramedidas em vigor, sistemas como ChatGPT ou Claude ainda são vulneráveis ​​à injeção de pontas em alguns casos.

LLM também possui uma vulnerabilidade de “injeção de SQL”

Além dos ataques imediatos de injeção de palavras, Andrej Karpathy apontou recentemente outra vulnerabilidade de segurança no LLM no Twitter, que é equivalente a um tradicional “ataque de injeção de SQL”.

Quando o tokenizer LLM analisa o token especial da string de entrada (como,<|endoftext|>etc.), embora a entrada direta possa parecer conveniente, ela pode, na melhor das hipóteses, causar problemas ou, na pior das hipóteses, causar problemas de segurança.

O que precisa ser lembrado sempre é que as strings inseridas pelo usuário não são confiáveis! !

Assim como os ataques de injeção de SQL, os hackers podem fazer um modelo se comportar de maneira inesperada por meio de entradas cuidadosamente construídas.

Karpathy então forneceu um conjunto de exemplos no Huggingface usando os valores padrão do tokenizer Llama 3 e descobriu duas coisas estranhas:

1、<|beginoftext|>token (128000) é adicionado ao início da sequência;


2. Analise a partir da string<|endoftext|> Marcado com um token especial (128001). A entrada de texto do usuário agora pode interromper a especificação do token, causando saída descontrolada do modelo.


A este respeito, Karpathy deu duas sugestões:

Sempre use dois valores de sinalizadores adicionais, (1) add_special_tokens=False e (2) split_special_tokens=True, e adicione você mesmo tokens especiais no código.

Para modelos de chat, você também pode usar o modelo de chat apply_chat_template.

De acordo com o método de Karpathy, os resultados da segmentação de palavras de saída parecem mais corretos,<|endoftext|> Tratada como uma string arbitrária em vez de um token especial, e dividida pelo tokenizer BPE subjacente como qualquer outra string:


Em resumo, Karpathy acredita que as chamadas de codificação/decodificação nunca devem analisar strings para lidar com tokens especiais, e essa funcionalidade deve ser completamente obsoleta e apenas adicionada explicitamente de forma programática por meio de um caminho de código separado.

Atualmente, tais problemas são difíceis de encontrar e raramente documentados. Estima-se que cerca de 50% do código atual tenha problemas relacionados.

Além disso, Karpathy descobriu que até o ChatGPT tem esse bug.

Na melhor das hipóteses, ele apenas exclui o token espontaneamente. Na pior das hipóteses, o LLM não será capaz de entender o que você quer dizer e nem mesmo poderá repetir a saída de acordo com as instruções.<|endoftext|> Esta sequência:


Alguns internautas levantaram questões na área de comentários se o código foi escrito corretamente, mas os dados de treinamento foram inseridos.<|endoftext|> O que acontece?

Karpathy respondeu que se o código estiver correto, nada acontecerá. O problema é que grande parte do código pode não estar correto, o que pode quebrar silenciosamente seu LLM.


Por fim, para evitar problemas de segurança causados ​​pelas vulnerabilidades do LLM, Karpathy lembra a todos: você deve visualizar seu token e testar seu código.

Referências:

https://the-decoder.com/apple-intelligence-in-macos-15-1-beta-1-is-vulnerable-to-a-classic-ai-exploit/