descifrar de forma segura un mensaje PGP no solicitado / no confiable

Peligros de imprimir texto no confiable

  

El mensaje cifrado podría contener cualquier tipo de información no confiable o mal formada que podría intentar explotar mi entorno de bash, mi emulador de terminal, etc.

Cuando se envía un texto arbitrario a un terminal, como GnuPG lo hace por defecto, está arriesgando la explotación de su emulador de terminal. Se encuentran constantemente nuevas vulnerabilidades con respecto al manejo de texto no confiable que se imprime, y si bien las vulnerabilidades más graves se han eliminado, siguen siendo un problema. Una solución sería canalizar la salida no confiable a través de un comando que elimina los caracteres que no se imprimen. Puedes usar cat -v para este propósito. De la sección 3.1 de la página de información de GNU de coreutils:

-v
--show-nonprinting
    Display control characters except for LFD and TAB using ^ notation
    and precede characters that have the high bit set with M-.

La impresión de texto no confiable mientras se eliminan los caracteres que no se imprimen debe evitar la explotación de su emulador de terminal mediante códigos de control mal manejados o cualquier otra vía de ataque típica.

$ gpg -d untrusted.gpg | cat -v

Peligroso de descifrar mensajes no confiables

  

Cualquier vulnerabilidad potencial en GnuPG o cualquier otro cliente PGP que esté utilizando también podría ser explotada por datos no confiables.

Esto también es un riesgo. GnuPG es increíblemente complejo, y cualquier análisis de datos complejos puede llevar a la explotación. La única solución sería ejecutar GnuPG con espacio en el aire, o en una caja de arena cerrada o en una máquina virtual debidamente aislada. GnuPG v2 ha mejorado su arquitectura, permitiendo que el descifrado ocurra en un proceso que no tiene acceso a su clave privada, pero esto está lejos de ser una caja de arena completa. En general, siempre debe asumir que un atacante suficientemente competente será capaz de explotar GnuPG a través de una forma de proporcionarle un mensaje cifrado malintencionado.

Una búsqueda rápida mostró varias vulnerabilidades en GnuPG en los últimos 10 años:

• CVE-2008-1530 : corrupción de memoria a través de claves duplicadas de los servidores de llaves, lo que permite Ejecución del código.
• CVE-2010-2547 - Vulnerabilidad de uso después del certificado en el certificado análisis permitiendo la ejecución de código.
• CVE-2013-4242 : ataque de canal lateral que revela información de clave privada a los procesos locales.
• CVE-2013-4576 : ataque de canal lateral que permite el análisis de criptoanálisis acústico durante Descifrado RSA.
• CVE-2016-6313 : RNG roto que pierde 160 bits de material aleatorio , debilitando ciertos tipos de claves.

¿Pero cuál es el riesgo real?

  

¿Estoy yendo demasiado lejos con este riesgo o debo usar una máquina fuera de línea de un solo uso para descifrar cada mensaje individual y luego borrarlo de forma segura? ¿Qué otros controles o prácticas de seguridad puedo implementar para ayudar?

Una máquina con aire comprimido funcionaría bien, pero puede que no siempre sea una opción. No es necesario borrar los mensajes de forma segura después, ya que un mensaje no vinculado (eliminado) no representa ningún riesgo. La única razón para tratar de eliminar algo de manera segura es si no desea que esté disponible a través del análisis forense.

En general, el riesgo real debería ser bastante bajo. La explotación de un programa popular requiere un cierto nivel de experiencia que es poco probable que se utilice para comprometerlo a través de su sitio web a menos que sea de alto perfil o muy desafortunado. Hay formas más fáciles de comprometerse a través de una vulnerabilidad que a través de los mensajes de GnuPG (por ejemplo, hipervínculos para comprometer su navegador, imágenes para comprometer analizadores de imágenes, etc.). Aun así, hay algunas cosas que puede hacer para reducir este riesgo con respecto a GnuPG:

• Descifre los mensajes usando un usuario no privilegiado, o mejor aún dedicado.
• Eliminar los códigos de control de la salida descifrada. Nunca vea la salida en bruto con vim , less , etc.
• Mantenga actualizado GnuPG en todo momento para que las vulnerabilidades conocidas estén parcheadas en su sistema.
• Utilice el terminal virtual y no un emulador de terminal. Nunca use xterm o las horquillas relacionadas.
• Use AppArmor o similar en GnuPG. No lo ejecute bajo un usuario con acceso X11.

Esto es solo una parte de la respuesta, porque el bosque ya cubrió mucho terreno.

  

Lo que más me preocupa es la salida de texto no confiable.

Puede evitar fácilmente el manejo de texto no confiable en el terminal. Primero, en su cliente de correo, almacene el bloque de gpg cifrado en un archivo, por ejemplo, /tmp/encrypted_message.txt

Luego, en la terminal, ejecuta

$ gpg ... -o /tmp/decrypted_message.txt ...

Así que ahora tiene el mensaje descifrado en /tmp/decrypted_message.txt sin tener datos no confiables tocando el terminal / shell. Abra el archivo descifrado en cualquier aplicación en la que confíe para mostrarlo o envíelo por correo electrónico (ya que lo usa para mostrar texto que no es de confianza cuando recibe un mensaje no solicitado, por lo que no está aumentando la superficie de ataque). / p>

Debes preocuparte por otras cosas

Ejecutar comandos de shell ocultos en la entrada del usuario es en realidad un posible vector de ataque, ya que muchos sistemas son vulnerables a esto, por lo que desde el punto de vista del atacante vale la pena desarrollar la carga malvada necesaria, y desde su punto de vista es inteligente para eliminar el shell de su canalización cuando maneje la entrada del usuario siempre que pueda. Pero al almacenar la entrada no confiable encriptada en un archivo y hacer que gnupg produzca el texto descifrado en otro archivo, ya eliminó todos los contactos entre datos no confiables y el shell.

En su lugar, ahora debería preocuparse por las fallas en el resto de las aplicaciones de su canalización. gpg podría contener una falla que le permite a un atacante ejecutar un código de máquina arbitrario (generalmente el código que le da un shell al atacante) en su computadora. Pero gpg aparece en muchos menos canales que, por ejemplo, un navegador web o un cliente de correo, por lo que parece poco probable que un atacante escoja a GnuPG para buscar fallas que le permitan ejecutar shellcode, en lugar del navegador web y el correo electrónico que se usa mucho más a menudo. clientes, (a menos que él apunte a usuarios de GnuPG o usted específicamente, por supuesto, alguien podría estar apuntando a usuarios de GnuPG, pero hay tantos paquetes de software de alta exposición que parecen objetivos mejores que creo que principalmente debería preocuparse por alguien que en realidad se dirige a usted o su sitio web, individualmente.

Airgapping para leer los mensajes que los usuarios de su sitio web le envían me parece demasiado cauteloso a menos que esté ejecutando la próxima Ruta de la Seda y tenga miedo de que la policía de EE. UU. lo persiga, en cuyo caso podría entender por qué se preocupa. Pero si desea aislar gpg , puede usar software como firejail . Esto significa que un atacante que haya encontrado una falla en GnuPG que le permita ejecutar código arbitrario también tendrá que encontrar una falla en el kernel de Linux antes de poder escapar de la cárcel a su sistema real y hacer más daño.

(Editar: se modificó la respuesta para reflejar la discusión en los comentarios / chat)