Portada
mis comunidades
otras secciones
#20:
#17 el error es un integer overflow:
http://en.wikipedia.org/wiki/Integer_overflow
Su explotación y riesgos está descrita en phrack 60:
http://www.phrack.org/archives/60/p60-0x0a.txt
Llegados a este punto sabemos que existe un agujero de seguridad en winsat.exe, que es una aplicación que a través del UAC, hereda los privilegios totales del usuario, por defecto root.
En windows vista, existe una separación root | usuarios, por defecto, tu usario es root, pero lo que ejecuta NO es root, sino que hereda privilegios limitados, es una de las features mas innovadoras de vista, según microsoft.
El problema reside en que si puedes tomar el control de un proceso que hereda privilegios completos del UAC, puedes usarlo como puente en tu aplicación, para escalar privilegios.
Lo que no entiendo es tanta confusión entorno a un concepto tan sencillo, de algo que se lleva haciendo años en linux, con los binarios suid.
Aparte de esto, en el correo digo que no estoy seguro por que como windows es closed source yo se que hay un bug, pero no puedo tener una idea precisa de como controlarlo para explotarlo.
Esto no significa que no exista un bug, significa que yo no tengo la información suficiente para continuar con esto, aun y sabiendo que hay bug.
Como nota histórica, el bug que aprovechaba el blaster, el rpc-dcom long filename buffer overflow, fue descubierto 8 meses antes, y enviado a bugtraq, pero no fue hasta 8 meses después, que alguien lo consiguió explotar.
Los bugs son bugs, y existen, aunque no los consigas explotar de antemano, tampoco hay que olvidar que el 90% de los bugs que leemos en listas de seguridad, nunca llegan a ser explotados, sino que se solucionan antes, para evitar que alguien descubra como hacerlo y que no haya parche, como pasó con el blaster.
http://en.wikipedia.org/wiki/Integer_overflow
Su explotación y riesgos está descrita en phrack 60:
http://www.phrack.org/archives/60/p60-0x0a.txt
Llegados a este punto sabemos que existe un agujero de seguridad en winsat.exe, que es una aplicación que a través del UAC, hereda los privilegios totales del usuario, por defecto root.
En windows vista, existe una separación root | usuarios, por defecto, tu usario es root, pero lo que ejecuta NO es root, sino que hereda privilegios limitados, es una de las features mas innovadoras de vista, según microsoft.
El problema reside en que si puedes tomar el control de un proceso que hereda privilegios completos del UAC, puedes usarlo como puente en tu aplicación, para escalar privilegios.
Lo que no entiendo es tanta confusión entorno a un concepto tan sencillo, de algo que se lleva haciendo años en linux, con los binarios suid.
Aparte de esto, en el correo digo que no estoy seguro por que como windows es closed source yo se que hay un bug, pero no puedo tener una idea precisa de como controlarlo para explotarlo.
Esto no significa que no exista un bug, significa que yo no tengo la información suficiente para continuar con esto, aun y sabiendo que hay bug.
Como nota histórica, el bug que aprovechaba el blaster, el rpc-dcom long filename buffer overflow, fue descubierto 8 meses antes, y enviado a bugtraq, pero no fue hasta 8 meses después, que alguien lo consiguió explotar.
Los bugs son bugs, y existen, aunque no los consigas explotar de antemano, tampoco hay que olvidar que el 90% de los bugs que leemos en listas de seguridad, nunca llegan a ser explotados, sino que se solucionan antes, para evitar que alguien descubra como hacerlo y que no haya parche, como pasó con el blaster.
#24:
#22 Creo que no lo entiendes... y voy a explicarlo un poco por encima poniendo un ejemplo, para que se entienda.
En ubuntu el usuario por defecto en la instalación, no es root, pero está en el /etc/sudoers, por lo que si quiere ejecutar algo como root, puede hacerlo usando sudo y proporcionando su contraseña.
En vista, es casi igual, la diferencia es que funciona un poco diferente, en vista el usuario por defecto es root, pero los procesos que ejecuta, no lo son, a menos que el proceso lo pida expresamente, cuando un proceso lo pide, sale en pantalla un aviso, con la empresa que firma el ejecutable, y su ruta.
De esta forma, si te aparece en pantalla que C:userspepitoDesktopmalware.exe quiere mas privilegios, tu le das a cancelar.
Esta arquitectura es correcta, no puedes conseguir que tu binario sea root, sino pasas antes por el usuario, preguntando, es algo muy similar al sudo que hacen las aplicaciones que requieren root en ubuntu, que saltan pidiendote la password, por ejemplo, al darle a configuración manual en la red.
El problema reside en que winsat.exe es parte de windows, está firmado por microsoft, está en C:windowssystem32 y encima es de los que están marcados para correr siempre con privilegios totales. (esto en linux se llama binario suid, aunque hay diferencias en como funciona)
Si tu pudieses tomar el control de ese proceso, podrías evadir toda esta historia, y ejecutar tu malware.exe, con privilegios totales.
Bien, aquí es donde entre en juego el bug.
Yo no he metido un número larguísimo y ha petado, puedes probar a meter otros números y verás que no peta te recomiendo 2^32/2+1, (lo cual ya no lo dejaría negativo) o 2^32/2-1 lo cual no lo llegaría a overflowear, si tienes dudas sobre si hay overflow, puedes comprobarlo con ollydbg http://www.ollydbg.de/ el debugger por excelencia en windows, si lo haces, verás como se arrasa el stack, la dirección de retorno, el framepointer...todo se sobreescribe con memoria.
Que memoria? es un poco relativo, son cosas del 3d, algunas las puedes controlar con los parametros de la aplicación, otras no.
Fijate a que extremo lo hemos llevado, tenemos un binario especial, que corre siempre como root, que es parte de windows, tenemos un bug, tenemos la prueba debuggeando de que es un bug e incluso sabemos como actua ese bug.
Lo único que falta es controlar algún argumento que nos permite colocar un dato arbitrario en el stack, y conseguir que coincida con la dirección de retorno sobrescrita, y creeme, esto sería mucho mas fácil si fuese de código abierto.
Pero no confundas, no es que haya puesto un numerito y haya petado, hay mucha ciencia detrás de estos bugs.
Y por favor, no confundas bug y exploit, mira:
http://www.securityfocus.com/archive/1/490263/30/0/threaded
http://www.securityfocus.com/archive/1/490176/30/0/threaded
Esos dos sin ir mas lejos, de hoy y ayer, no han sido explotados.
etc...etc... como digo, el 90% de los bugs de seguridad, aceptados como tal, nunca han sido explotados, no hay que confundir términos, una cosa es una brecha en la seguridad, y otra muy distinta es como aprovecharla.
En ubuntu el usuario por defecto en la instalación, no es root, pero está en el /etc/sudoers, por lo que si quiere ejecutar algo como root, puede hacerlo usando sudo y proporcionando su contraseña.
En vista, es casi igual, la diferencia es que funciona un poco diferente, en vista el usuario por defecto es root, pero los procesos que ejecuta, no lo son, a menos que el proceso lo pida expresamente, cuando un proceso lo pide, sale en pantalla un aviso, con la empresa que firma el ejecutable, y su ruta.
De esta forma, si te aparece en pantalla que C:userspepitoDesktopmalware.exe quiere mas privilegios, tu le das a cancelar.
Esta arquitectura es correcta, no puedes conseguir que tu binario sea root, sino pasas antes por el usuario, preguntando, es algo muy similar al sudo que hacen las aplicaciones que requieren root en ubuntu, que saltan pidiendote la password, por ejemplo, al darle a configuración manual en la red.
El problema reside en que winsat.exe es parte de windows, está firmado por microsoft, está en C:windowssystem32 y encima es de los que están marcados para correr siempre con privilegios totales. (esto en linux se llama binario suid, aunque hay diferencias en como funciona)
Si tu pudieses tomar el control de ese proceso, podrías evadir toda esta historia, y ejecutar tu malware.exe, con privilegios totales.
Bien, aquí es donde entre en juego el bug.
Yo no he metido un número larguísimo y ha petado, puedes probar a meter otros números y verás que no peta te recomiendo 2^32/2+1, (lo cual ya no lo dejaría negativo) o 2^32/2-1 lo cual no lo llegaría a overflowear, si tienes dudas sobre si hay overflow, puedes comprobarlo con ollydbg http://www.ollydbg.de/ el debugger por excelencia en windows, si lo haces, verás como se arrasa el stack, la dirección de retorno, el framepointer...todo se sobreescribe con memoria.
Que memoria? es un poco relativo, son cosas del 3d, algunas las puedes controlar con los parametros de la aplicación, otras no.
Fijate a que extremo lo hemos llevado, tenemos un binario especial, que corre siempre como root, que es parte de windows, tenemos un bug, tenemos la prueba debuggeando de que es un bug e incluso sabemos como actua ese bug.
Lo único que falta es controlar algún argumento que nos permite colocar un dato arbitrario en el stack, y conseguir que coincida con la dirección de retorno sobrescrita, y creeme, esto sería mucho mas fácil si fuese de código abierto.
Pero no confundas, no es que haya puesto un numerito y haya petado, hay mucha ciencia detrás de estos bugs.
Y por favor, no confundas bug y exploit, mira:
http://www.securityfocus.com/archive/1/490263/30/0/threaded
http://www.securityfocus.com/archive/1/490176/30/0/threaded
Esos dos sin ir mas lejos, de hoy y ayer, no han sido explotados.
etc...etc... como digo, el 90% de los bugs de seguridad, aceptados como tal, nunca han sido explotados, no hay que confundir términos, una cosa es una brecha en la seguridad, y otra muy distinta es como aprovecharla.
#7:
#1 Yo soy muy escéptico de este tipo de noticias a pesar de venir de quién viene (que nos encontró y solucionó problemas de seguridad bastantes complejos y rebuscados en el código del Menéame). A este problema ya lo conocía porque me lo comentó el mismo jcarlosn en cuanto lo descubrió, aún así sólo lo vote después de leer cuidadosamente su apunte.
El problema aquí no es que tenga un bug de seguridad, todo software más o menos complejo suele tenerlo, sino en cómo han tratado a este reporte en securityfocus a diferencia de otros que se explica en al apunte.
Esto es como el canon (en mi opinión), el problema no es que tengamos que pagar, sino el proceso por el cuál se decidió y quiénes son los que administran el dominio. En este caso el problema NO es el bug, sino en cómo tomaron decisiones en securityfocus.
¿Es infantil o conspiranoico preguntarse porqué para una empresa gorda son tan "así" y para productos libres son tan liberales de acpetar bugs que no lo son o que inlcuso no están demostrados que sea un bug?
El problema aquí no es que tenga un bug de seguridad, todo software más o menos complejo suele tenerlo, sino en cómo han tratado a este reporte en securityfocus a diferencia de otros que se explica en al apunte.
Esto es como el canon (en mi opinión), el problema no es que tengamos que pagar, sino el proceso por el cuál se decidió y quiénes son los que administran el dominio. En este caso el problema NO es el bug, sino en cómo tomaron decisiones en securityfocus.
¿Es infantil o conspiranoico preguntarse porqué para una empresa gorda son tan "así" y para productos libres son tan liberales de acpetar bugs que no lo son o que inlcuso no están demostrados que sea un bug?
#5:
Lo peor de todo, es que los bugs en productos de software libre se aceptan a discreción, sin importarle a nadie si son falsos (se los cuelan a diario) o si no son realmente bugs. Igual sucede con productos de apple, que llegan a ser publicados en la lista moderada, agujeros de seguridad inexistentes o muchísimo mas rebuscados que este.
Sin embargo, cuando es windows, entonces todo se mira con lupa, y a la mínima, se censura.
Dejando a un lado los flames, no tenemos certeza de cuantos agujeros mas se están censurando así, y luego microsoft dice que hay menos bugs en su software, que en los productos libres...
Sin embargo, cuando es windows, entonces todo se mira con lupa, y a la mínima, se censura.
Dejando a un lado los flames, no tenemos certeza de cuantos agujeros mas se están censurando así, y luego microsoft dice que hay menos bugs en su software, que en los productos libres...
Comentarios
#17 el error es un integer overflow:
http://en.wikipedia.org/wiki/Integer_overflow
Su explotación y riesgos está descrita en phrack 60:
http://www.phrack.org/archives/60/p60-0x0a.txt
Llegados a este punto sabemos que existe un agujero de seguridad en winsat.exe, que es una aplicación que a través del UAC, hereda los privilegios totales del usuario, por defecto root.
En windows vista, existe una separación root | usuarios, por defecto, tu usario es root, pero lo que ejecuta NO es root, sino que hereda privilegios limitados, es una de las features mas innovadoras de vista, según microsoft.
El problema reside en que si puedes tomar el control de un proceso que hereda privilegios completos del UAC, puedes usarlo como puente en tu aplicación, para escalar privilegios.
Lo que no entiendo es tanta confusión entorno a un concepto tan sencillo, de algo que se lleva haciendo años en linux, con los binarios suid.
Aparte de esto, en el correo digo que no estoy seguro por que como windows es closed source yo se que hay un bug, pero no puedo tener una idea precisa de como controlarlo para explotarlo.
Esto no significa que no exista un bug, significa que yo no tengo la información suficiente para continuar con esto, aun y sabiendo que hay bug.
Como nota histórica, el bug que aprovechaba el blaster, el rpc-dcom long filename buffer overflow, fue descubierto 8 meses antes, y enviado a bugtraq, pero no fue hasta 8 meses después, que alguien lo consiguió explotar.
Los bugs son bugs, y existen, aunque no los consigas explotar de antemano, tampoco hay que olvidar que el 90% de los bugs que leemos en listas de seguridad, nunca llegan a ser explotados, sino que se solucionan antes, para evitar que alguien descubra como hacerlo y que no haya parche, como pasó con el blaster.
#22 Creo que no lo entiendes... y voy a explicarlo un poco por encima poniendo un ejemplo, para que se entienda.
En ubuntu el usuario por defecto en la instalación, no es root, pero está en el /etc/sudoers, por lo que si quiere ejecutar algo como root, puede hacerlo usando sudo y proporcionando su contraseña.
En vista, es casi igual, la diferencia es que funciona un poco diferente, en vista el usuario por defecto es root, pero los procesos que ejecuta, no lo son, a menos que el proceso lo pida expresamente, cuando un proceso lo pide, sale en pantalla un aviso, con la empresa que firma el ejecutable, y su ruta.
De esta forma, si te aparece en pantalla que C:userspepitoDesktopmalware.exe quiere mas privilegios, tu le das a cancelar.
Esta arquitectura es correcta, no puedes conseguir que tu binario sea root, sino pasas antes por el usuario, preguntando, es algo muy similar al sudo que hacen las aplicaciones que requieren root en ubuntu, que saltan pidiendote la password, por ejemplo, al darle a configuración manual en la red.
El problema reside en que winsat.exe es parte de windows, está firmado por microsoft, está en C:windowssystem32 y encima es de los que están marcados para correr siempre con privilegios totales. (esto en linux se llama binario suid, aunque hay diferencias en como funciona)
Si tu pudieses tomar el control de ese proceso, podrías evadir toda esta historia, y ejecutar tu malware.exe, con privilegios totales.
Bien, aquí es donde entre en juego el bug.
Yo no he metido un número larguísimo y ha petado, puedes probar a meter otros números y verás que no peta te recomiendo 2^32/2+1, (lo cual ya no lo dejaría negativo) o 2^32/2-1 lo cual no lo llegaría a overflowear, si tienes dudas sobre si hay overflow, puedes comprobarlo con ollydbg http://www.ollydbg.de/ el debugger por excelencia en windows, si lo haces, verás como se arrasa el stack, la dirección de retorno, el framepointer...todo se sobreescribe con memoria.
Que memoria? es un poco relativo, son cosas del 3d, algunas las puedes controlar con los parametros de la aplicación, otras no.
Fijate a que extremo lo hemos llevado, tenemos un binario especial, que corre siempre como root, que es parte de windows, tenemos un bug, tenemos la prueba debuggeando de que es un bug e incluso sabemos como actua ese bug.
Lo único que falta es controlar algún argumento que nos permite colocar un dato arbitrario en el stack, y conseguir que coincida con la dirección de retorno sobrescrita, y creeme, esto sería mucho mas fácil si fuese de código abierto.
Pero no confundas, no es que haya puesto un numerito y haya petado, hay mucha ciencia detrás de estos bugs.
Y por favor, no confundas bug y exploit, mira:
http://www.securityfocus.com/archive/1/490263/30/0/threaded
http://www.securityfocus.com/archive/1/490176/30/0/threaded
Esos dos sin ir mas lejos, de hoy y ayer, no han sido explotados.
etc...etc... como digo, el 90% de los bugs de seguridad, aceptados como tal, nunca han sido explotados, no hay que confundir términos, una cosa es una brecha en la seguridad, y otra muy distinta es como aprovecharla.
#1 Yo soy muy escéptico de este tipo de noticias a pesar de venir de quién viene (que nos encontró y solucionó problemas de seguridad bastantes complejos y rebuscados en el código del Menéame). A este problema ya lo conocía porque me lo comentó el mismo jcarlosn en cuanto lo descubrió, aún así sólo lo vote después de leer cuidadosamente su apunte.
El problema aquí no es que tenga un bug de seguridad, todo software más o menos complejo suele tenerlo, sino en cómo han tratado a este reporte en securityfocus a diferencia de otros que se explica en al apunte.
Esto es como el canon (en mi opinión), el problema no es que tengamos que pagar, sino el proceso por el cuál se decidió y quiénes son los que administran el dominio. En este caso el problema NO es el bug, sino en cómo tomaron decisiones en securityfocus.
¿Es infantil o conspiranoico preguntarse porqué para una empresa gorda son tan "así" y para productos libres son tan liberales de acpetar bugs que no lo son o que inlcuso no están demostrados que sea un bug?
Lo peor de todo, es que los bugs en productos de software libre se aceptan a discreción, sin importarle a nadie si son falsos (se los cuelan a diario) o si no son realmente bugs. Igual sucede con productos de apple, que llegan a ser publicados en la lista moderada, agujeros de seguridad inexistentes o muchísimo mas rebuscados que este.
Sin embargo, cuando es windows, entonces todo se mira con lupa, y a la mínima, se censura.
Dejando a un lado los flames, no tenemos certeza de cuantos agujeros mas se están censurando así, y luego microsoft dice que hay menos bugs en su software, que en los productos libres...
Si? De verdad? ¿Y por qué iban a hacerlo?
#1 echa un ojo a la noticia y juzga por ti mismo.
Es un bug bastante grave (MUY grave), aunque no haya manera obvia de exploitearlo. Es vergonzoso es que se cause un overflow de una manera tan fácil para un programa que corre ¡como root!
#4 pero hombre, que era en tono irónico. Qué cabrones ajajaja, me habéis freido a negativos. ¿Arreglarlo no?
La clave aquí es que un bug en una aplicación relacionada con la seguridad del sistema, o en una aplicación con privilegios, es considerado un riesgo para la seguridad tanto si se conoce una forma de explotarlo como si no. En Linux. Solo hay que echar un vistazo y ver la cantidad de reportes donde dicen "podría ser explotado" en lugar de "puede ser explotado".
Por el contrario, como jcarlosn acaba de demostrar, en Windows no es suficiente con que una aplicación cualquiera pueda causar un error en un proceso con privilegios y pueda controlar la manera en que sobreescribe la memoria. Parece que es necesario que alguien descubra como explotarlo y distribuya un virus que infecte a medio mundo. Entonces sí tendremos un agujero de seguridad.
Para aclarar un poco todo lo que rodea al bug, cabe aclarar una cosa: en Windows vista, los usuarios son root por defecto, y el UAC separa los procesos que heredan los privileigos de root del usuario, y los que no. winsat.exe es una aplicación de las que se ejecutan con privilegios totales, por lo que alguien puede usar este bug para conseguir privilegios de root en su aplicación, sin pasar por el UAC.
Esto es un poco similar a los binarios suid en linux.
#17 lo que ocurre es que por mucho menos que eso, hay muchos errores publicados en securityfocus como bugs de seguridad cuando no lo son. En la entrada del blog tienes varios ejemplos.
#30 estoy totalmente de acuerdo, pero esto no lo podían mirar ellos, que tienen el código? es ahí a donde voy a parar yo.
De todas formas, no es esto motivo suficiente para no censurarlo, y que quien quiera lo investigue y se sepa el final? ahora seguro que no lo sabremos nunca.
A mi lo que me ofende es que si esto mismo hubiese sido en otro producto que no fuese de microsoft, como ya ha pasado en el pasado, no hubiese sido censurado en securityfocus, y mucha gente podría haberlo investigado, y se hubiese sacado una conclusión finalmente.
De todas formas, por lo que se ve en el debugger (miralo si tienes un rato) parece ser que ese indice se usa para reservar memoría, por lo que si sería peligroso.
#20 ese crash te permitirá ejecutar código si se usa para reservar un buffer. Pero un integer overflow no es prueba irrefutable de que es un fallo de seguridad. Tal vez el código de winsat lo que hace es:
for(int i=0;i
#27 La vulnerabilidad apareció muchísimo antes, por que os empeñais en mezclar el concepto vulnerabilidad con el concepto exploit?
#0: Y cuando llueve, caen gotas.
Perdón, creí que era un concurso de obviedades. Soy muy competitivo.
– Dr. Gregory House.
#31 Microsoft es tan tan tan tan grande que dudo que el tío que te ha respondido tenga acceso a ni una línea del código original sin pedir una autorización firmada por los mandamases. Ellos no han negado que haya un integer overflow, lo que te han pedido es que les dés un indicativo de porqué crees que el código es explotable. Si lo has probado con el OllyDbg, el IDA o con el propio debugger del Visual Studio y efectivamente, machaca la pila, te podrás pegar el gustazo de darle las pruebas al tipo de Microsoft. Intenta meter un shellcode en la línea de comandos (puedes sacar alguno de Metasploit) a ver qué pasa.
#23 La vulnerabilidad que explotaba Blaster llevaba semanas parcheada en Windows Update cuando apareció
http://en.wikipedia.org/wiki/Blaster_%28computer_worm%29
#35 el problema es que hay un paso entre saber que se está realizando un overflow en un buffer que puedes controlar de forma parcial, y conseguir encajar un dato arbitrario en la dirección que ocupaba la dirección de retorno.
Esto se complica ya muchísimo, lo máximo que le puedo dar a los de Microsoft es la prueba de que hay un buffer overfloweado como consecuencia del entero, y que se puede controlar parcialmente, pero sabes que? al final acabamos todos trabajando para microsoft, te cansas, lo envias a bugtraq para que lo sigan los demás, y te lo censuran, cuando bugs calcados a este, pero en preoductos de software libre, los aceptan a diario, ese es el punto del artículo.
Debo ser la única que no se ha enterado de nada, al menos de la parte técnica. Pero la historia de fondo queda bastante clara para los no iniciados. Hay que decirlo más...
¿Podría?
#32 me refería a que la vulnerabilidad estuvo en la calle mucho tiempo, hasta que la parchearon, otro tema es hablar concretamente del blaster, que es una explotación de dicha vulnerabilidad.
El titulo es ERRONEO.
La noticia es que securityfocus esta comprada por MS y no reportan (ni aceptan) bugs en productos de MS.
#33 Sí, tienes razón con lo de la vulnerabilidad. Pero yo no hablaba de eso. Yo respondía a las mentiras de #23
Que cosa rara, mira que me cuesta creerlo...
Pues como el virus Blaster. Al principio la vunerabilidad que explota este virus decían que no era grave y no la iban a solucionar, al cabo de 2 semanas se lió un jaleo en todo el mundo porque los ordenadores se infectarón solo por el hecho de estar conectados a Internet, y Microsoft tardo 1 semana en sacar un parche que no sirvió para nada, y 1 año en sacar el definitivo. Esperemos que esta vez no llegue tan lejos.
Y aún así hay gente que continua diciendo que nos quejamos de Microsoft por mania y que el software propietario es también bueno. en fin...
#29 ¿Lo cualo? Yo sólo digo que el parche para la vulnerabilidad que explotaba Blaster existía desde un mes antes de las primeras infecciones. ¿A qué te refieres?
#1: Imagino que se referirá a que se los oculten a la NSA, que es quien les encarga todos los demás.
Yo un día encontré un bug de seguridad gracias a los blogs de msn que era brutal. Avisé a Kriptópolis y a Microsoft porque me pareció que era muy grave.
Envié el enlace de mi blog a un conocido para que le echara un vistazo.
Entonces, como supongo que sabéis, en las estadísticas te sale quien te ha vistado y desde donde.
Pues resulta que al acceder esta persona a mi blog, en las estadísticas salía directamente el enlace vía webmail.
Me da por clicarlo y accedí directamente al correo de esta persona (evidentemente esta persona estaba con sesión abierta en su correo vía web).
Y tenía acceso completo a su correo.
Cabe decir que no me pude resistir y miré la agenda, jejejeje.
Pero como vi que era un error enorme avisé.
Aunque mis conocimientos de informática no me permitieron saber si era un bug en los blogs de msn, o en el correo vía web de esta persona.
Y cómo no va a tener grandes bugs si llevan vendiendo la misma porquería a la que le van añadiendo remiendos y lavándole la cara desde el win95 y encima lo venden a precio de nuevo.
#15
Pero no entiendo dónde está el agujero de seguridad.
El error que encuentras parece un error de una aplicación de sistema. Parece un bug, cierto pero no veo el problema de seguridad a priori.
Si alguien logra escalar prilegios en un sistema, ese es el fallo de seguridad.
Es como si en un sistema Linux dices que puedes llegar a ejecutar como root un determinado binario que puede ser un troyano.
Lo grave, es la escalación de privilegios. Un sistema seguro no debe permitir que un usuario acceda a permisos de superusuario.
Incluso lo reconoces en el correo: "I’m not sure if you can control some memory using other options in winsat.exe arguments to take advantage of this issue, and exploit it."
Vista es en si un agujero de seguridad
No me extrañaría NI UN PELO, están tratando de lavar la cara a esa chapuza con maquillaje rancio.
#44 el que fue hackeado en dos minutos fue Mac OSX, no Windows Vista.
#28 hay otros, pero como ha explicado el mismo jcarlosn si el sistema es de código cerrado te quedas en saber que el bug existe pero difícilmente lo puedes trazar. Por eso en los sistemas de código abierto con un control de configuración serio y un buen sistema de reporte de errores se pueden encontrar con mayor rapidez la solución a estos problemas. Si no, es cuestión de que alguien aburrido encuentre la manera de joder con el bug.
#8 Joder, es que si no pones la etiquetita de ironic la gente te funde tío.
Te echo una mano con un par de votos positivos.
Una notícia contra Microsoft ? karma asegurado
#18 Esos mismos no, pero habrá otros
En el comentario #10 hago referencia sobretodo a Bugs relacionados con el kernel Linux. Solo teneis que ir a http://www.securityfocus.com/bid seleccionar "Linux" y comparar sus descripciones con las referencias.
En securityfocus hace muchísimo tiempo que venden "vaporbugs". Son muchas veces las que me he alarmado al ver algún reporte y luego a la hora de la verdad, o el bug no existe o simplemente es imposible de explotar. Así que tendrían que pensárselo mil veces antes de llamar a un bug "Local privilege escalation".
#45 Bienvenido a la ironía y al sarcasmo.
Ya lo sabía, por eso lo puse . Me explico, a windows le criticamos hasta el fondo de pantalla pero los demás... los demás tienen carta blanca.
Dado esto no me extraña que windows vista fuese hackeado en dos minutos... y no haya pasado a la siguiente fase como los otros dos S.O. Mac y linux.
MacBook hackeado en 2 minutos
MacBook hackeado en 2 minutos
mundobip.comP.D: que curioso, el meneo anterior no ha salido a portada.
P.D2: http://eventos.barrapunto.com/article.pl?sid=08/03/28/1134238
#0 Me ha recordado a Canal 9, donde todos los futbolistas son de la comunidad valenciana, han jugado en la comunidad valenciana (o una vez se comió una paella)
La verdad es que en el bugtraq se comen casi cualquier cosa... que suene a esto es una bomba. Así que si hay exploit, de la chorrada más chorra, lo publican seguro. Que le de exposición al problema y, si se puede explotar, ya saltará algo.
Si lo ha descubierto él, tendrá crédito seguro.
Vamos a ver, no van a anunciarlos a viva voz. Es una obviedad que ocultan los agujeros, lo que nos interesa es que los solucionen antes de que se usen, no que los den a conocer.
Agujeros como estos...
#23
Puedes quejarte de Microsoft y de sus productos, pero ¿ qué tiene que ver el software cerrado ?.
Os recuerdo que el navegador Opera es cerrado y nadie lo considera un coladero.
Hay cientos de programas que no son de código abierto que son muy seguros.
Para expresar las ventajas del SL no hace falta atacar el software cerrado: creo que tiene cosas buenas por si mismo.
#7 Pero todo esto es normal en todo lo que tiene a Microsoft relacionado. Yo ya las noticias que hablan de estas cosas y Microsoft ni las voto.
#18 con linux hay otros
#20
Insisto: que haya un bug no significa que haya agujero de seguridad.
Tu equiparas bug con inseguridad y no siempre es así.
Tan sólo has probado a meter un entero 2147483648 y la aplicación ha fallado
Como bien dices, Windows Vista no es código abierto, así que no queda más remedio que lo echen un ojo los propios desarrolladores.
Que es un bug es evidente, pero parece ser que Microsoft no lo considera un fallo de seguridad.
Dices: "El problema reside en que si puedes tomar el control de un proceso que hereda privilegios completos del UAC, puedes usarlo como puente en tu aplicación, para escalar privilegios."
Desconozco como funciona Vista, pero en este caso, estas denunciando una mala arquitectura, no la escalacion de privilegios por una situación concreta de un bug en una aplicación concreta.
Miren a mi me parece que si lo miran con una lupa como dicen por acá y todos buscan los errores, de ultima el sistema se va haciendo mas fuerte en seguridad y prestaciones, como ha pasado con la version del Xp. de ultima Microsoft está cobrando por versiones beta y usandonos de tester sin decirnoslo.
Con Linux no hay esos problemas !!!