Mozilla publica parche oficial para la vulnerabilidad en Firefox 3.5

Mozilla ha publicado ya oficialmente la versión 3.5.1 que corrige el fallo en JIT que permitía la ejecución de código. El exploit fue publicado por sorpresa, cuando el equipo de desarrollo todavía no disponía de una versión corregida que ofrecer a los usuarios. Pensaban publicar la actualización a finales de julio, pero han acelerado convenientemente el proceso para emitir la nueva versión lo antes posible.

¿Pero no existía parche ya?

A raíz de la cantidad de comentarios recibidos en nuestros buzones, sobre la información publicada en la una-al-día “Ejecución de código en Mozilla Firefox. No existe parche oficial disponible”, creemos necesario aclarar ciertos puntos y actualizar la información existente.

El comentario más repetido es que “sí” existía parche en el momento de la publicación de la noticia. Queremos aclarar y ratificarnos en que no existía, hasta este momento, parche oficial disponible, aclarando correctamente lo que es un parche oficial. Entendemos como “parche oficial”, un método de actualización que no exija “recompilación” del software, ofrecido por el fabricante, y que haya pasado unos mínimos controles para comprobar que no introduce nuevos errores. El mismo blog de seguridad oficial de Mozilla (http://blog.mozilla.com/security/),

escribía:

Status: “Mozilla developers are working on a fix for this issue and a Firefox security update will be sent out as soon as the fix is completed and tested.”

Estaban trabajando en una solución. En cuanto han creído que el parche es correcto, no abre nuevos fallos y está concienzudamente comprobado, han subido a la página oficial la versión 3.5.1 para que todo el mundo pueda descargarla. La política de Firefox en este sentido es crear nuevas versiones con la solución integrada. Desde el día 13 (cuando ya se conocía el fallo) y hasta ahora, solo estaba disponible para descarga oficial la versión 3.5, vulnerable. No había parche oficial comprobado, si no, obviamente Mozilla lo habría subido como descarga pública oficial.

¿Qué tenían entonces antes de la versión 3.5.1?

Tenían la localización del problema, y un planteamiento de modificación del código para solucionar el fallo (que probablemente fuese el definitivo), en forma de archivo .diff o precompilaciones diarias inestables o versiones de desarrollo. Pero eso no es un parche oficial.

Cuando existe un fallo de seguridad, y más cuando se tiene delante un exploit, la parte más “sencilla” es localizar la línea que origina el problema y programar una solución. Esto es prácticamente inmediato sea software libre o no. Lo complicado es integrar esto en una versión oficial que sea compilada y distribuida públicamente, asegurándose de que no introduce regresiones, problemas de estabilidad y que de verdad soluciona todos los vectores por los que la vulnerabilidad puede ser aprovechada. Solo este último punto puede llevar semanas. Si no se respeta este paso, se corre el riesgo de emitir constantes versiones con regresiones (un problema más común de lo que parece) e introducir inestabilidades.

En un entorno no profesional, casero, es viable aplicar un parche en forma de archivo .diff, compilar extraoficialmente y asumir los problemas potenciales que esto puede acarrear. Pero en entornos profesionales, con decenas o cientos de máquinas que administrar, no es tan sencillo. Todo debe seguir funcionando, y nadie que se tome en serio su negocio usaría versiones no estables, en desarrollo o compilaciones diarias en entornos de producción más o menos críticos. En entornos más exigentes, incluso no aplican nunca los parches oficiales nada más son publicados, sino que son todavía más cautelosos y esperan a comprobar que no introducen nuevos problemas.

También cabe recodar, que deshabilitar el origen del problema no es “solucionar” la vulnerabilidad.

Con respecto a la vulnerabilidad, aclaramos que el fallo se encuentra en en el compilador Just-in-time (JIT). La rama 3.0.x no se ve afectada.

Fuente:Noticias Hispasec

Read More

Las nuevas versiones de Samba corrigen dos vulnerabilidades

Las nuevas versiones de Samba (3.0.35, 3.2.13 y 3.3.6) corrigen dos vulnerabilidades que podrían permitir a un atacante eludir restricciones de seguridad e incluso ejecutar código arbitrario, lo que podría llegar a comprometer el servidor que alojase este servicio.

Samba es una implementación Unix “Open Source” del protocolo SMB/NetBIOS, utilizada para la compartición de archivos e impresora en entornos Windows. Gracias a este programa, se puede lograr que máquinas Unix y Windows convivan amigablemente en una red local, compartiendo recursos comunes. Incluso es factible utilizar un servidor Samba para, por ejemplo, actuar como controlador de un dominio Microsoft Windows.

El primero de los errores se trata de un acceso a una zona de memoria que no se ha inicializado previamente. Ocurre cuando se deniega el acceso a la modificación de las listas de control de acceso (ACL) restringidas, al no leer la zona correcta de memoria para aplicar la restricción. Esto podría ser aprovechado por un atacante para modificar las ACL de ficheros sin que posea los permisos correspondientes. La directiva “dos filemode” debe estar establecida a “yes” en smb.conf.

El segundo se debe a un error de formato de cadena en la utilidad smbclient, a la hora de procesar nombres de ficheros recibidos como parámetros. Un atacante podría inducir a un usuario a ejecutar algún comando de smbclient (con nombres de ficheros especialmente manipulados como argumentos) y ejecutar código arbitrario en el servidor. También podría aprovecharse como vector de ataque algún automatismo legítimo que utilice smbclient, haciéndole procesar ficheros con nombres manipulados.

Fuente:Noticias Hispasec

Read More

Microsoft corrige 14 vulnerabilidades en PowerPoint

Tal y como adelantamos, este martes Microsoft ha publicado sólo un boletín de seguridad (el MS09-017) correspondientes a su ciclo habitual de actualizaciones. Esta actualización que corrige un total de 14 vulnerabilidades presenta, según la propia clasificación de Microsoft, un nivel de gravedad “crítico”.

Las vulnerabilidades corregidas afectan a diversas versiones de PowerPoint de Microsoft Office (XP, 2000, 2002, 2003 y 2007), Office para Mac y el visor de archivos PowerPoint (PowerPoint Viewer 2003 y 2007). Entre las vulnerabilidades corregidas se incluye el problema ya comentado anteriormente que venía siendo explotado de forma activa desde primeros de abril.

Todos los problemas corregidos pueden permitir la ejecución remota de código al abrir un archivo PowerPoint maliciosamente construido. El problema se agravaba al ser PowerPoint un formato de archivo sobre el que la gente tiende a confiar, y que se usa con frecuencia para el intercambio de presentaciones de todo tipo entre usuarios (desde presentaciones profesionales hasta totalmente intrascendentes), lo que podría permitir la rápida infección debido precisamente a estos factores.

Las actualizaciones publicadas pueden descargarse a través de Windows Update o desde el boletín de Microsoft donde se incluyen las direcciones de descarga directa de cada parche. Dada la gravedad de las vulnerabilidades se recomienda la actualización de los sistemas con la mayor brevedad posible.

Fuente:Noticias Hispasec

Read More

Adobe parchea a medias su vulnerabilidad casi un mes después, mientras Foxit Reader lo soluciona en 10 días

La ShadowServer Fundation advirtió el día 19 de febrero de una potencial vulnerabilidad en Adobe Acrobat Reader que podría permitir a un atacante ejecutar código arbitrario. Al descubrirse el problema mientras estaba siendo aprovechado activamente por atacantes, se convierte en un grave 0day. Adobe reconoció la vulnerabilidad y esperó al día 10 de marzo para publicar parche solo para algunas versiones. Foxit Reader, afectada por un problema muy parecido, necesitó solo 10 días para solucionar el fallo.

Es más que probable que el fallo fuese conocido incluso desde hace bastante más tiempo, y que Adobe tuviese constancia de su existencia.

Pero solo lo reconoció el mismo día en el que la ShadowServer lo hizo público. El día 23, para complicar el asunto, aparece un exploit público para múltiples lectores PDF, que permite una denegación de servicio aprovechando los flujos JBIG2, base del problema de Adobe. Este ejemplo daba muchas pistas a los atacantes sobre cómo crear un exploit que permitiese la ejecución de código.

El día 26 de febrero, SourceFire (dueños del IDS snort) publica un parche rápido para mitigar el problema. El día 27, Secunia avisa a Foxit Reader, otro popular lector de PDF, de que también es vulnerable a este problema. 10 días después Foxit publica una actualización y lo soluciona. Adobe ha necesitado más de 20 días para publicar un parche para sólo algunas de sus versiones. Y contando desde que lo reconociera, que no significa que no estuviese al tanto desde bastante antes.

Adobe lo soluciona un día antes del prometido, pero solo a medias.

Publica la versión 9.1 para Windows, olvidando las ramas 8 y 7 para otros sistemas operativos.

Para colmo, recientemente se ha descubierto una nueva forma mucho más sencilla de aprovechar la vulnerabilidad. Un nuevo vector de ataque que permite incluso ejecutar código sin necesidad de abrir el archivo con el lector. A través del explorador de Windows, simplemente mostrando una carpeta que contenga un documento PDF especialmente manipulado (y basándose en el servicio de indexación, que debería estar activo), sería posible ejecutar código en el sistema.

Fuente:Noticias Hispasec

Read More

Boletines de seguridad de Microsoft en marzo

Tal y como adelantamos, este martes Microsoft ha publicado tres boletines de seguridad (del MS09-006 y MS09-008) correspondientes a su ciclo habitual de actualizaciones, que corrigen un total de ocho vulnerabilidades. Según la propia clasificación de Microsoft uno de los boletines presenta un nivel de gravedad “crítico”, mientras que los dos restantes son “importantes”.

El boletín “crítico” es:

* MS09-006: Actualización del kernel de Microsoft Windows que soluciona tres vulnerabilidades que podrían permitir la ejecución remota de código arbitrario.

Los dos boletines “importantes” son:

* MS09-007: Actualización destinada a corregir una vulnerabilidad en Secure Channel (Schannel) de Windows que podría permitir a un atacante remoto la falsificación de certificados.

* MS09-008: Actualización para DNS y WINS que resuelve cuatro vulnerabilidades que podrían ser aprovechadas por un atacante remoto para falsificar respuestas y redirigir tráfico de Internet.

Las actualizaciones publicadas pueden descargarse a través de Windows Update o consultando los boletines de Microsoft donde se incluyen las direcciones de descarga directa de cada parche. Dada la gravedad de las vulnerabilidades se recomienda la actualización de los sistemas con la mayor brevedad posible.

Más información:

Microsoft Security Bulletin Summary for March 2009 http://www.microsoft.com/technet/security/bulletin/ms09-mar.mspx

Microsoft Security Bulletin MS09-006 – Critical Vulnerabilities in Windows Kernel Could Allow Remote Code Execution http://www.microsoft.com/technet/security/Bulletin/MS09-006.mspx

Microsoft Security Bulletin MS09-007 – Important Vulnerability in SChannel Could Allow Spoofing http://www.microsoft.com/technet/security/bulletin/MS09-007.mspx

Microsoft Security Bulletin MS09-008 – Important Vulnerabilities in DNS and WINS Server Could Allow Spoofing http://www.microsoft.com/technet/security/bulletin/MS09-008.mspx

Fuente:Noticias Hispasec

Read More

Denegación de servicio a través de NFSv4 en Sun Solaris 10

Sun ha publicado una actualización para Sun Solaris 10 y OpenSolaris que soluciona un fallo que podría permitir a un atacante remoto provocar una denegación de servicio.

El fallo del que no se han facilitado detalles se presenta en el módulo NFS del kernel. Un atacante sin privilegios podría hacer que el servidor NFS deje de responder si comparte el sistema de ficheros hsfs.

Según versión y plataforma, se recomienda instalar los siguientes

parches:

Para la plataforma SPARC:

Solaris 10 instalar el parche 139462-02 o superior desde:

http://sunsolve.sun.com/search/document.do?assetkey=urn:cds:docid:1-21-139462-02-1

Para la plataforma x86:

Solaris 10 instalar el parche 139463-02 o superior desde:

http://sunsolve.sun.com/search/document.do?assetkey=urn:cds:docid:1-21-139463-02-1

Más información:

Denial of Service (DoS) Vulnerability in NFSv4 Server Kernel Module

http://sunsolve.sun.com/search/document.do?assetkey=1-66-252469-1

Fuente:Noticias Hispasec

Read More

La nueva versión de Firefox corrige otras ocho vulnerabilidades (Thunderbird, olvidado)

Apenas un mes después de corregir seis vulnerabilidades con la última 3.0.6, Mozilla lanza la nueva versión 3.0.7 de su navegador Firefox que soluciona otros ocho fallos de seguridad. Seis de ellos críticos.

La nueva versión de Firefox soluciona ocho vulnerabilidades aglutinadas en cinco boletines. Tres de estos boletines tienen carácter crítico (permite ejecución remota de código con solo visitar una página web), uno es considerado de alto riesgo y uno de carácter bajo.

Específicamente, cada boletín:

* Un problema de falsificación de URL usando caracteres de control invisibles.

* Se ha actualizado la librería PNG para solucionar riesgos de seguridad con la memoria.

* Riesgo de robo de datos a través de RDFXMLDataSource.

* Un problema con el recolector de basura podría permitir ejecución de código.

* Múltiples problemas de corrupción de memoria con evidencias de posibilidad de ejecución de código.

Estos fallos, como de costumbre, también afectan al cliente de correo Thunderbird y SeaMonkey. Para los usuarios de Thunderbird, solo queda deshabilitar JavaScript para intentar mitigar solo algunos de estos problemas, o bien lanzarse a buscar las versiones en pruebas en los servidores FTP de la fundación Mozilla.

Mozilla todavía no ha corregido las anteriores vulnerabilidades aparecidas en febrero y que se supone deberían haber sido solucionadas con la versión 2.0.0.20 de Thunderbird. Incluso un mes después todavía no está disponible para descarga desde el sitio oficial (sigue la

2.0.0.19 disponible desde finales de diciembre). Ahora, anuncia que en una futura versión 2.0.0.21 (para la que no se indica fecha) se solucionarán también esta tanda de problemas.

Fuente:Noticias Hispasec

Read More

La nueva versión de Opera soluciona tres vulnerabilidades y añade soporte DEP y ASLR

La nueva versión de Opera, 9.64 soluciona tres vulnerabilidades. Además, la versión para Windows añade dos características destinadas a mitigar el impacto de los problemas de seguridad que puedan surgir en el futuro.

Opera ha publicado la versión 9.64 para corregir tres vulnerabilidades.

No se han dado muchos detalles sobre los problemas. Solo se sabe que una de ellas es grave y está relacionada con la forma en la que el navegador procesa ficheros de imágenes en formato JPEG. Este fallo podría permitir la ejecución de código arbitrario.

Para las otras dos vulnerabilidades, se darán detalles más adelante, según Opera Software. Se ha incluido además otras mejoras relacionadas con el rendimiento y la estabilidad y se han corregido otros problemas en general.

Para la versión de Windows del navegador, además se han añadido un par de funcionalidades interesantes. Soporte para DEP y ASLR.

DEP es una funcionalidad de Windows que significa Data Execution Prevention y su objetivo es evitar en la medida de lo posible que las vulnerabilidades del software deriven en ejecución de código. Si se tiene un procesador compatible, no permitirá que zonas de memoria dedicadas a datos sean usadas para ejecutar código.

Si no, se activa el DEP propio de Windows, que protege de otra forma. Si un software es compatible con DEP (como es ahora el caso de Opera) y realiza una excepción (una operación inválida), se comprueba que la excepción está “documentada” y registrada en una tabla localizada en el propio fichero. Se trata de una especie de manejador de excepciones a nivel de sistema operativo. Si el software no es compatible DEP comprueba que al menos la zona de memoria donde se maneja la excepción está marcada como ejecutable por el programa. Sería muy sospechoso que un programa realizara una excepción y fuese a parar a una zona no marcada como ejecutable.

En cualquier caso, DEP debe estar activado en el sistema para que los programas que sean compatibles lo aprovechen (disponible a partir de XP SP2).

ASLR sólo está disponible de serie en Windows Vista. Los ejecutables, a través de un cambio en su cabecera, pueden aprovecharse de esta funcionalidad y cargarse en zonas de memoria diferentes cada vez que son ejecutados. De esta forma, para un atacante es mucho más complicado conocer las zonas de memorias donde ha inyectado código y llamarlas para su ejecución.

Fuente:Noticias Hispasec

Read More

Adobe al más puro estilo Microsoft: parche no oficial para Acrobat Reader

Puesto que Adobe decidió “esperar” varias semanas para solucionar un grave problema de seguridad, ya ha aparecido un parche no oficial programado por un tercero. Esta era una parcela que hasta ahora se creía reservada para el sistema operativo Windows. Adobe Reader está cada vez más en el punto de mira de la industria del malware, como buen vehículo para instalar troyanos en el sistema sin que el usuario lo perciba. Ha protagonizado una nueva ola de ataques y Adobe sigue sin responder correctamente, sin experiencia en ser el centro de atención. ¿Sabrá esquivar los golpes que pueden llegarle en los próximos años?

Symantec y Shadowserver dieron la voz de alarma a mediados de febrero:

una nueva vulnerabilidad de Acrobat estaba siendo aprovechada para instalar malware. Poco después Adobe publica una nota oficial en la que reconoce el fallo, pero afirma que lo solucionará el 11 de marzo e incluso más tarde para las ramas más veteranas del producto. No publica más información, ni contramedidas, ni consejos, ni alcance… nada.

Se creía que se trataba de un ataque dirigido, minoritario, hasta que un par de días después, se hace público un exploit capaz de aprovechar el fallo. Ahora, más que nunca, es de dominio público y Adobe deja desprotegidos a sus usuarios ante una amenaza más que palpable.

SourceFire (dueños del IDS snort) ha tenido mucho que ver en esto.

Publicaron el día 20 los detalles de la vulnerabilidad y fue cuestión de tiempo que apareciera un exploit. SourceFire se justifica diciendo:

“la vulnerabilidad está siendo aprovechada desde principios de enero.

Preferimos que la gente esté protegida”.

Mientras, SourceFire publica un parche no oficial para solucionar el problema. Tal y como ha ocurrido en otras ocasiones con Microsoft, investigadores privados se adelantan y son capaces de mitigar el problema en cuestión de días. Bien es cierto que estos parches no tienen ningún tipo de garantía, y que no han superado las pruebas de calidad y compatibilidad a las que los suelen someter las empresas oficiales.

Hasta ahora, los parches no oficiales habían sido, casi en exclusiva, algo de Windows y Microsoft, cuando se le acusaba de no solucionar a tiempo graves problemas de seguridad.

Brian Krebs preguntó al director de seguridad de Adobe por qué no habían incluido información en su alerta para mitigar el problema, como por ejemplo, recomendar el deshabilitar JavaScript. La respuesta fue que deshabilitar JavaScript no atacaba la raíz del problema. Poco después la alerta oficial fue actualizada para incluir la recomendación. Adobe además, ha publicado esta semana un parche para Flash Player que soluciona un grave problema de ejecución de código.

Adobe se ha visto envuelta en un episodio del que normalmente no es protagonista, un incidente al que nos tenía (y a veces, nos tiene) más acostumbrado Microsoft. Y quizás debería aprender de quien ha recibido incontables reveses al respecto. No es la primera vez que Adobe no reacciona convenientemente antes un grave fallo de seguridad. Aunque es un software tremendamente popular, parece no tener experiencia a la hora de ofrecer unos boletines de seguridad completos, fiables, puntuales y con información útil sobre las vulnerabilidades. Esa información es muy necesaria para que un administrador de una gran empresa que gestione cientos de máquinas pueda lidiar con el problema hasta que se publique una solución.

Microsoft, con más de 15 años siendo el centro de atención del malware, ha superado a marchas forzadas ciertos aspectos, ofreciendo normalmente información detallada sobre las vulnerabilidades, contramedidas más o menos eficaces, etc. Dispone de un equipo de respuesta a incidentes que aunque no es perfecto, cumple holgadamente su función. Una de las máximas de muchas compañías es no invertir en soluciones para problemas que no existen. Cuando el problema se presenta de repente (aunque no es el caso, venimos anunciando que Adobe es carne de malware desde hace tiempo), entonces las reacciones no son las deseadas.

En el hipotético caso de que Microsoft pierda protagonismo y otros programas se conviertan en menor medida en centro de atención del malware, cuando los atacantes fragmenten y diversifiquen sus objetivos… ¿estarán preparados para encajar este golpe el resto de “candidatos”?

Fuente:Noticias Hispasec

Read More