| Kriptópolis alojado en |
| Zilos-Veloxia Network |
| Tu mejor defensa: |
| Bufet Almeida |
Analizando el torpedo 1 de Zalewski
Enviado por anv el 20. Diciembre 2006 - 13:54.
Por Alejandro Nestor Vargas
Pensando en problemas y motivos, me dio por analizar el torpedo 1, a ver si me daba una idea de por qué no lo solucionan.
La página contiene un javascript que inserta múltiples veces un archivo xml.
Para profundizar en el asunto intenté descargar directamente ese archivo (una sola vez), pero eso sólo bastó para que Firefox se cerrara con un "Segmentation fault", así que lo bajé con wget para ver su contenido...
Como vi que tardaba (mide 3Mbytes), no esperé a que terminara, y en realidad no hace falta; con el pedacito que bajé me bastó para ver lo que tiene: el contenido es una etiqueta "<x>" repetida un millón de veces.
Como se imaginarán, el intérprete de html cuando ve que se abre una etiqueta, como por ejemplo "<x>" debe guardar en su stack el estado, a la espera de que la etiqueta se cierre ("</x>"). Si esto no ocurre, lo que debería hacer es continuar dejando pendientes las etiquetas hasta que se cierren o hasta que se acabe la memoria del sistema, lo cual podría redundar en algo bastante molesto para el usuario.
Firefox parece que no hace ni una cosa ni la otra: cuando la pila de etiquetas abiertas llega a un límite determinado, simplemente aborta con un Segmentation fault, lo cual no me suena muy bien, porque significa que intentó escribir en un área de memoria que no tenía reservada para tal fin. Obviamente Firefox no soporta tener un millón de etiquetas abiertas.
¿Cuál podría ser la solución a esto? Me imagino que debe ser poco más que trivial verificar la cantidad de etiquetas pendientes y cuando superen un valor razonable, digamos por ejemplo 1024, emitir un error y abortar la interpretación de la página.
¿Por qué no lo han hecho? Me imagino que pensarán que ni el señor Zalewski ni el problema de que se cierre el navegador ante un caso tan poco probable merecen la atención de los desarrolladores, que estarán ocupados en cosas que consideran más graves.
Es posible que el área reservada para el stack no tenga posibilidades de sobreescribir datos de programa y por eso se genere el Segmentation fault (el sistema operativo se encarga del control) y por lo tanto no haya posibilidad de que se produzca una inyección de código, aunque no puedo estar seguro de eso sin analizar el fuente de Firefox, y dudo que sea fácil verificarlo, así que ni pienso intentarlo.
Pues es un fallo serio
No es la primera vez que por error un php me entra en un bucle ( iterativo o recursivo, para el caso es lo mismo ), y empieza a generar miles de millones de tags hasta que el php se queda sin memoria... o casca el navegador
¿Tanto consumiría en recursos o código un test que compruebe el nivel de anidación de un tag? Escribo desde mi ignorancia del fuente del firefox, pero a mi me parece un parche trivial... Me imagino que el tema puede venir con el famoso "vale, aquí detectamos un error, ¿ y cómo salimos del embrollo? ¿mensaje de error?¿pantalla vacía?, a ver, que decida el jefe..."
Como decía mi "viejo" profesor de sistemas operativos: Nunca detectes una condición de error que no puedas manejar :-)
No es tan simple
Creo que no es tan simple como contar las etiquetas abiertas.
También se podría dar un desbordamiento con una sola etiqueta, tipo <x...(100000)...x>, o con combinaciones de N etiquetas de M longitud, sin contar con que cada una puede tener J atributos...
Contar la memoria quizá fuera buena idea... si no fuera porque seguramente no es simple, y además depende fuertemente del equipo.
mozilla tambien
El browser mozilla 1.7.8 (no firefox) bajado de los repositorios oficiales de Debian también es vulnerable
Pero entonces...
...¿por qué es necesario javascript para activarlo?
Yo podría construir un documento HTML con un millón de etiquetas abiertas ante las que sucumbiría el navegador (según tu razonamiento), tuviera o no activado javascript.
¿Qué hay de diferente en inyectar etiquetas HTML mediante javascript, que hacerlo directamente en el fichero?
SKS, criptografía de curva elíptica de bolsillo
http://sks.merseine.nu..
Para Shevek
Supongo que será por el trabajo de tener que copiar y pegar hasta un número lo suficientemente grande como para colapsar Firefox. Se hace con javascritp o con PHP porque es más rápido.
Moya
copiar y pegar
shevek: no se por qué zalewsky habrá insertdo el código con javascript. De hecho, no hace ninguna falta para matar a Firefox. Sin embargo con el javascript lo inserta muchas veces y no una sola. Puedes verlo yendo a la página del torpedo (con javascript desactivado) y mirando el código fuente. Ahí verás lo que hace el shell script. Copia y pega la dirección en la barra de direcciones y verás que incluso con javascript desactivado, el Firefox se muere.
gadolino: No hace falta copiar y pegar un millón de veces (literalmente) para generar el archivo que está insertando el "torpedo" ese. Basta con un sencillícimo shell script de una sóla línea para crearlo.
Alejandro Nestor Vargas
Opinar