Portada
mis comunidades
otras secciones
#4:
El problema viene a ser más bien de las aplicaciones. Las aplicaciones que siguen estas recomendaciones de seguridad: http://msdn.microsoft.com/en-us/library/ff919712%28VS.85%29.aspx no tienen problemas.
Pero es más fácil culpar de todo a Microsoft, claro. Y poner titulares claramente sensacionalistas.
Pero es más fácil culpar de todo a Microsoft, claro. Y poner titulares claramente sensacionalistas.
#11:
¿Y los datos para afirmar que Windows sea más inseguro hoy que hace diez años?
Ah, en ningún lado, es simplemente un titular llamativo.
Ah, en ningún lado, es simplemente un titular llamativo.
Comentarios
El problema viene a ser más bien de las aplicaciones. Las aplicaciones que siguen estas recomendaciones de seguridad: http://msdn.microsoft.com/en-us/library/ff919712%28VS.85%29.aspx no tienen problemas.
Pero es más fácil culpar de todo a Microsoft, claro. Y poner titulares claramente sensacionalistas.
#4 ¿Se puede explotar algun agujero de seguridad de este tipo en linux u otro S.O.? si es no, entonces es también culpa del S.O.
#5 Por supuesto, si un programa no utiliza correctamente dlopen(3). Por eso hay versiones seguras de Unix que desactivan la posibilidad de usar dlopen() con rutas de archivo no absolutas. Leyendo la página man de ld.so, imagino que es posible construir virus que manipulen archivos ejecutables ELF para añadirles una sección DT_RUNPATH. Todo se trata de poner imaginación.
#4 En realidad el hecho de que desde el año 2000 venga existiendo este problema (que ahora ha explotado en las manos de los chicos de Redmond) en posiblemente centenares de aplicaciones, e incluso, en muchas de las incluidas en el propio windows, como lo es MSTSC etc, no te da que pensar que existe un problema arquitectural en todo esto?
Uno podría argumentar entonces, que los sistemas operativos que tienen la pila ejecutable (muy peligroso!), no son culpables de los stack-based buffer overflow que explotan en las aplicaciones de terceros que corren.
#6 Te replanteo tu pregunta de otra manera: Hay cientos de aplicaciones de Windows que NO son vulnerables a este fallo porque sus programadores fueron lo suficientemente cuidadosos como para hacer las cosas bien. Si este problema es "del sistema operativo", ¿cómo explicas que esas aplicaciones sean seguras y no tengan ningún problema? ¿No deberían estar afectadas también, ya que el problema es de Windows, y no de las aplicaciones?
Microsoft, por supuesto, se declara culpable y se moja para intentar hacer algo, porque irremediablemente es la imagen de Windows la que recibe la paliza si un gran numero de programas de su plataforma tienen un problema, del mismo modo que cargan con la culpa de los pantallazos azules que en realidad son culpa de los malos programadores de drivers. Y no pueden intentar la opción radical de las modalidades de alta seguridad de Unix (desabilitar por completo las rutas relativas) porque si lo hicieran todos esos montones programas con fallo dejarían de funcionar correctamente.
#9 Desde mi punto de vista, lo que dices no es cierto.
Entiendo tu postura, sin embargo no estoy de acuerdo en que si yo desarrollo una arquitectura o tecnología compleja, que es muy fácil utilizarla mal, y crear agujeros de seguridad con ella, al final yo no sea culpable de nada.
Creo que con el tema de la carga de DLL, Microsoft ha cometido muchos errores desde el principio, que han llevado a numerosos agujeros de seguridad en cientos de aplicaciones en mas de una vez. Podríamos decir, que todas las veces, es por que la gente usaba mal la tecnología, pero no crees que la tecnología debería ser mas robusta? Debería disponer de medidas como las que AHORA empieza a plantear Microsoft tomar con el tema de las DLL?
Yo aquí veo una analogía, imagina un coche donde el volante, cogido de forma correcta es seguro, pero que es MUY fácil cogerlo mal, y al hacerlo, puedes sufrir un accidente. Al finalizar el año, podría salir un informe diciendo que ese coche, tiene muchos mas siniestros que todos los demás. ¿Podría decir la empresa que son los usuarios que cogen mal el volante?
Lo mismo podríamos decir del antennagate de apple. ¿Podemos decir que son los usuarios que cogen mal el iphone 4, o es el iphone 4 que es dado a ser cogido mal?
Y así un largo etcetera de ejemplos, que a mi modo de verlo, demuestran que es Microsoft quien ha puesto sobre la mesa una tecnología que ahora resulta insegura cuando es usada de determinadas maneras, por lo cual, es lógico que aunque la culpa no podamos nunca decir que sea 100% suya, ellos sufran las consecuencias.
O dicho de otra manera, aun mucho mas simple:
Tu dices que es lo mismo que dlopen, y yo te pregunto: está hoy la lista de seguridad de bugtraq llena de avisos sobre GNU/Linux y dlopen, o sobre Microsoft y DllHijacking? Puedes comprar tu mismo la respuesta y sacar tus propias conclusiones.
#10 Claro que puedo comprobarlo. He aquí dos fallos de seguridad en una base de datos para sistemas Unix que permiten acceder a root por un mal uso de dlopen(): http://www.artofhacking.com/tucops/hack/unix/live/aoh_bt410.htm http://www.artofhacking.com/tucops/hack/unix/live/aoh_bt411.htm . También se pueden rastrear CVEs relacionados con mal uso de dlopen: CVE-2008-3657, CVE-2009-3736, CVE-2007-6049
Aquí este señor http://www.nth-dimension.org.uk/blog.php?id=87 piensa que todos estos scripts también necesitan ser corregidos http://www.google.com/codesearch?q=LD_LIBRARY_PATH%3D%22%24LD_LIBRARY_PATH:
Aquí tienes la sección de seguridad de la documentación ld.so(1) en Solaris detallando las restricciones que se ponen a programas setuid y que en cambio se permiten a los programas no-setuid: http://docs.sun.com/app/docs/doc/816-5165/ld.so.1-1?l=en&a=view#Security
Aquí una página de recomendaciones de seguridad diciendo que dlopen() es vulnerable a problemas TOCTOU (time-of-check-to-time-of-use) y dando una serie de recomendaciones de uso https://buildsecurityin.us-cert.gov/bsi-rules/home/g1/734-BSI.html
#12 tu me citas un par de softwares que han usado mal dlopen.
Vale, ahora te cito yo un paper real sobre la vulnerabilidad de la que hablamos en windows:
http://www.exploit-db.com/papers/14813/
En la cual el propio autor dice:
Dll hijacking is the new hype on Windows exploiting. This vulnerability
is caused by a misbehavior practiced by all versions of Windows, as far
as I’m concerned. This misbehavior can be found explained in this MSDN
page (see Remarks). Note that many people consider this
flaw a feature and not a real bug because it was intended to be made this way
by Microsoft. I strongly disagree as I can’t think of a single legitimate
usage of a dll being loaded from the same directory of a opened file.
Para luego decir:
There are vulnerabilities in many major programs, so it’s possible to
bundle a dll with almost any filetype, like pdf, html, jpg, mp3, avi,
ANYTHING. Even some programs included with Windows are vulnerable. Peter
Eeckhoute from corelan team started an unofficial list that you might
want to check . You’re almost certainly using many
exploitable applications so it’s a must to check there if you use Windows
regardless of it’s version or edition.
Es decir, no solo hay un problema de diseño que ha llevado a cientos de programas (no 4 scriptillos cogidos con pinzas) de compañías millonarias a ser vulnerables de pronto y a la vez, sino que además algunos programas del propio windows, son vulnerables también.
Sobre #14 muy fácil, sacado del mismo paper:
This is a major security issue that affects every Windows version and
cannot be patched universally as it would break many existing
applications.
No es lo mismo un bug en wordpress que un bug en todas las versiones de windows, que afecta a cientos de programas de uso muy extendido, y que como consecuencia, ni se sabe como se va a parchear aún.
Para #14 y #12 y todos los que dicen que esto no es un bug en Windows:
http://msdn.microsoft.com/en-us/library/ms686203%28VS.85%29.aspx
[...]
After calling SetDllDirectory, the DLL search path is:
1. The directory from which the application loaded.
2. The directory specified by the lpPathName parameter.
[...]
Es el propio setdlldirectory, FUNCIÓN DE WINDOWS, la que tiene el problema
#15 Tu los has dicho, el problema es de Windows y no de las aplicaciones.
Esto es fruto de años de mal diseño.
Recomiendo la lectura de la segunda parte del articulo:
http://www.rooibo.com/2010/08/29/toda-la-verdad-sobre-dll-load-hijacking/
Prepárense para una orda de malware que ni el UAC y la mar en coche los va a salvar.
saludos
#4 La culpa es sin duda del SO de MicroSoft... o de todos los fabricantes de software menos de MicroSoft, tu elijes.
¿Y los datos para afirmar que Windows sea más inseguro hoy que hace diez años?
Ah, en ningún lado, es simplemente un titular llamativo.
http://z0r.de/483
#2 que tiempos aquellos!
Por cierto, leyendo otras entradas del blog, no entiendo porque no usa esa misma expresión para otros fallos de los que habla.
Lo fácil de usar sale caro
Vuelvan a Barrapunto, gilipollas