Realizar una auditoría

Esta página le proporciona un vistazo somero de los pasos que son necesarios para afrontar la auditoría de un paquete.

El primer paso es elegir un paquete que realmente necesite examinarse. Debería elegir uno cuya seguridad sea crítica.

Diríjase a la lista de paquetes cuya auditoría es prioritaria para encontrar sugerencias que le ayudarán a tomar su decisión.

Una cosa que debería tener clara es que no pretendemos que el paquete se audite una sola vez. Es bueno que muchas personas elijan examinar el mismo paquete, porque se demostrará que mucha gente piensa que ese paquete es sensible a cuestiones de seguridad.

Permitiendo una selección de paquetes esencialmente aleatoria, simplificamos la coordinación y eliminamos el problema de ¿cómo puedes fiarte de que la persona X ha hecho un buen trabajo? (No lo necesitamos porque asumimos que tarde o temprano alguien decidirá examinar el mismo programa).

Comenzar la auditoría

Tras tomar la decisión de los paquetes, tiene que comenzar la verdadera auditoría.

Si no está seguro del tipo de problemas que tiene que buscar, comience leyendo un libro sobre desarrollo de software seguro.

Secure Programming for Linux and Unix HOWTO (n.t. en inglés) tiene información de calidad que puede resultarle muy útil. Secure Coding: Principles & Practices, de Mark G. Graff y Kenneth R. van Wyk (n.t. en inglés) también es un excelente libro.

Aunque las herramientas son imperfectas, puede ser extremadamente útiles para encontrar posibles vulnerabilidades. Diríjase a la página de herramientas de auditoría para encontrar más información acerca de algunas de las herramientas de auditoría disponibles y de cómo se usan.

Además de mirar el propio código, es buena idea leer la propia documentación del paquete, e intentar instalarlo y usarlo.

Esto le debería permitir urdir maneras de subvertir el comportamiento típico del programa.

Informar de problemas

Si descubre un problema en el paquete que está examinando, debería informar de ello. Cuando informe de un fallo de seguridad, intente proporcionar también un parche, para que los desarrolladores puedan repararlo cuanto antes. No es necesario facilitar una muestra de ataque (lo que se suele llamar un exploit o una prueba de concepto), ya que el parche debería hablar por sí msimo. Suele preferirse la inversión de tiempo en proporcionar un parche adecuado que en facilitar un ataque con éxito que saque provecho del error.

Aquí tiene una lista con los pasos recomendados para cuando encuentre un error de seguridad en Debian:

  1. Intente producir un parche para el error u obtener información suficiente para que otros puedan determinar la existencia del fallo. De forma ideal, cada fallo debería contener una solución para el problema que se ha descubierto, y que se haya probado y verificado que ciertamente corrige el problema.

    2. Si no tiene una solución para el problema, lo mejor será que dé los máximos detalles sobre el ámbito del problema, la severidad de la incidencia y la información adicional que haya recopilado sobre ella durante su análisis.

  2. En primer lugar, compruebe si el error de seguridad está presente en la versión estable de Debian o si puede estar presente en otras distribuciones o en la versión original.
  3. Según los resultados de la comprobación anterior, informe del incidente:
    • Al desarrollador original, a través del correo electrónico de contacto para seguridad. Proporcione el análisis y el parche.
    • Al equipo de seguridad de Debian, si el error está presente la versión publicada de Debian. El equipo de seguridad de Debian le suele asignar un nombre CVE a la vulnerabilidad. El equipo de seguridad se coordinará con otras distribuciones de Linux si fuese necesario y se pondrá en contacto con el responsable del paquete en su nombre. Una cosa que podría hacer usted es mandar también una copia del correo al responsable del paquete. De todas formas, hágalo sólo cuando se trate de vulnerabilidades de bajo riesgo (tiene más información abajo).
    • Si el error no está presente en la versión publicada de Debian y la aplicación puede estar presente en otras distribuciones o sistemas operativos, escriba a vendor-sec (una lista de correo privada que la mayoría de distribuciones de software libre utilizan para debatir sobre errores de seguridad). No tiene que hacer esto si ya ha enviado el fallo al equipo de seguridad de Debian, puesto que este equipo también seguirá los pasos de esta lista.
    • Si el error no está presente en ninguna de las versiones publicadas por Debian y está absolutamente seguro de que la aplicación no forma parte de ninguna otra distribución ni sistema operativo, informe de ello a través del sistema de seguimiento de fallos.
  4. Una vez que la vulnerabilidad sea pública (por ejemplo, cuando el equipo de seguridad de Debian o cualquier otro vendedor haya emitido un aviso) se rellenará un informe de fallo con toda la información relevante en el sistema de seguimiento de fallos de Debian para seguir la pista de las incidencias de seguridad en las versiones no publicadas de Debian (esto es, sid o en pruebas). Esto lo suele hacer el propio equipo de seguridad. De todas formas, si viera que no se ha producido este paso o si no va a avisar de esto al equipo de seguridad, puede informar usted mismo. Asegúrese de que la etiqueta del fallo es la adecuada (use la etiqueta seguridad) y de que ha definido la prioridad apropiada (normalmente, grave o superior). Asegúrese también de que el título del error incluye el nombre CVE adecuado, si es que se le ha asignado. De esta forma se le puede seguir la pista a los errores de seguridad que se han corregido tanto en las versiones publicadas como en las no publicadas de Debian.
  5. Si lo desea, una vez que sea pública la incidencia, puede reenviar esta información a listas de correo públicas de divulgación, como full-disclosure o Bugtraq.

Tenga en cuenta que estos pasos pueden variar según el riesgo asociado con la vulnerabilidad que se encuentre. Tiene que valorar el riesgo según:

Se deben dar distintos pasos, por ejemplo, para informar de un ataque local de enlaces simbólicos que sólo puedan aplicar los usuarios autenticados y que sólo provea de una forma de dañar el sistema que para informar de un desbordamiento remoto de buffer que proporcione privilegios administrativos y esté presente en un software popular y de gran difusión.

En la mayor parte de los casos, los errores de seguridad no se deberían revelar hasta que se hayan corregido. Por tanto, no informe de ellos por el sistema estándar de seguimiento de fallos. En su lugar, informe del problema directamente al equipo de seguridad, que gestionará la publicación de un paquete actualizado y, una vez corregido, informará de ello en el BTS.