En el software libre, existe una continua barrera muy fina entre las discusiones púramente internas y las declaraciones de relaciones públicas. Esto es parcialmente así porque la audiencia objetivo no esta muy-definida: dado que la mayoría o todos los posts son accesibles públicamente, el proyecto no tiene control sobre la impresión que de él tiene la gente. Alguien; digamos, un slashdot.org editor; puede arrastrar la atencion de millones de lectores' a un post sobre el que nadie esperaba que fuera visto fuera del proyecto. Este es un hecho real con el que todos los proyectos open source viven, pero en la práctica, el riesgo es normalmente pequeño. En general, los anuncios que el proyecto más quiere publicitar serán los que más se publicitarán, asumiendo que usas los mecanismos correctos para indicar los valores más relativos al mundo exterior.
Para grandes comunicados, suele haber cuatro o cinco canales principales de distribución, en cuales los anuncios deben ser hechos lo más simultáneamente posible.:
Probablemente la página principal de tu proyecto es la página más vista de tu proyecto. Si tienes un gran comunicado, pon la propaganda ahí. La propaganda debería ser un pequeño resumen que enlace a la noticia de prensa (ver abajo) para más información.
Al mismo tiempo, debes tener una parte del sitio web denominada "Noticias" o "Notas de prensa" donde los anuncios se describan en detalle. Parte del propósito de las notas de prensa es proporcionar un simple objeto de anuncio canónico al que otros sitios puedan enlazar, por lo que hay que asegurarse que está correctamente estructurado: tanto con una nueva página por release, como una entrada discreta de blog, o cualquier otro tipo de entidad que pueda ser enlazada manteniéndose todavía a parte de otras notas de prensa en la misma área.
Si tu proyecto tiene un feed RSS, asegúrate de que el anuncio tambíen irá por él. Esto puede ocurrir automáticamente al crear la nota de prensa, dependiendo de como está configurado tu sitio web. (RSS es un mecanismo para distribuir sumarios de noticias a través de meta-datos-enriquecidos a subscriptores, esto es, a gente que ha indicado un interés en recibir esos sumarios. Mira http://www.xml.com/pub/a/2002/12/18/dive-into-xml.html para más información sobre RSS.)
Si el anuncio va a ser sobre una nueva versión de el software, entonces actualiza la entrada de tu proyecto en http://freshmeat.net/ (mira “Anunciando” sobre crear entradas en primer lugar). Cada vez que actualices una entrada de Freshmeat, esta entrada irá a la lista de cambios de Freshmeat del día. Esta lista de cambios se actualiza no sólo en el propio Freshmeat, sino también en varios sitios de portales (incluyendo slashdot.org) el cual es visto tempranamente por hordas de gente. Freshmeat también ofrece la misma vía de datos a través de feed RSS, de tal manera que la gente que no esté subscrita al RSS de tu proyecto todavía puede ver el anuncio vía el RSS de Freshmeat.
Envía un mail a tú lista de correo de anuncios del proyecto.
Este nombre de lista actualmente debe ser algo como "anuncios", esto es,
announce@yourprojectdomain.org,
ya que es una convención muy estándar actualmente, y en la definición
de la lista debe indicarse claramente que se trata de una lista con un
tráfico muy bajo, reservada para anuncios internos del proyecto.
La mayoría de esos anuncios serán sobre nuevas releases de software, y
ocasionalmente de otros eventos, tales como fundraising drive, o sobre
descubrimientos de vulnerabilidades de seguridad (ver
“Anunciando Vulnerabilidades de Seguridad”)
después en este capítulo, también puede enviarse
un cambio de rumbo en la dirección del proyecto. Al tratarse de una
lista de tráfico bajo y usada sólo para cosas importantes, la
lista de anuncios tiene típicamente el mayor
número de subscriptores de cualquier lista de correo del proyecto
(por supuesto, esto significa que no deberías abusar de ella- consideralo
cuidadosamente antes de utilizarla). Para evitar que gente al azar
envíe anuncios, o lo que es peor, que llegue spam a través de ella,
la lista de anuncios debe ser siempre moderada.
Intenta realizar los anuncios en todos esos sitios al mismo tiempo , tanto como sea posible. A la gente puede confundirle si ven un anuncio en la lista de correo pero no lo ven reflejado en la página principal del proyecto o en su área de anuncios de prensa. Si tienes los diversos cambios (correos, ediciones de página web, etc.) encolados y preparados para enviarlos de una vez, podrás mantener la ventana de inconsistencia al mínimo.
Para un evento poco importante, puedes prescindir de alguno o todos los consejos de arriba. El evento todavía será conocido por el mundo exterior en proporción directa a su importancia. Por ejemplo, cuando una nueva liberación de software es un gran evento, marcar meramente la fecha de la siguiente liberación también debe tenerse en cuenta, aunque no sea tan importante como la liberación del software. Marcar la fecha merece un correo a la lista de correo diario (no a la lista de anuncios), y una actualización en la ruta del proyecto o del estado en la página web, pero no más.
Sin embargo, todavía puedes ver que las fechas aparecen en otros sitios de Internet, donde hay gente interesada en el proyecto. La gente suele actuar como lurkers en tus listas de correo, simplmente escuchando y sin decir nunca nada, no son necesariamente silenciosos en otros sitios. El boca a boca da una amplia distribución; deberías contar con ello, y construir incluso los anuncios menores de tal manera para la transmisión informal exacta. Específicamente, posts, que esperas que sean citados deberían tener una parte tiene-que-ser-citada, así como tú escribiste el anuncio formal. Por ejemplo:
Simplemente una actualización de progreso: estamos planeando liberar una versión 2.0 de Scanley a mediados de agosto de 2005. Siempre puedes revisar http://www.scanley.org/status.html en busca de actualizaciones. La principal nueva característica será búsquedas con expresiones regulares.
Otras nuevas características incluyen: ... También habrá varias correciones de bugs, incluyendo: ...
El primer párrafo es corto, da las dos piezas más importantes de información (la fecha de liberación y las principales nuevas características), y una URL para visitar en busca de más noticias. Sí este párrafo es la única cosa que se muestra en la pantalla de alguien, todavía lo estas haciendo muy bien. El resto del correo podría perderse sin afectar a la esencia del contenido. Por supuesto, en ocasiones la gente enlazará al correo completo, pero a menudo, citarán sólamente una parte. Dado que esto es una posibilidad, querrás poder hacerlo fácil para ellos, y conseguir alguna influencia sobre lo que se citará.
Manejar una vulnerabilidad de seguridad es diferente del manejo de cualquier otro tipo de reporte de error. En el software libre, hacer las cosas de manera abierta y transparente es normalmente casi como un credo religioso. Cada paso del proceso estándar de manejo de errores es visible a todo aquel que le preocupe verlo: la llegada del informe inicial, la consiguiente discusión, y la correción eventual.
Los errores de Seguridad son diferentes. Estos pueden comprometer datos de usuarios, y posiblemente ordenadores completos de usuarios. Para discutir tales problemas de manera abierta tiene que anunciarse su existencia a todo el mundo—incluyendo a todas las partes que pueden hacer un uso malicioso de la vulnerabilidad. Incluso realizando meramente el commit de una solución se anuncia efectivamente la existencia de la vulnerabilidad (existen atacantes potenciales que pueden buscar los logs de commits en proyectos públicos, buscando sistemáticamente cambios que indiquen problemas de seguridad en el código antes del cambio). La mayoría de proyectos open source han resuelto aproximadamente de la misma manera estos conflictos entre el secretismo y la abertura, basándose en estas guías básicas:
No hables sobre la vulnerabilidad de manera pública hasta que una solución esté disponible; entonces proporciona la solución al mismo tiempo exactamente que anuncias la vulnerabilidad.
Busca una solución tan rápido como puedas— especialmente si alguien externo al proyecto informo de la vulnerabilidad, porque sabes entonces que hay al menos una persona de fuera del proyecto que es capaz de explotar esa vulnerabilidad.
En la práctica, estos principios nos llevan a una serie de principios bastante estandarizados, los cuales se describen en la siguiente sección.
Obviamente, un proyecto necesita la característica de que cualquiera pueda informar sobre un error de seguridad. Pero la dirección regular para informar de errores no será, porque también puede ser vista por cualquiera. Por ello, tendrá que haber una lista de correo separada para recibir informes de errores de seguridad. Esta lista de correo no debe tener los archivos de manera que se puedan leer públicamente, y debe controlarse estrictamente a los subscriptores de la misma— sólo los desarrolladores de confianza y que lleven tiempo en el proyecto, podrán estar en la lista. Si necesitas una definición formal de "confianza", puedes orientarte con "cualquiera que ha tenido acceso para realizar commits desde hace dos años o más" o algo similar, para evitar favoritismos. Este es el grupo que manejará los errores de seguridad.
Idealmente, la lista de seguridad no debería estar moderada o protegida contra el spam, ya que no querremos que un informe importante pueda filtrarse o se retrase simplemente porque los moderadores no estuvieron online aquel fin de semana. Si usas software automática de protección de spam, intenta realizar una configuración con características de gran tolerancia; es mejor dejar pasar unos cuantos correos spam que perder un informe. Para que la lista sea efectiva, por supuesto que debes informar de su dirección; pero dado que no estará moderada, y en gran parte, ligeramente protegida de spam, intenta no publicar su dirección sin algun tipo de transformación y ocultación de la dirección, tal y como se describe en “Ocultar las direcciones en los archivos” en Capítulo 3, Infraestructura Técnica. Afortunadamente, el ocultar la dirección de correo no significa que ésta sea ilegible; echa un vistazo a http://subversion.tigris.org/security.html, y mira el código HTML de esta página, para ver un ejemplo.
¿Qué hace la lista de seguridad cuando recibe un informe? La primera tarea es evaluar la urgencia y severidad del problema. :
¿Cómo de seria es la vulnerabilidad? Permite que un atacante malicioso tome la computadora de alguien que utiliza tu sofware? o únicamente hay una fuga de información sobre el tamaño de algounos de sus archivos?
¿Cómo de fácil es explotar la vulnerabilidad? Se puede realizar el ataque con scripts, o hacerlo requiere un conocimiento circunstancial, suposiciones y suerte?
¿Quién te informó del problema?
La respuesta a esta pregunta, por supuesto que no cambia
la naturaleza de la vulnerabilidad, pero te da una idea de
cómo otras personas pueden conocerla. Si el informe viene de
uno de los desarrolladores del propio proyecto, puedes respirar
algo tranquilo (pero sólo un poco), porque puedes confiar en
que ellos no se lo dirán a nadie más. Por otra parte, si viene
de una dirección de correo como anonymous14@globalhackerz.net,
entonces lo mejor será que actúes tan rápido como puedas. Después de todo
la persona te hizo un favor informando del problema, pero no tienes idea
de a cuanta gente más se lo ha contado, o cuanto tiempo esperará antes
de explotar la vulnerabilidad en instalaciones en producción.
Nota que la diferencia que estamos hablando aquí es un rango estrecho entre urgente y extremadamente urgente. Incluso cuando el informe viene de una fuente conocida, puede haber otra gente en la red que descubrieron el bug hace tiempo y no han informado de ello. La única vez que las cosas no son urgentes es cuando el bug inherentemente no compromente la seguridad muy severamente.
El ejemplo de "anonymous14@globalhackerz.net" por
cierto, no es burlón. Realmente puedes obtener informes de gente con
identidades-encubiertas que, por sus palabras y comportamiento, nunca
clarifican si estan de tu parte o no. No importa: si te han informado de el
agujero de seguridad, ellos sienten que te han hecho un buen favor, y
tú deberías responderles de la misma manera. Agredeciéndoles el informe,
facilitándoles una fecha antes de la cual planeas liberar un parche público,
y mantenlo al tanto. Algunas veces ellos pueden darte una fecha—que
es, una amenaza implícita de publicar el bug en una fecha dada, si estás preparado o no.
Esto puede parecer un juego de poder de intimidación, pero es más una acción
preferente resultado de decepciones anteriores con productores de software
que no respondían y no se tomaban los informes de seguridad en serio.
This may feel like a bullying power play, but it's more likely a
preëmptive action resulting from past disappointment with
unresponsive software producers who didn't take security reports
seriously enough. De todas maneras, no puedes permitirte ignorar a esta persona.
Después de todo, si el bug es severo, el tiene conocimiento que podría causar grandes
problemas a tus usuarios. Trata a estos informadores bien, y espera que ellos tambien
te traten bien a tí.
Otro informador frecuente de agujeros de seguridad es el profesional de la seguridad, alguien que audita código cómo parte de su trabajo y se mantiene al día con las últimas noticias en las vulnerabilidades de software. Esta gente normalmente tiene experiencia en ambos lados de la vallya—ellos tanto han recibido como enviado informes, probablemente más que la mayoría los desarrolladores de tu proyecto tengan. Ellos normalmente también te darán una fecha fija para solucionar la vulnerabilidad antes de hacerla pública. Esta fecha puede ser negociable, pero esto dependerá del informador; las fechas fijadas han sido reconocidas entre los profesionales de la seguridad como la única vía fiable para que las organizaciones solucionen los problemas de seguridad puntualmente. Por lo que no trates la fecha fijada como algo grosero; es una larga tradición, y hay buenas razones para ello.
Una vez que conozcas la severidad y urgencia, puedes empezar a trabajar en la solución. A veces hay un sacrificio entre hacer una solución elegante y hacerla rápida; por esto, debeis acordar la urgencia antes de empezar. Manten la discusión de la solución restringida únicamente a los miembros de la lista, por supuesto también al informador original (si el quiere estar involucrado) y con cualquier desarrollador que se necesite contactar por razones técnicas.
No hagas el commit de la solución en el repositorio. Mantelo en forma de parche hasta la fecha de ir al público. Si fueras a hacer el commit, incluso con un mensaje de log aparentemente inocnete, alguién puede darse cuenta y comprender el cambio. Nunca sabes quién está observando tu repositorio y porque estos pueden estar interesados. Deshabilitar los correos del commit no ayudará; primero de todo, el intervalo en la secuencia del mail del commit resultaría sospechoso, y de cualquier manera, los datos todavía estarían disponibles en el repositorio. Simplmente haz todo el desarrollo en un parche y mantén el parche en algún lugar privado, quizás un repositorio privado y separado que sólo lo conozca la gente que está al tanto del bug. (Si usas un sistema de control de versiones descentralizado tal como Arch o SVK, puedes hacer el trabajo bajo el control de versión completo, y mantener simplemente el repositorio inaccesible a los desconocidos.)
Puedes haber visto un número CAN o un número CVE asociados con problemas de seguridad. Estos números son del tipo "CAN-2004-0397" o "CVE-2002-0092", por ejemplo.
Ambos tipos de números representan el mismo tipo de entidad: una entrada en la lista de "Exposiciones y Vulnerabilidades Comunes" mantenida en http://cve.mitre.org/. El propósito de esta lista es proporcionar nombres estandarizados para todos los problemas de seguridad conocidos, de tal forma que todo el mundo tenga un único, nombre canónico que usar cuando se discuta una, y un sitio central para encontrar más información. La única diferencia entre número "CAN" y número "CVE" es que el primero representa una entrada candidata, pero todavía no aprobada para incluirse en la lista oficial de la junta editorial CVE, y el último representa una entrada aprobada. Sin embargo, ambos tipos de entradas son visibles al público, y un número de entrada no cambia cuando es aprobado—el prefijo "CAN" es reemplazado simplmente con "CVE".
Una entrada CAN/CVE no contiene en sí misma una descripción completa del bug y como protegerse contra el. En lugar de eso, contiene un breve sumario, y una lista de referencias a recursos externos (tal como archivos de listas de correo) donde la gente puede ir para conseguir información más detallada. El propósito real de http://cve.mitre.org/ es proporcionar un espacio bien organizado en el cual cada vulnerabilidad pueda tener un nombre y una ruta clara a más datos. Mira http://cve.mitre.org/cgi-bin/cvename.cgi?name=2002-0092 cómo un ejemplo de una entrada. Observa que las referencias pueden ser muy secas, con fuentes apareciendo como abreviaciones crípticas. Note that the references can be very terse, with sources appearing as cryptic abbreviations. Una clave a estas abreviaciones está en http://cve.mitre.org/cve/refs/refkey.html.
Si tu vulnerabilidad cumple los criterios de CVE, puedes adquirir un número CAN. El proceso para hacer esto es deliberadamente por ingreso: básicamente tienes que conocer a alguien, o conocer a alguien que conozca a alguien. Esto no es tan disparatado como pueda sonar. Con el fin de evitar que la Junta Editorial de CVE este abrumada con falsos o envíos pobremente escritos, reciben los envíos sólo de fuentes de las que ya confían. Con el fin de conseguir listar tu vulnerabilidad , por lo tanto, necesitas encontrar un camino de conocimiento de tu proyecto al Consejo Editorial de CVE. Pregunta entre tus desarrolladores; alguno de ellos probablemente conocerá a alguien que haya realizado previamente el proceso de CAN, o conoce a alguien que lo ha hecho, etc. La ventaja de hacerlo de esta manera es tambien que en algún lugar a través de la cadena, alguien puede saber lo suficiente para decirte que a) no contará como una vulnerabilidad o exposición de acuerdo a los criterios de MITRE, por lo que no es necesario enviarlo, o b) la vulnerabilidad ya tiene un número CAN o. Lo último puede ocurrir si el bug ya ha sido publicado en otra lista de avisos de seguridad, por ejemplo en http://www.cert.org/ o en la lista de correo BugTraq en http://www.securityfocus.com/. (Si esto ha ocurrido y tu proyecto no se ha enterado, entonces deberías preocuparte por quien más puede saber algo que todavía no sabes.)
Si después de todo consigues un número CAN/CVE, normalmente querrás conseguirlo en la primera etapa de la investigación del bug, para que todas las comunicaciones consiguientes puedan referirse con ese número. Las entradas CAN están embargadas hasta la fecha de publicación; la entrada existirá como una reserva vacía (para que no pierdas el nombre), pero no revelará ninguna información sobre la vulnerabilidad hasta la fecha en la cual anunciarás el bug y la solución.
Más información sobre el proceso CAN/CVE puede encontrase en http://cve.mitre.org/about/candidates.html, y una exposición particularmente clara de el uso de los números CAN/CVE de un proyecto open source en http://www.debian.org/security/cve-compatibility.
Una vez que tu equipo de respuesta a seguridad (este es, aquellos desarrolladores que están en la lista de correo de seguridad, o quien ha estado involucrado con un informe particular) tienen un arreglo listo, necesitas decidir como distribuirlo.
Si simplemente realizas un commit con el arreglo en tu repositorio, o de lo contrario lo anuncias al mundo, efectivamente estarás forzando a todo el mundo que use tu software a actualizarse inmediatamente o estarán en riesgo de ser hackeados. A veces es apropiado, por lo tanto, hacer pre-notificaciones para ciertos usuarios importantes. Esto es particularmente cierto con software cliente/servidor , donde puede haber servidores bien conocidos que serán objetivos tentadores para atacantes. Los administradores de estos servidores apreciarán el tener un día o dos extra para realizar la actualización, de tal manera que ya estén protegidos una vez que el exploit sea de conocimiento público.
La Pre-notificación simplemente significa enviar correos a esos administradores antes de la fecha de publicación, avisándoles de la vulnerabilidad y de cómo solucionarla. Deberías enviar pre-notificaciones sólo a gente en la que confíes que serán discretos con la información. Esto es, la cualificación para recibir pre-notificaciones es doble: el destinatario debe administrar un gran e importante servidor donde un compromiso sería un asunto serio, y el emisor debe saber que no cotorreará sobre el problema de seguridad antes de la fecha de publicación.
Envía cada correo de pre-notificación individualmente (de uno en uno) a cada receptor. No envíes a la lista completa de receptores de una vez, porque podrán verse los nombres de cada uno; lo que significa que esencialmente estás alertando a cada receptor con el hecho de que cada uno de los otros receptores pueden tener un agujero de seguridad en su servidor. Enviarselo a todos vía CC ciegas (BCC) tampoco es una buena solución, porque algunos administradores protegen sus bandejas con filtros de spam tanto bloquean como reducen la prioridad de los correos con BCC, ya que mucho spam es enviado vía BCC actualmente.
Este es un correo de ejemplo de pre-notificación:
De: Tú nombre aquí A: admin@large-famous-server.com Responder-A: Tú nombre aquí (no la dirección de la lista de seguridad) Asunto: Notificación confidencial de vulnerabilidad Scanley. Este correo es una pre-notificación confidencial de una alerta de seguridad en el servidor Scanley. Por favor *no reenvíes* ninguna parte de este correo a nadie. El anuncio público no se hará hasta el 19 de Mayo, y nos gustaría mantener la información en secreto hasta entonces. Estas recibiendo este correo porque (pensamos) que administras un servidor Scanley, y quierrías tenerlo parcheado antes de que este agujero de seguridad sea público el 19 de Mayo. Referencias: =========== CAN-2004-1771: Desbordamiento de pila en consultas de Scanley Vulnerabilidad: ============== Se puede conseguir que el servidor ejecute comandos arbitrarios si la configuración local esta mal configurada y el cliente envía una consulta malformada. Severidad: ========= Muy severa, puede involucrar la ejecución de código arbitrario en el servidor. Solución alternativa: ============ Configurando la opción 'natural-language-processing' a 'off' en scanley.conf cierra esta vulnerabilidad. Parche: ====== El parche de abajo se aplica a Scanley 3.0, 3.1, y 3.2. Una nueva distribución pública (Scanley 3.2.1) se hará el 19 de Mayo o un poco antes, de tal manera que esté disponible al mismo tiempo que esta vulnerabilidad se haga pública. La única diferencia entre 3.2 y 3.2.1 será este parche. [...el parche viene aquí...]
Si tienes un número CAN, inclúyelo en la pre-notificación (cómo se muestra arriba), incluso aunque la información esté todavía oculta y de ahí que la página de MITRE no mostrará nada. Incluyendo el número CAN permite al receptor conocer con certeza que el bug con el que han sido pre-notificados es el mismo que luego oirán hablar en los canales públicos, por lo que no tendrán que preocuparse si es necesario realizar alguna acción, qué es precisamente el objetivo de los números CAN/CVE.
El último paso en el manejo de un bug de seguridad es distribuir la solución públicamente. En un único y comprensivo anuncio, deberías describir el problema, dar los números CAN/CVE si los tiene, describir alguna solución temporal, y cómo solucionarlo permanentemente. Normalmente "fix" significa actualizar a una nueva versión del software, aunque algunas veces puede significar aplicar un parche, particularmente si el software normalmente es ejecutado desde las fuentes. Si creas una nueva versión disponible, debe diferenciarse de las versiones existentes en únicamente el parche de seguridad. De esta manera, admins conservadores podrán actualizar sin preocuparse sobre a que más puede afectarle; tampoco tendrán que preocuparse de futuras actualizaciones, porque la solución del fallo de seguridad vendrá integrado en todas las futuras versiones (Detalles de procedimientos de liberación de versiones discutidos en “Security Releases” en Capítulo 7, Empaquetado, Liberación, y Desarrollo diario.)
Al margen de que la solución pública al bug de seguridad conlleve una
nueva versión, haz el anuncio con aproximadamente con la misma prioridad con
la que harías una nueva liberación de versión: envía un mail a la lista de
anuncios del proyecto, crea una nueva nota de prensa de la
liberación, actualiza la entreada de Freshmeat, etc.
Mientras tú nunca deberías restar importancia a la existencia de un bug
de seguridad por asuntos de la reputación del proyecto, ciertamente puedes
definir un tono de la importancia del anuncio de seguridad que coincida
con la severidad actual del problema. Si el agujero de seguridad es simplemente
una exposición de información menor, y no existe un exploit que permita tomar
un control total de la computadora del usuario, entonces no puede justificar
mucha preocupación. Puedes incluso decidir el no distraer a la lista de
anuncios con él. Después de todo, si el proyecto empieza
con este tipo de anuncios cada cierto tiempo, los usuarios pueden empezar a
pensar que el software es menos seguro de lo que actualmente es, y también
pueden dejar de creerte cuando exista un problema realmente grave que deba
anunciarse. Mira
http://cve.mitre.org/about/terminology.html cómo una buena
introducción al problema de judgar la severidad.
En general, si no estás seguro en como tratar un problema de seguridad, encuentra a alguien con experiencia y habla con él sobre ello. Evaluar y manejar vulnerabilidades es en gran parte una destreza adquirida, y es fácil cometer fallos las primeras veces.