El pasado día 15 publicamos en «una-al-día» las explicaciones de
Microsoft sobre su nueva política de actualizaciones. Hoy damos la
palabra a nuestros lectores, que en gran número nos hicieron llegar
sus comentarios y razonamientos al respecto.
Debido al gran volumen de mensajes, y lo extenso de algunos, vamos
a intentar resumir en cinco puntos los argumentos que más se
repitieron por parte de los lectores.
1) Las vulnerabilidades existen y se explotan antes de ser publicadas
En las explicaciones de Microsoft podíamos leer «Las vulnerabilidades
representan un aumento exponencial del riesgo a partir de su
descubrimiento y anuncio, no antes. […] no perdemos en materia de
seguridad desde el momento que asumimos que el riesgo es casi
inexistente antes de cualquier tipo de anuncio».
Respecto a esta afirmación, son muchos los lectores que recuerdan
que no todas las vulnerabilidades se publican cuando son
descubiertas, no todo los hackers son «whitehats». De hecho existen
grupos de investigación dedicados a descubrir vulnerabilidades y
a explotarlas en beneficio propio.
Que una vulnerabilidad no se publique, no quiere decir que no
existan ataques basadas en ellas que estén pasando desapercibidos.
El sistema debe ser seguro por diseño, no porque no se publiquen
o se oculten sus fallos. No a la seguridad por oscuridad.
2) Microsoft no descubre las vulnerabilidades
Según Microsoft «en ese 0.1% de casos donde el orden de sucesos no
ocurra de esta forma, como por ejemplo el conocimiento de una
vulnerabilidad de forma previa a la creación del update».
Para muchos lectores ese porcentaje tal vez sería válido a la inversa,
es decir, la inmensa mayoría de los descubrimientos de agujeros en
el software de Microsoft son autoría de terceras personas ajenas a
la compañía. Por lo tanto las vulnerabilidades suelen conocerse antes
de la creación y distribución de la actualización.
Microsoft no puede, ni debe, controlar el descubrimiento y
publicación de vulnerabilidades.
3) Las empresas planifican sus propias políticas de actualizaciones
«La medida está pensada fundamentalmente para minimizar situaciones
de actualización de software no planificadas, y permitir que una
corporación pueda planificar sus recursos adecuada y ordenadamente
ante una actualización de seguridad.»
Muchos administradores de sistemas y responsables de seguridad
indican que cuentan con sus propias políticas corporativas de
actualizaciones, y que la planificación de éstas no deben estar
condicionadas (ni se van a ver mejoradas) porque las actualizaciones
se encuentren disponibles un día determinado.
En la mayoría de los casos, en ambientes críticos, los parches y
actualizaciones deben pasar unos tests y controles de calidad en
sistemas de pruebas, antes de distribuirlos en los sistemas en
producción. No en vano, la instalación directa e inmediata de los
parches puede ocasionar problemas de incompatibilidad,
mal funcionamiento, o regresión de vulnerabilidades.
Este tipo de comprobaciones, que hasta ahora se hacía de forma
escalonada y puntual según publicación de parches concretos, ahora
resulta más complicada al acumularse todo en una fecha, y puede
dar lugar a retrasos en el despliegue final. No es lo mismo, ni
se tarda el mismo tiempo, en comprobar que una actualización para
Internet Explorer es correcta, que en comprobar 6 o 7 parches para
diferentes componentes del sistema.
En definitiva, en muchos casos la acumulación de parches supone un
retraso en la distribución final de los mismos en ambientes
corporativos. Los administradores piden que la actualización se
encuentre disponible tan pronto sea posible, ya serán ellos los que
decidan como les afecta, la prioridad, y el día en que se procederá
a su instalación.
4) Dificultad para usuarios sin banda ancha en la descarga de grandes
actualizaciones
Algunos usuarios, que conectan a Internet a través de módems
analógicos conectados a la red telefónica básica, muestran su
preocupación por la acumulación y distribución de los parches
en un mismo día.
Si algunas actualizaciones individuales pueden ocupar megas, la
actualización del paquete mensual puede llegar a ser todo un
inconveniente para ellos.
Como anécdota, recordar que fueron muchos los usuarios domésticos que
tuvieron problemas con la actualización de la vulnerabilidad que
explotaba el gusano Blaster, ya que en el tiempo que tardaban en
descargarse la actualización desde Internet el gusano volvía a
infectarles y/o a reiniciar sus equipos.
5) Comparativa Microsoft vs. Linux cualitativa (no cuantitativa)
Con respecto a los números barajados por Microsoft, a la hora de
comparar vulnerabilidades entre sus sistemas y algunas distribuciones
de Linux, los lectores hacen hincapié en que es necesario distinguir
entre vulnerabilidades de aplicaciones y del propio sistema operativo.
Las distribuciones cuentan con un gran número de aplicaciones, de
instalación opcional, que no forman parte del sistema operativo.
Además, no basta con dar números absolutos, debería analizarse
cuantas de esas vulnerabilidades son explotables remotamente, y el
impacto real en la seguridad de los usuarios.
La propia política de Microsoft, de integración de aplicaciones y
funcionalidades extras en el propio sistema operativo, supone un
aumento en el número de vulnerabilidades que afectan a todos sus
sistemas. Un ejemplo claro lo tenemos en Internet Explorer.
Con respecto a la resolución, muchos lectores recuerdan que en
algunos casos la comunidad Open Source, tras el descubrimiento de
una vulnerabilidad, facilita parches en cuestión de horas. En
última instancia, el usuario tiene el control sobre el sistema,
y no depende exclusivamente de la resolución de una empresa.
La clave
A título personal, aunque comparto de forma genérica las opiniones
de los lectores, creo que la clave en la explicación de Microsoft
está en la afirmación «en ese 0.1% de casos donde el orden de
sucesos no ocurra de esta forma, como por ejemplo el conocimiento
de una vulnerabilidad de forma previa a la creación del update, NO
SE SEGUIRÁ ESTA NORMA DE PUBLICACIÓN MENSUAL y se publicará en
cuanto la actualización esté preparada.»
El caso es que desde hace semanas tenemos varios de esos casos, en
concreto hay varias vulnerabilidades de Internet Explorer que se
han hecho públicas (algunas desde finales de noviembre), han sido
catalogadas como críticas (tanto por su impacto como por la
facilidad de explotación), y están siendo aprovechadas en ataques.
A día de hoy, finales de diciembre, aun no hay parches para corregir
esas vulnerabilidades. De entrada queda patente los tiempos de
respuesta de Microsoft ante vulnerabilidades críticas. Si bien aun
queda pendiente conocer cuando se publicarán finalmente estos
parches.
Si los parches de Internet Explorer se publican en su paquete de
actualizaciones mensuales, el segundo martes de enero, en vez de
hacerlo de forma puntual en cuanto tengan la solución (dada la
importancia), Microsoft habrá tirado por tierra gran parte de sus
propias argumentaciones.
bernardo@hispasec.com
Más información:
Explicaciones de Microsoft sobre su nueva política de actualizaciones
http://www.hispasec.com/unaaldia/1877
Parches y actualizaciones, un problema común
http://www.hispasec.com/unaaldia/1884
Deja una respuesta