Esta página es un servicio gratuito de Video Soft BBS - SUBSCRIBASE en nuestras listas de correo.
 

Busque su tema:

VSantivirus  Internet
Proporcionado por FreeFind

Video Soft BBS
Menú Principal
Anti Trojans
Antivirus
Hoaxes
Subscripciones
Otro software
Artículos
Links
Sugerencias
Sobre el BBS
Direcciones
Galería
Chat

Controlado desde el
19/10/97 por NedStat

Manejo responsable en la información de vulnerabilidades
 
VSantivirus No. 1206 Año 7, Domingo 26 de octubre de 2003

Manejo responsable en la información de vulnerabilidades
http://www.vsantivirus.com/agr-responsable.htm

Por Alejandro Germán Rodríguez (*)
Peligros_en_la_red-owner@onelist.com


Recientemente mencionábamos la actitud responsable desarrollada tanto por el descubridor, como por el vendedor, en la última falla del navegador Opera y su cliente de correo asociado.

El manejo prolijo que se hizo del problema detectado permitió que en menos de un mes la falla fuera corregida sin riesgos para los usuarios.

Los pasos, utilizando el sentido común, deberían ser:

1. Detección de una falla por parte de un investigador/usuario.

2. Informar al vendedor/fabricante, de lo descubierto.

3. Análisis por parte del vendedor/fabricante de lo informado.

4. Confirmación de la existencia de la falla.

5. Solución de la falla en un plazo de tiempo razonable.

6. Dar a conocer públicamente la existencia de la falla.

Lamentablemente se dan situaciones anómalas, por ambas partes tanto del descubridor como del vendedor.

Por parte del descubridor:

Existe una creencia, errónea a mi entender, que sugiere que haciendo pública una falla, supone un impulso por parte del fabricante a solucionarla.

Un fabricante que conozca la existencia de una falla cuando ésta se hace pública en una lista de correo o un foro, y que recién a partir de ese momento comience el proceso desde el paso (3) mencionado anteriormente, supone un riesgo para los usuarios, toda vez que no existe protección hasta la aparición de la actualización o parche, y es lógico suponer que dicha solución tome algún tiempo.

En otras ocasiones, al parecer, el descubridor informa de una falla descubierta, pero en un plazo de tiempo que él considera apropiado y sin que la falla haya sido corregida aún, decide publicar su descubrimiento.

Este caso aunque más parecido a la lógica de los pasos (1) a (6), encierra siempre el peligro de dejar expuestos a los usuarios. Así mismo, el descubridor toma el papel de juez estableciendo el plazo en el cual la compañía debe solucionar el problema.

Según la falla a la que nos referimos, el programa que afecta, y la complejidad de su explotación, algunas veces surgen "exploits", métodos automatizados de explotarla, lo que pone un arma en manos de cualquiera (aun sin conocimientos específicos) y la convierte en una verdadera bomba de tiempo.

Ejemplo de esto, son los virus del tipo Blaster, que explotan una falla conocida en el protocolo RPC en Windows.

La acción más temeraria por parte de los usuarios es el pseudo-chantaje, la amenaza de hacer pública una falla a menos que se desembolse una suma de dinero.

En junio de 1997, Christian Orellana un consultor informático danés, amenazó con hacer pública una falla en el navegador Netscape, ya que pretendía una suma superior a los 1,000 dólares que solía abonar la compañía para incentivar a los descubridores de fallas. Por el solo hecho de haber pretendido una suma superior a lo que la empresa ofrecía, el premio no se hizo efectivo.

Esta actitud, está muy cercana a la extorsión y podría estar penada en algunos países, y es en definitiva contraria a una actitud solidaria.

Por parte de las compañías:

Una actitud que se ha dado en el pasado, por parte de algunas compañías de software, es la de menospreciar la falla detectada indicando que ésta es de muy difícil explotación, o que su solución implicaría un cambio radical de la arquitectura del programa.

Una compañía que lleva adelante esta actitud, desincentiva a los investigadores a informar sus hallazgos sin importar que sean muy graves o triviales.

A veces, la compañía desarrolla métodos alternativos de configuración o de operación, para solucionar aunque sea parcialmente la falla, pero dichos métodos son poco profesionales y no arreglan el problema de fondo, la falla en la programación del software que se sacó al mercado.

Como política corporativa, todas las fallas informadas deberían ser tratadas con la misma importancia.

Otra actitud de la que hemos sido testigos más de una vez, es la de informar una falla, que ésta caiga en el olvido, y cuando toma estado público, surja casi mágicamente la solución o el parche.

De la misma manera que existen sectores dedicados a la atención de clientes y reclamos, debe existir un sector específico que recepcione y valide la información sobre fallas detectadas.

Quienes en definitiva se perjudican, son los usuarios finales, que han comprado el programa y son rehenes de la relación "informante de fallas versus compañía de software".


(*) Alejandro Germán Rodríguez mantiene la lista de seguridad "Peligros en la Red", y es un asiduo colaborador de VSAntivirus.


http://ar.groups.yahoo.com/group/Peligros_en_la_red
ICQ # 44796626





(c) Video Soft - http://www.videosoft.net.uy
(c) VSAntivirus - http://www.vsantivirus.com

 

Copyright 1996-2003 Video Soft BBS