La siguiente anécdota no tiene un valor general:
En 1999, tomé el código fuente de PGP (no GnuPG, todavía en su infancia), versión 5.5, y lo compilé en mi máquina (que era un Alpha que ejecuta NetBSD, es decir, un sistema Unix bastante "normal"). El código fuente de PGP había estado disponible durante algunos años y, a menudo, se consideraba necesariamente seguro, ya que era de código abierto.
Por supuesto, casi de inmediato me encontré con errores. Miré la fuente, y resultó que:
- El código estaba usando el tipo
char como si no estuviera firmado, y, como tal, era completamente incapaz de procesar correctamente cualquier carácter más allá del conjunto ASCII de 7 bits. Fue así en todo el código.
- El código fuente era varios cientos de archivos de origen, en más de 30 subdirectorios (y sus subdirectorios).
Así que llegué a la conclusión de que, a pesar de ser un objetivo de alto perfil, con el código fuente abierto para inspección durante varios años (el código fuente incluso había sido impreso como un libro para evitar las regulaciones de exportación de los EE. UU. De esa época), nadie se molestó en verlo (o aquellos que lo hicieron, no tenían suficiente conocimiento en C para hacerlo correctamente).
El código no facilitó la auditoría; El código de auditoría ya es un esfuerzo bastante aburrido que es poco probable que los amateurs no pagados aborden por su propia cuenta. Es mucho más interesante, para el aficionado, reescribir todo desde cero, que es exactamente lo que ocurrió (con GnuPG ).
Aunque no creo, en general, en hordas de revisores aficionados sin nombre que auditan el código simplemente porque está ahí, hay proyectos que reúnen un poco de revisión, principalmente debido a las personas que quieren para modificar el proyecto para satisfacer sus necesidades. Por lo tanto, alteraciones maliciosas de las herramientas de seguridad son algo arriesgado. Lo que encontrará en todos los proyectos, de código abierto o no, relacionado con la seguridad o no, son errores , algunos de los cuales se pueden explotar para comportarse en beneficio de terceros (es decir, vulnerabilidades ).
La forma plausible de inyectar una puerta trasera en herramientas de seguridad de código abierto es cometer un error de diseño o implementación honesto, en particular cuando se trata de PRNG (ha habido algunas denuncias, aparentemente infundadas, de tal puerta trasera en OpenBSD; consulte esta respuesta ; la puerta trasera no estaba allí, pero todos se tomaron la cosa en serio, porque es plausible ).
Sobre una base teórica pura, la auditoría externa puede encontrar todas las puertas traseras exactamente tanto como puede descubrir todos los errores en el código auditado, es decir, no puede.