Parches y actualizaciones, un problema común

En una-al-día no es la primera vez que hacemos referencia a los parches,

actualizaciones, Services Packs y similares publicados por Microsoft,

los problemas que estos pueden ocasionar, los problemas de regresión,

fallos que contienen, etc. Sin embargo este es un problema común a todos

los fabricantes, diferentes distribuciones Linux, Sun, IBM, HP y en

general todos los fabricantes se ven afectados por problemas similares.

La experiencia que nos brinda nuestro servicio de alertas SANA, nos ofrece la

oportunidad de conocer de primera mano todos y cada uno de los parches

publicados para otros sistemas operativos no tan populares como los de

Microsoft, pero no por ello menos importantes, en algunos casos al estar

destinados a labores de gran importancia.

Sistemas como HP-UX

destacan por llegar a publicar más de 15 parches y actualizaciones a la

semana, otros incluso más populares como Sun Solaris también rondan el

mismo número. Por no mencionar el número de actualizaciones que pueden

llegar a publicarse para aplicaciones de estos sistemas, algunas como HP

OpenView, Sun ONE, Sun Cluster, etc. con números que aun pueden superar

a los anteriores. IBM y su sistema profesional más extendido como es

AIX, también destaca por el número de parches publicados que

semanalmente puede llegar a superar los 30.

Una muestra de estos

resultados se puede comprobar a través del una al día del pasado 3 de

diciembre, en la que se desvelaban los resultados de nuestro servicio

SANA. En un mes se publicaron un total de 202 alertas en torno a los

sistemas y aplicaciones de IBM, mientras que de los sistemas Sun

recibieron 117 informaciones, HP llegó a un total de 109 publicaciones

mientras que por su parte Microsoft contó con 41 alertas.

Otro problema destacable que se presenta en estos sistemas es la

tardanza en la publicación de parches para evitar problemas hechos

públicos con anterioridad. Un ejemplo, las vulnerabilidades de

desbordamiento de búfer anunciadas en junio del 2002, en torno a las

librerías de resolución de DNS (aviso del CERT CA-2002-19), fue

corregido de forma inmediata en la mayoría de los sistemas Linux,

mientras que HP en septiembre de este año aun publicaba parches para

corregir el problema en algunos de sus sistemas HP-UX. No deja de ser

cierto que no es habitual que los sistemas HP-UX cuenten con sistemas

DNS, pero es un ejemplo que se repite habitualmente en este tipo de

sistemas. Microsoft al no hacer uso de las librerías afectadas (libc,

libbind o glibc) no se vio atacada por este problema.

La revisión

de boletines, parches, etc. también es algo habitual en todos los

fabricantes, recientemente Microsoft publicó la revisión número 12 del

boletín de seguridad MS02-050 debido a un problema de regresión. La

actualización que comentamos anteriormente para la vulnerabilidad en el

DNS de HP-UX, publicada en el boletín HPSBUX0208-209, cuenta con 15

revisiones. Los problemas de regresión también son habituales en todo

tipo de sistemas y de igual forma podríamos citar múltiples ejemplos.

En Julio de 2001 se detectaron diversos problemas de seguridad en múltiples

implementaciones del protocolo LDAP de múltiples productos que permitían

ataques de denegación de servicio y accesos no autorizados. Lotus Domino

R5.0.7 y anteriores estaban afectados por estos problemas. Lotus

corrigió estas graves vulnerabilidades en Domino R5.0.7a publicado el 18

de Mayo de 2001. Sin embargo, curiosamente en las versiones pre-release

y beta de Lotus Domino R6 se volvió a detectar estos mismos problemas en

el protocolo LDAP, que quedaron definitivamente corregidos en la versión

R6.0 Gold o superiores.

Por otra parte y como punto a favor hay

que destacar a los sistemas Linux en velocidad de reacción de resolución

de las vulnerabilidades. Además de disponer de diversos medios para

corregir los problemas, en este sentido las ideas Open Source ayudan

mucho para la resolución de problemas. En ocasiones disponemos de la

solución en forma de código fuente que será necesario compilar de forma

inmediata a la publicación del problema o disponer de los paquetes

específicos publicados por el creador del software afectado. Pero si el

usuario lo prefiere, bastará con esperar unos pocos días, para tener los

paquetes específicos para distribución que se tenga instalada.

También hay que destacar la compatibilidad como una de las grandes ventajas

del sistema de actualizaciones de los sistemas Solaris, es decir se

garantiza que no existen incompatibilidades. Si un programa funciona,

tras la actualización del sistema también funcionará. Aunque también se

producen múltiples casos en los que el parche no realiza su cometido

adecuadamente.

Otro punto a considerar son las diferentes formas en que cada fabricante

actualiza o parchea sus sistemas. Mientras que Microsoft tiende a

realizar parches por producto además de, en ocasiones, acumularlos para

que formen un solo parche (tanto para el sistema operativo como para

otros como su famosa suite ofimática), otras compañías utilizan otros

sistemas, como el de paquetes (clásico en las diferentes variantes de

los sistema Unix), más pormenorizado y que puede dar una sensación mayor

de volumen.

La conveniencia o no de las diferentes filosofías de

presentar correcciones no es algo que queramos discutir. Si se observa

el panorama de una forma lo más global posible al final se descubre que,

como dice el refrán en todas partes cuecen habas y nadie está libre de

problemas. Aunque en teoría los modelos de desarrollo formales definen

unos pasos a seguir para asegurar en lo posible la calidad de los

programas realizados, la aplicación estricta de estos – a todos los

niveles, no sólo pensando en modelizar un sistema a grandes rasgos –

haría que el tiempo de desarrollo de un producto complejo se extendiese

de forma dramática.

No se pretende disculpar la existencia

de fallos en los sistemas. Debemos evitar caer en el conformismo que

comentaba Bernardo Quintero en su boletín del 12/11/2003 (Microsoft

distribuye los parches de noviembre), parece que todos asumimos que los

fallos existen y debemos convivir con ellos. Hasta llegar al punto de

que a nadie le sorprende ver un pantallazo azul en un sistema Windows

9x. Lo importante en el fondo es que ciertas compañías adquieran un

verdadero compromiso sobre los productos que desarrollan, y que realicen

un esfuerzo a la hora de realizar los cambios necesarios en ellos cuando

se detecten errores. Este es quizá el factor determinante: la agilidad

de respuesta ante los errores que día a día aparecen en el mundo de la

informática.

Respecto a los boletines que publica cada

fabricante también se puede realizar diferentes análisis. En este punto

cabe decir que los mejores en todos los aspectos son, sin lugar a dudas,

los publicados por Microsoft. Posiblemente al tener que dirigirse a

niveles tan heterogéneos de público, desde los usuarios más noveles

hasta los administradores más avanzados, nos encontramos con boletines

claros, sencillos de asimilar, con toda la información necesaria para

entender los problemas claramente analizada y con facilidad para

encontrar el parche necesario.

Sin embargo, los boletines

publicados por otros fabricantes, como IBM o Sun, resultan complejos de

asimilar, sin duda debido a que se dirigen a un público mucho más

experto por lo que se entiende que no son necesarios grandes detalles,

aunque ello impide que se facilite una descripción completa de los

problemas y no un mero telegrama acerca de estos.

También es

lamentable la actuación de algunos fabricantes al dificultar el acceso a

la información publicada, restringen los accesos a la información

únicamente a los usuarios registrados de sus productos y obligan a los

usuarios a acudir su web al no emitir ninguna alerta por e-mail. Es

totalmente lícito el ofrecer la información solo a los usuarios de sus

productos, pero todos los usuarios también deberían poder conocer los

problemas de los que adolece cada producto antes de adquirirlo.