Auditoría de seguridad de la biblioteca OTR3

CoyIM utiliza su propia implementación del protocolo OTR. Esta implementación se llama OTR3. Esta biblioteca está escrita en Golang y desde el principio ha sido extremadamente bien probada. El objetivo de la biblioteca es dar soporte absoluto para la versión 3 del protocolo OTR y también implementar todas las características necesarias para que sea una biblioteca fácil de integrar y utilizar para los distintos clientes. Dado que esta biblioteca es el aspecto de seguridad más importante del cifrado de extremo a extremo de CoyIM, decidimos que queríamos priorizar la realización de una auditoría para asegurarnos de que esta funcionaba como se esperaba y que además no tenía vulnerabilidades u otros problemas.

En 2019-2020, contratamos a la firma de seguridad sin fines de lucro Radically Open Security para que nos ayude a realizar una auditoría completa de la biblioteca de OTR3. Puedes leer el informe final aquí. Este informe fue actualizado por Radically Open Security para incluir verificaciones de las correcciones aplicadas al OTR3. Esta auditoria informó acerca de seis hallazgos, todos los cuales se han corregido en el código base actual. Sólo un problema (OTR3-005) fue remoto, y únicamente puede ser utilizado para bloquear el proceso, no para extraer información. La solución para este problema se registró en este issue. Un problema (OTR3-004) identificó la falta de controles del sistema de archivos. En este problema se identificó que la biblioteca OTR3 puede exportar material de claves privadas a archivos que no tienen permisos tan restringidos como podrían ser. Esta funcionalidad no se utiliza en CoyIM, ya que CoyIM almacena material clave en su propio archivo de configuración. Este problema se solucionó fácilmente aplicando permisos más restrictivos.

Tres de los problemas restantes (OTR3-001, OTR3-003 y OTR3-006) se relacionan con el material de las claves que se deja en la memoria o que no está bloqueado en la memoria. Dado que OTR3 está escrito en Golang, un lenguaje seguro para la memoria, eso hace que sea difícil controlar qué sucede con el material de claves en la memoria del proceso. Con un lenguaje de programación donde sea necesario hacer gestión de la memoria, esto sería más fácil de manejar, pero nos abriría una gran variedad de otros tipos de vulnerabilidades. Sin embargo, las tres cuestiones se resolvieron en la medida de lo posible, usando el acceso directo a la memoria para intentar limpiar las áreas de memoria que pertenecen a la biblioteca estándar y para usar una biblioteca llamada memguard para proteger la memoria que pertenece a la implementación OTR3. Si bien es imposible garantizar que estos enfoques funcionarán al 100% en todas las situaciones, son suficientes para proteger contra este tipo de amenazas.

El último problema (OTR3-002) se relaciona con la implementación de diferentes algoritmos que requieren exponenciación. La biblioteca OTR3 utiliza la funcionalidad de biblioteca estándar para realizar estos cálculos matemáticos, algo que también hacen las propias implementaciones criptográficas de Golang. Sin embargo, como se describe en una sección anterior, esta operación tal como se implementa en la biblioteca estándar de Golang no es de tiempo constante. Eso significa que se necesitarán diferentes cantidades de tiempo para hacer los cálculos dependiendo de las claves privadas. Si alguien puede observar estos tiempos de alguna manera (que en la configuración de OTR no sería trivial hacerlo), podrían revelar partes de los dígitos del material de la clave privada. En teoría, un atacante remoto podría aprender el peso de Hamming (el número de unos en la representación binaria de la clave) de una clave efímera. Aunque se trataba de una posibilidad muy teórica, y algo que otras implementaciones de algoritmos criptográficos de Golang no priorizan, decidimos que arreglarlo valía la pena el esfuerzo. La forma en la que resolvimos el problema involucraba la creacción de una nueva biblioteca de código abierto llamada constbn, que proporciona específicamente las operaciones de enteros grandes que necesitamos, implementadas de manera constante en el tiempo. Con esta solución implementada, OTR3 no es vulnerable a los ataques de tiempo.

El informe deja claro que el código inicial tenía una buena actitud defensiva con una superficie de ataque limitada, y que esta superficie de ataque estaba bien defendida. La conclusión dice que “el código luce maduro y tiene una buena postura de defensa”. En general, habiendo resuelto los hallazgos anteriores, sumado a los comentarios sobre la calidad del código, el equipo de desarrollo de CoyIM está muy contento con estos resultados. Nos sentimos cómodos recomendando que las personas usen OTR3 para asuntos delicados.

También nos gustaría agradecer enormemente a Radically Open Security. Fue un placer trabajar con ellos. Su apoyo ha hecho que CoyIM y OTR3 sean mejores proyectos en el proceso. Si necesitas ayuda con las auditorías de seguridad, especialmente para proyectos de código abierto, podemos recomendarlos fácilmente.