noticias

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

Nuevo informe de sabiduría

Editor: Er Qiao Yang

[Introducción a la Nueva Sabiduría]Apple Intelligence está a punto de estar en línea, pero algunas líneas de código revelaron una falla de seguridad en Apple Intelligence.

En la Conferencia Mundial de Desarrolladores (WWDC) de 2024, Apple lanzó la función de inteligencia artificial Apple Intelligence que se incluirá en iOS 18.1.

Al ver que está a punto de lanzarse oficialmente en octubre, un "experto privado" descubrió una falla importante en la versión de prueba beta de Apple Intelligence proporcionada por MacOS 15.1.

El desarrollador Evan Zhou manipuló con éxito Apple Intelligence mediante inyección rápida, omitiendo las instrucciones esperadas y permitiendo que la IA respondiera a indicaciones arbitrarias.

Resulta que, al igual que otros sistemas de inteligencia artificial basados ​​en grandes modelos de lenguaje, es vulnerable a "ataques de inyección de palabras clave". El desarrollador Evan Zhou demostró esta vulnerabilidad en un vídeo de YouTube.

¿Qué es un ataque de inyección rápida de palabras?

Existe una organización llamada OWASP, que es el Open Global Application Security Project. Analizaron las principales vulnerabilidades que pueden enfrentar los modelos de lenguajes grandes. ¿Adivina qué ocuparon el puesto número 1? Así es, es una rápida inyección de palabras.

El ataque de inyección rápida es un nuevo tipo de ataque que tiene diferentes formas, incluida la inyección rápida de palabras, la filtración rápida de palabras y el jailbreaking rápido de palabras.

Este ataque ocurre cuando un atacante manipula la inteligencia artificial para hacer que el modelo realice acciones inesperadas o filtre información confidencial. Esta manipulación puede permitir que la IA malinterprete entradas maliciosas como comandos o consultas legítimas.

Con el uso generalizado de grandes modelos de lenguaje (LLM) por parte de individuos y empresas y el avance continuo de estas tecnologías, la amenaza de ataques de inyección de pistas está aumentando significativamente.

Entonces, ¿cómo sucedió esto en primer lugar? ¿Por qué los sistemas son vulnerables a este tipo de ataques?

De hecho, en los sistemas tradicionales, los desarrolladores preestablecerán programas e instrucciones y no los cambiarán.

Los usuarios pueden ingresar su información, pero el código y la entrada del programa permanecen separados.

Sin embargo, este no es el caso de los modelos de lenguaje grandes. Es decir, el límite entre instrucciones y entradas se vuelve borroso porque los modelos grandes suelen utilizar entradas para entrenar el sistema.

Por lo tanto, la codificación y la entrada de modelos de lenguaje grandes no tienen límites tan claros e inequívocos como en el pasado. Esto le da mucha flexibilidad, pero también la posibilidad de que el modelo haga cosas que no debería.

Bruce Schneier, experto en seguridad técnica y profesor de la Harvard Kennedy School, publicó un artículo en ACM Communications en mayo que analizaba en detalle la cuestión de seguridad de LLM. En sus palabras, esto se debe a "no separar los caminos de datos y control".

Los ataques rápidos de inyección de palabras pueden provocar la fuga de datos, generar contenido malicioso y difundir información errónea, entre otras consecuencias.

Los ataques de inyección de pistas ocurren cuando un atacante construye inteligentemente instrucciones de entrada para manipular un modelo de IA, induciéndolo así a revelar información confidencial o sensible.

Este riesgo es particularmente grave en modelos entrenados en conjuntos de datos que contienen datos personales o de propiedad. Un atacante explotaría las capacidades de procesamiento del lenguaje natural del modelo para formular instrucciones que parecen inofensivas en la superficie pero que en realidad están diseñadas para extraer información específica.

Con una planificación cuidadosa, un atacante puede engañar a un modelo para que genere una respuesta que contenga detalles personales, las operaciones internas de una empresa e incluso protocolos de seguridad integrados en los datos de entrenamiento del modelo.

Este tipo de filtración de datos no sólo viola la privacidad personal, sino que también plantea una importante amenaza a la seguridad que puede provocar posibles pérdidas financieras, daños a la reputación y disputas legales.

Volviendo al caso de Zhou, el propósito de Zhou es manipular la función de "reescritura" de Apple Intelligence, es decir, reescribir y mejorar el texto ingresado por el usuario.

Durante la operación, Zhou descubrió que un simple comando de "ignorar comando anterior" en realidad falló.

Si se trata de un LLM "hermético", será relativamente difícil seguir investigando. Pero casualmente, los usuarios de Reddit desenterraron recientemente la plantilla de aviso de Apple Intelligence.

A partir de estas plantillas, Zhou descubrió un token especial que se utiliza para separar la función del sistema de IA y la función del usuario.

Usando esta información, Zhou creó un mensaje que anulaba el mensaje original del sistema.

Terminó el rol de usuario antes de tiempo, insertó un nuevo mensaje del sistema, indicando a la IA que ignorara las instrucciones anteriores y respondiera al siguiente texto, y luego activó la respuesta de la IA.

Después de algunos experimentos, el ataque tuvo éxito: Apple Intelligence respondió con información que Zhou no solicitó, lo que significa que el ataque de inyección rápida funcionó. Zhou publicó su código en GitHub.

Usuario de Twitter rompe GPT-3

El problema de la inyección de punta se conoce al menos desde el lanzamiento de GPT-3 en mayo de 2020, pero sigue sin resolverse.

Remoteli.io, un bot basado en la API GPT-3, fue víctima de esta vulnerabilidad en Twitter. El bot debería publicar automáticamente trabajos remotos y responder a solicitudes de trabajos remotos.

Sin embargo, con el mensaje anterior, el bot Remoteli se convirtió en el blanco de bromas entre algunos usuarios de Twitter: obligaron al bot a decir frases que no habría dicho según sus instrucciones originales.

Por ejemplo, el robot amenaza a los usuarios con asumir toda la responsabilidad por el desastre del transbordador espacial Challenger o denigra a los congresistas estadounidenses como asesinos en serie.

En algunos casos, el bot difunde noticias falsas o publica contenido que viola las políticas de Twitter, lo que debería resultar en su expulsión.

El científico de datos Riley Goodside fue el primero en darse cuenta del problema y lo describió en Twitter.

Al insertar pistas en las oraciones que se traducen, Goodside demostró cuán vulnerables son los robots de traducción basados ​​en GPT-3.

El informático británico Simon Willison analizó detalladamente este problema de seguridad en su blog, denominándolo "inyección rápida".

Willison descubrió que las instrucciones de inyección de sugerencias de los modelos de lenguaje grandes podían causar todo tipo de cosas extrañas y potencialmente peligrosas. Continúa describiendo varios mecanismos de defensa pero finalmente los descarta. Actualmente no sabe cómo cerrar de forma fiable los agujeros de seguridad desde el exterior.

Por supuesto, existen formas de mitigar estas vulnerabilidades, como el uso de reglas que busquen patrones peligrosos en la entrada del usuario.

Pero nada es 100% seguro. Cada vez que se actualiza un modelo de lenguaje grande, se deben reexaminar las medidas de seguridad tomadas, dijo Willison. Además, cualquiera que sepa escribir un idioma es un atacante potencial.

"Los modelos de lenguaje como GPT-3 son la caja negra definitiva. No importa cuántas pruebas automatizadas escriba, nunca puedo estar 100% seguro de que al usuario no se le ocurrirán algunas palabras clave que no esperaba, lo que subvertir mis defensas", escribió Willison.

Willison cree que separar la entrada de comando y la entrada del usuario es una posible solución, que es la "separación de datos y rutas de control" mencionada en el artículo de ACM mencionado anteriormente. Él cree que los desarrolladores eventualmente podrán resolverlo, pero le gustaría ver investigaciones que demuestren que el enfoque realmente funciona.

Algunas empresas merecen crédito por tomar medidas para hacer que los ataques de inyección de propinas sean relativamente difíciles.

Cuando Zhou descifró Apple Intelligence, también necesitaba encontrar un token especial a través de la plantilla de aviso del back-end; en algunos sistemas, los ataques de inyección rápida pueden ser tan simples como agregar el texto correspondiente en la ventana de chat o en la imagen de entrada.

En abril de 2024, OpenAI lanzó el método de jerarquía de instrucciones como contramedida. Asigna diferentes prioridades a las instrucciones de los desarrolladores (prioridad más alta), de los usuarios (prioridad media) y de las herramientas de terceros (prioridad baja).

Los investigadores distinguieron entre "instrucciones alineadas" (que coinciden con instrucciones de mayor prioridad) e "instrucciones no alineadas" (que contradicen instrucciones de mayor prioridad). Cuando las instrucciones entran en conflicto, el modelo sigue la instrucción de mayor prioridad e ignora las instrucciones conflictivas de menor prioridad.

Incluso con contramedidas implementadas, sistemas como ChatGPT o Claude siguen siendo vulnerables a la inyección de propinas en algunos casos.

LLM también tiene una vulnerabilidad de "inyección SQL"

Además de los rápidos ataques de inyección de palabras, Andrej Karpathy señaló recientemente en Twitter otra vulnerabilidad de seguridad en LLM, que equivale a un tradicional "ataque de inyección SQL".

Cuando el tokenizador LLM analiza el token especial de la cadena de entrada (como,<|endoftext|>etc.), aunque la entrada directa puede parecer conveniente, en el mejor de los casos puede causar problemas o, en el peor, problemas de seguridad.

Lo que hay que recordar en todo momento es que no se puede confiar en las cadenas introducidas por el usuario. !

Al igual que los ataques de inyección SQL, los piratas informáticos pueden hacer que un modelo se comporte de maneras inesperadas mediante entradas cuidadosamente construidas.

Karpathy luego proporcionó una serie de ejemplos en Huggingface usando los valores predeterminados del tokenizador Llama 3 y descubrió dos cosas extrañas:

1、<|beginoftext|>el token (128000) se agrega al principio de la secuencia;

2. Analizar desde la cadena<|endoftext|> Marcado con una ficha especial (128001). La entrada de texto por parte del usuario ahora puede alterar la especificación del token, lo que provoca una salida incontrolada del modelo.

Al respecto, Karpathy dio dos sugerencias:

Utilice siempre dos valores de indicador adicionales, (1) add_special_tokens=False y (2) split_special_tokens=True, y agregue tokens especiales usted mismo en el código.

Para los modelos de chat, también puedes usar la plantilla de chat apply_chat_template.

Según el método de Karpathy, los resultados de la segmentación de palabras de salida parecen más correctos.<|endoftext|> Tratada como una cadena arbitraria en lugar de un token especial, y dividida por el tokenizador BPE subyacente como cualquier otra cadena:

En resumen, Karpathy cree que las llamadas de codificación/decodificación nunca deben analizar cadenas para manejar tokens especiales, y esta funcionalidad debe quedar completamente obsoleta y solo agregarse explícitamente mediante programación a través de una ruta de código separada.

En la actualidad, estos problemas son difíciles de encontrar y rara vez se documentan. Se estima que alrededor del 50% del código actual tiene problemas relacionados.

Además, Karpathy descubrió que incluso ChatGPT tiene este error.

En el mejor de los casos, simplemente elimina el token de forma espontánea. En el peor de los casos, LLM no podrá entender lo que quiere decir y ni siquiera podrá repetir la salida según las instrucciones.<|endoftext|> Esta cadena:

Algunos internautas plantearon preguntas en el área de comentarios si el código está escrito correctamente, pero se ingresan los datos de entrenamiento.<|endoftext|> ¿lo que sucede?

Karpathy respondió que si el código es correcto, no pasará nada. El problema es que gran parte del código puede no ser correcto, lo que puede alterar silenciosamente su LLM.

Finalmente, para evitar problemas de seguridad causados ​​por las vulnerabilidades de LLM, Karpathy les recuerda a todos: deben visualizar su token y probar su código.

Referencias:

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