Parches y actualizaciones, un problema común

SeguridadVirus

Las actualizaciones y parches son un tema común a todos los fabricantes
de software, desde Microsoft a Sun o IBM.

Alertas de seguridad

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 brinda el servicio de alertas SANA de Hispasec, 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.

Según desvela los

resultados del 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.

Velocidad de reacción

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.

Actualizaciones y parches

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 pueden 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.

Lea también :