-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
-------------------------------------------------------------------
Hispasec - una-al-día 15/05/2008
Todos los días una noticia de seguridad www.hispasec.com
-------------------------------------------------------------------
Mitos y leyendas: Seguridad en ActiveX I (Introducción)
-------------------------------------------------------
ActiveX es una tecnología propia de Microsoft que con el tiempo ha sido clasificada prácticamente de maldita en cuestión de seguridad. Los
numerosos problemas tanto en la tecnología en sí como en los programas
que la han usado, han hecho que se gane esta fama a pulso. ¿Cuáles son
los riesgos y problemas de seguridad que presenta ActiveX realmente? ¿En realidad es tan peligrosa? Como siempre, no hay respuestas absolutas y
todas estas cuestiones son bastante discutibles.
¿Qué es?
De forma resumida, ActiveX es una tecnología de Microsoft. Es una
librería (básicamente un ejecutable) con funciones, como otro
cualquiera, con la peculiaridad de que implementa una interfaz llamada IDispatch que permite al "objeto" interactuar de una forma concreta (más abstracta) con el programa que lo aloja (llamado contenedor). Por tanto
no son programas "independientes" y suelen crearse con cualquier
lenguaje que admita el modelo COM. "Físicamente" tienen forma de
librería DLL o OCX. Internet Explorer o Office son programas
contenedores que admiten esta tecnología. Un componente ActiveX es pues,
código ejecutable (desarrollado por y para Microsoft) encapsulado en un
objeto desarrollado mediante esos estándares. De esta forma al tener
este código encapsulado, se facilita su portabilidad y reutilización.
Así, es posible usar un objeto ActiveX (llamar a sus funciones)
insertándolo en cualquier aplicación que lo soporte, independientemente
del lenguaje con el que haya sido creado el control ActiveX. Un ejemplo
común es usarlos para interactuar con Internet Explorer y el sistema, llamándolos a través de JavaScript. Un típico ejemplo de llamada a un
objeto ActiveX a través de una página es:
<HTML><object id="nombrecualquiera" classid="CLSID:012345567-12345-1234-A1234-F1234567789A"></object>
<script language="javascript"> nombrecualquiera.FuncionCualquieraDentroDelActiveX(a, b);
</script></HTML>
Donde existe una relación única entre el código CLSID y el archivo OCX o
DLL. Los análisis antivirus a través de web (sin necesidad de instalar
el producto) suelen hacerse a través de un ActiveX registrado, las
barras complementarias de Internet Explorer (Yahoo!, Google...) son
ActiveX registrados, el programa de instalación de Windows Update y
otros muchos que pasan desapercibidos para el usuario son todos ActiveX registrados.
Pero también existen de serie muchos ActiveX instalados en Windows para
el propio uso del sistema operativo, que no están pensados en ningún
momento para tener nada que ver con la web o redes sino que aprovechan
más su portabilidad y capacidad de ser reutilizados. Por último, muchos programas no basados en web que necesitan interactuar con otros
contenedores registran sus propios controles ActiveX.
¿Es igual que los applets de Java?
ActiveX, de hecho, fue en parte la respuesta de Microsoft a los applets
de Java, pero con importantes diferencias en las formas aunque con una filosofía parecida. Tanto los applets de Java como los ActiveX son en
una buena parte programas descargados y ejecutados en local. Los
creadores de la JRE ((Java Runtime Enviroment, el entorno donde se
ejecutan los applets) supieron que esto supondría un riesgo desde el
principio y por eso los applets se ejecutan "encerrados" en una sandbox
virtual que impide que el código tenga acceso a otras partes del sistema (excepto si aprovechan vulnerabilidades del JRE para escaparse de la
sandbox).
¿Por qué pueden resultar peligrosos?
Si nos centramos en la seguridad, el problema se puede presentar por
varias vías:
* Un ActiveX, al contrario que un applet encerrado en la sandbox, tiene
vía libre para acceder al sistema con los permisos del usuario que lo
ejecute. Tiene el mismo efecto que ejecutar un programa cualquiera.
* En el modelo actual, un ActiveX instalado (registrado) por un usuario administrador está disponible para el resto. Está expuesto para todos y
si contiene un problema de seguridad, afectaría a todos los usuarios.
* Muchos de los ActiveX, en el fondo, no son más que programas que se
descargan e instalan desde Internet Explorer. Por tanto, por un lado,
heredan los riesgos lógicos de la descarga y ejecución indiscriminada de cualquier otro programa. Pueden ser usados para distribuir malware en
forma de ActiveX aunque no es el caso mayoritario.
* Pero la razón más importante por la que un control ActiveX puede
resultar peligroso es por la misma que cualquier otro programa. No es
más que una pieza de código programada por un ser humano y por tanto
tendente a errores. El problema básico es que un fallo de seguridad en
un componente ActiveX "se paga más caro" en ellos que en otras
aplicaciones.
* Se paga más caro porque, aunque esté alojado en el sistema, ese OCX
o DLL es a veces accesible a través de Internet Explorer. El navegador,
como contenedor habitual, puede en ocasiones llamar a sus funciones y
si estas tienen un fallo, explotarlo. A efectos prácticos, si tenemos
un ActiveX (una DLL, por ejemplo) en el sistema para que funcione un
programa cualquiera que nada tiene que ver con la web, una página que
visitemos podría llamar (invocar) a esa DLL y explotar el fallo.
Básicamente, una puerta abierta a ejecutables del disco duro desde
Internet. De ahí su mayor peligro. La mezcla entre el diseño
excesivamente tolerante (responsabilidad de Microsoft) y programas
vulnerables mal diseñados (responsabilidad de los programadores del
ActiveX) han hecho que la tecnología sea considerada insegura.
Pero obviamente Microsoft ha impuesto buenos e importantes mecanismos
para mitigar estos riesgos. La firma de código, la programación de los
propios ActiveX donde se les dice qué pueden hacer, los kill bits, la configuración del propio navegador... muchos métodos han servido para
hacer que los ActiveX no sean tan poderosos como su propio concepto les permite, aunque a veces las medidas no han sido suficientes. Hablaremos
de todo esto en el siguiente artículo.
Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/3491/comentar
Sergio de los Santos
ssantos@hispasec.com
Tal día como hoy:
-----------------
15/05/2007: Varias vulnerabilidades en Samba 3.x
http://www.hispasec.com/unaaldia/3125
15/05/2006: Grave vulnerabilidad en RealVNC
http://www.hispasec.com/unaaldia/2760
15/05/2005: Publicado Service Pack 4 para Microsoft SQL Server 2000
http://www.hispasec.com/unaaldia/2395
15/05/2004: Escuchar los teclados para descubrir contraseñas
http://www.hispasec.com/unaaldia/2029
15/05/2003: e-Gallaecia: Seguridad 2003
http://www.hispasec.com/unaaldia/1663
15/05/2002: "Spam" para robar datos sensibles
http://www.hispasec.com/unaaldia/1298
15/05/2001: Importante actualización de IIS 4.0 y 5.0
http://www.hispasec.com/unaaldia/933
15/05/2000: El G8 contra el delito en la red
http://www.hispasec.com/unaaldia/566
15/05/1999: Galadriel, una semana después
http://www.hispasec.com/unaaldia/200
-------------------------------------------------------------------
Claves PGP en
http://www.hispasec.com/directorio/hispasec
-------------------------------------------------------------------
Bajas: mailto:
unaaldia-request@hispasec.com?subject=unsubscribe
Altas: mailto:
unaaldia-request@hispasec.com?subject=subscribe
-------------------------------------------------------------------
(c) 2008 Hispasec
http://www.hispasec.com/copyright
-------------------------------------------------------------------
--- SoupGate-DOS v1.05
* Origin: Pasarela FTN-INet
telnet://pucelabbs.dyndns.org:4000 (2:341/201.99)