Cinco investigadores de la universidad Vrije (Holanda) han encontrado una grave vulnerabilidad en la protección ASLR. Esta protección sirve para evitar que un atacante ejecute código arbitrario en una maquina haciendo que los bloques de código y datos se carguen en direcciones aleatorias que impiden al atacante saber dónde está el código y ejecutarlo, sin embargo este nuevo ataque que afecta a Intel, AMD, ARM, Allwinner, Nvidia y otros es capaz de manera indirecta de averiguar las direcciones correctas donde el sistema ha cargado los datos.
![Rompen la protección ASLR contra el buffer-overflow con un código escrito en javascript [Eng]](https://cdn.mnmstatic.net/cache/29/bf/media_thumb_2x-link-2735977.jpeg?1487211907)
Comentarios
La "Universidad Vrije" no existe. Se puede escribir en su original en holandés "Vrije Universiteit" o su traducción al castellano "Universidad Libre de Ámsterdam", pero esa mezcla churrimerinesca es idiótica. https://es.wikipedia.org/wiki/Universidad_Libre_de_%C3%81msterdam
#1 Una vez, estando en Amberes, iba yo con mi colega de Interraíl y nos encontramos en una marquesina de un tranvía a un hombre en estado catatónico. Me ahorraré detalles, pero hubo un momento en el que no me quedó más remedio que llamar a emergencias y me preguntaron que dónde estaba. Yo dije "Amberes", pensando que ese era su único y original nombre. Me costó horrores hacerles entender que estaba en Antwerpen.
Para mí, el "enseñar" topónimos sin referenciar su nombre original me parece una aberración. Por eso, en mi opinión creo que "Universidad Vrije" no es peor que "Universidad Libre de Ámsterdam".
Dicho esto, en el artículo original pone Vrije University. ¿Le damos un pescozón por ser un churrimerino?
#66 Tampoco me gusta "Universidad Libre de Ámsterdam" pero es su nombre español, como pasa con Amberes. Y sí, el autor del artículo original se ha pasado de listillo con los de "Vrije University". Probablemente porque en su ignorancia pensó que Vrije era el nombre de un sitio, como Oxford. Pasa muy a menudo, pero no por eso es correcto.
En mi modesta opinión, la traducción se puede hacer entera o no hacerla (y ambas opciones son muy respetables), pero quedarse a medias causa confusión. Yo lo veo como si en inglés dijeran "University Rey John Carlos" o "University Pontificia".
#66 recuerdos desde Den Haag. Ahora vas y lo buscas
#1 Cuñado seal of approval.
#71 Teniendo tantos hermanos casados, es normal hacerse un poco el cuñao para presumir de mi inmarcesible legado cultural.
#72 Inmarcesible. Del lat. immarcescibĭlis.
1. adj. Que no se puede marchitar.
Es preciosa hasta en inglés: Unfathomable.
#5 No te has enterado, símplemente (es un decir) han conseguido evitar la protección ASLR, que evita buffer-overflow y por tanto ejecutar un programa alojado en una parte de la memoria que no debería ejecutarse, donde alguien puede haber introducido código malicioso.
Y lo han conseguido usando JavaScript, código que por defecto se ejecuta al cargar una web.
A si pues, si no configuras debidamente tu firewall-sys-internal con un protocolo ATPT redundante es posible que el almacenamiento del mainloop desencadene una serie de eventos de I/O que cargue la memoria condensada, ejecutando programas DLL sin la intervención de una butifarra inversa.
#11 se te ha roto el detector de sarcasmos
#18 A ti se te ha roto la butifarra inversa de #11
#26 reconozco que solo ley el principio de la primera linea
#5. Sabes que todo eso no es verdad...
Tio, que hay gente mayor que se cree esas cosas y luego no saben porque les da el mareo.
Personas mayores, el último párrafo de #11 tambien es mentira de la mala. La palabra 'butifarra' es muy sospechosa.
(CC #2)
#25 Me lo estaba imaginando
Saludos
#11 gracias por la aclaración!
#11 Gracias por la aclaración, realmente era necesario porque hay gente que al leer la mía han pensado "uy, parece cierto todo lo que dice".
¿Alguien que lo explique para neófitos...porfaplis?
Saludos
#2 La cosa es tan difícil que no hay ni gente haciendo chistes tontos.
#4 Yo lo entiendo perfectamente, pero me reservo mi opinión o cobro por ella como CEDRO.
#6 🐷
#4 Yo creo que se han inventado las palabras del título y os la han colado.
#8 #14 Gracias, ya mas o menos me ha quedado claro
#4 Totalmente cierto
#5 Estoooo...fao... he acabado mas perdido que con la entradila
#13 Si, yo también lo llevo de fabrica
Saludos
#2 el código anterior estaba escrito en C++ BR que es una compilación en Tin de lo que se usa para codificar códigos de kernel en braile.
No ha sido hasta ahora que han podido condensar el flow del Java en un over flow correcto en vez de un under-flow que le daba la vuelta a tu USB.
De tan contentos que se pusieron los científicos que lo han descubierto, acabaron pidiendo un Kebab en just eat y cuando llegó el repartidor, se fijaron que su moto era el mismísimo Albert Einstein.
#5
¿eso no se paliaba con el USB tipo-C que se puede insertar de ambos lados?
Por cierto, eso de Einstein es un bulo. Se sabe desde hace tiempo que era JC I, que paró antes de entregar la pizza a ayudar a un pavo a cambiar la rueda.
#2 básicamente es una manera de leer direcciones de memoria del equipo atacado mediante código javascritp incrustado en una pagina y poder ejecutar codigos complejos en la maquina atacada
#2. Amigos, amigos, amigos :
'...According to researchers, the only way users can protect themselves against AnC attacks is to deploy an extension like NoScript, which stops untrusted JavaScript code from running in the browser...'
Llevo usando ese plugin en Firefox desde hace años.
https://www.mozilla.org/es-ES/firefox/new/
https://addons.mozilla.org/en-US/firefox/addon/noscript/?src=hp-dl-mostpopular
#13 Y yo!
a veces toca los cojones porque al recargar una página pierdes algun dato o tienes que repetir un pago con visa. Pero la molestia es mínima.
Le falta que sincronice la configuración entre diferentes pcs, ya que yo cambio mucho y ando desbloqueando las mismas paginas en miles de pcs...
Para #2. Hoy en día cuando cargas una página web, a parte de lo que ves en pantalla, se cargan junto con la página una cantidad considerable de programitas pequeños para muchos temas, desde estadísticas hasta que un botoncito haga algo gracioso. Pues bien, algunos de esos programitas puede meterlos gente que sabe como tocarte las narices con las peores intenciones y según el artículo tu PC no puede defenderse ante ello.
Pero también dan la solución que apunto en #13, navegador Firefox + plugin NoScript. Con NoScript tú decides que programitas de esos carga una página web y que programitas no. En las páginas web de confianza, conocidas, no hay ningún problema. Pero si te da por visitar páginas poco conocidas o sospechosas simplemente deja de NoScript bloquee todos los scripts de la página web en cuestión.
El NoScript se instala con un click de ratón desde un navegador Firefox en el enlace en #13. Y el majísimo desarrollador acepta donaciones.
#20 Otra opción puede ser usar uMatrix (que se puede usar tanto con Firefox como Chrome). Si aún así se te pasa y dejas que se ejecute código javascript malicioso puede que te salve ejecutar el navegador dentro de un sandbox (por ejemplo firejail)
#31 ¿Alguna diferencia frente a uBlock Origin?
#36 Creo que parten del mismo codigo fuente, pero uBlock esta enfocado como un bloqueador de publicidad mientras que uMatrix para filtrar (tipo Noscript, pero para mi gusto con una interfaz mas eficiente, intuitiva y granular). De echo yo tengo instalados los dos.
#20 yo lo tuve instalado mucho tiempo y lo tuve que quitar porque terminé harto, pero para los que tienen más paciencia que yo es una buena medida de seguridad.
Para #32. Es solo cuestión de un poco de paciencia al principio de usarlo. Una vez tienes todas tus páginas habituales 'activadas' NoScript da muy pocos problemas y mucha seguridad. NoScript es diez mil veces mejor que cualquier antivirus comercial. Goto #29.
#34 cualquier cosa es mejor que un "antivirus comercial", que es una lacra. Yo uso GNU/Linux, pero aunque usara Windows no usaría esa basura. Casi prefiero que me infecten.
Lo que dices es práctico para la gente que entra siempre a las mismas páginas, pero yo soy mucho de navegar para acá y para allá y tenía que estar recargando las páginas constantemente porque en muchas no se puede ver el contenido. Al final terminaba desactivándolo temporalmente para descansar y llegó un momento en el que terminé desinstalándolo, pero reconozco que es un buen software.
#20 eso de que las conocidas ningun problema no es cierto porque la mayoria te hacen cargar codigo de terceras empresas directamente desde los servidores de estas.
Para #63. Los que no dejan de sorprenderme son los servidores de Microsoft. Cada dos por trés añaden scripts nuevos a sus páginas.
Pero vamos, que si nos ponemos piquismiquis nos hacemos nuestras propias web y nos las visitamos.
(CC #20)
Para #42. Excelente pregunta. Todos suelen tener nombres raros y en principio no se sabe lo que hacen. Este es mi criterio en caso de visitar una página nueva que no conozco.
(1) Cargar la página con todos los scripts desactivados.
(2) Si la página muestra correctamente el contenido usarla normalmente.
(3) Si la página merece confianza (o asumir el riesgo) y algo interactivo en ella no funciona se le dice a NoScript que acepte todo el javascript de la página. Entonces Noscript recarga la página y suele resultar que buena parte de los scripts cargados dependen de nuevos scripts por lo que en realidad no has cargado todos los scripts en ese momento, pero si la página te ofrece la funcionalidad que necesitas seguir el punto (2). Si no seguir el punto (3).
PD. Muchas veces puede deducirse que hace un código javascript activándolo-desactivándolo con NoScript y viendo como afecta a la página web.
(CC #29 #13)
Para #2. Goto #46.
#46 Jo, pero entonces esto no es simple de usar ni de lejos. Si no tienes conocimientos de programación nunca sabrás si un código es malicioso o no. Y si al final, para que la página funcione tengo que activar los scripts y ver si pasa algo raro, hacemos un pan con unas tortas.
Sinceramente, no lo acabo de ver claro salvo que seas programador.
Para #55. Pues NoScript no está pensado para programadores, esta pensado para el usuario medio, para evitar que tu máquina ejecute código sin tu consentimiento desde el navegador de Internet.
En #46 explico que activar todos los scripts de una página de hecho no suele acabar activando todos los scripts. Por lógica el 'malware' deben ponerlo es los últimos scripts de la carga de la página, algo más allá de las funcionalidades reales de la página web. No es seguro, pero es muy probable.
Además, si ves que una página desconocida te carga un millón y medio de scripts ya tienes información suficiente como para cerrarla y no volver a visitarla.
Si no utilizas noscript pero no te sales de las páginas web más conocidas no hay (en principio) ningún problema; pero si quieres tener buena parte del control de lo que sucede en tu PC entonces te recomiento el uso de noscript.
Para #55. Si no te gusta noscript no lo uses, pero por lo menos estas informado de los riesgos que se corren. Saludos.
#58 No lo he usado nunca. De hecho ni lo conocía. Pero como por aquí comentaban que era superfacil de usar e intuitivo pues me he decidido a probarlo.
Y me he encontrado con que para usar la herramienta no hacen falta conocimientos técnicos pero para decidir si cargar un script o no sí que hacen falta. Así que entre usar o no usar NOSCRIPT prácticamente me quedo igual porque jamás me daré cuenta de si un script que estoy habilitando es bueno o malo. Para mí los scripts es como si estuvieran en arameo coloquial: no entiendo nada de lo que hacen.
#60. Tampoco sabes como funciona internamente el navegador y eso no te impide usarlo correctamente. Pero lo dicho, no NoScript es también una opción válida.
#61 El navegador no me hace preguntas técnicas. Tiene una cajita donde meto una dirección (o ni eso porque puedo googlearla antes) y un botón de alante y otro de atrás. Noscript me pide que le diga si acepto ejecutar un script que está en un idioma que no conozco.
Hay una sutil diferencia.
No vendáis Noscript como algo fácil de usar cuando es una herramienta a todas luces destinada a usuarios con conocimientos técnicos.
#62 no es necesario que sepas intrepetar cada linea de codigo, con saber a que dominio quieres ir y bloquear unicamente el javascript que te intenta cargar desde otros dominios diferentes suele ser mas que suficiente para la mayoria de las paginas.
#60 Los que somos programadores no miramos el código para saber si un script es malo o bueno, entre otras cosas porque es inviable y no da tiempo, a ver si te crees que somos dioses o qué. Analizar código es mucho más difícil y lento que escribirlo.
Usamos el sentido común.
Si la página de la seguridad social necesita ejecutar un script, no corre riesgo y puedes habilitar la página entera para siempre.
Si en una página porno super chunga no se ve correctamente el vídeo, y hay tropecientos scripts que están bloqueados, vas buscando uno por uno a ver cuál de ellos es el que se encarga de ejecutar el vídeo.
Esto no se hace por conocimientos técnicos, sino haciendo deducciones en función de cómo se llaman los sitios bloqueados: superadnetwork.com te indica que es una red de publicidad (por la palabra "ad"). Lo mismo con la palabra "tracker", "campaign", "click" y cosas similares. Todos esos no puedes activarlos porque probablemente sean mierda. Esto no requiere conocimientos técnicos, sino inglés y sentido común.
En general suele funcionar buscar servidores que tengan "cdn" (Content Distribution Network) en el nombre y habilitarlos, ya que son los que suelen tener el contenido que quieres ver. Normalmente todo el resto es basura.
Para esto no hace falta tener concimientos técnicos, sino de inglés y un poco de sentido común (y en caso de duda, pasar de la página e irse a otro sitio).
Siempre puedes desbloquear la página entera sabiendo a lo que te expones, pero no es recomendable.
Decir que para esto necesitas conocimientos técnicos es lo mismo que decir que necesitas conocimientos técnicos para conducir un coche o cambiarle el aceite o una rueda pinchada. Nos ha jodido.
#74 Pero con esto que comentas sólo me aseguro de no tener anuncios. ¿Cómo sé si el código malicioso no está en uno de los que dejo? ¿Por el nombre del archivo? No creo que el hacker sea tan tonto como para poner en el nombre RoboTuDinero.js
Para saber que CDN es un archivo bueno sí que hace falta conocimientos técnicos. A las pruebas me remito: yo no los tengo y no tenía ni puta idea de que era bueno. Tú sí los tienes y sabías que era bueno sólo con verlo. Ahora has compartido tus conocimientos técnicos conmigo y yo también lo sé.
Lo mismo con palabras como click o tracker. ¿Cómo sé si no se limitan a controlar el click en los botones de la página para algo de la página o si van a ejecutar algo malicioso? ¿O si es un tracker (por el nombre supongo que será un rastreador de algún tipo) cómo sé que no necesita rastrear lo que hago para que funcione la página? No sé lo que es un tracker aunque pueda traducirlo al español. Campaign sí que parece más obvio.
#75 Sabemos lo mismo que tú, repito. No hay forma humana de analizar ese código porque eso llevaría días. Lo que se hace es probar a activar cosa por cosa hasta que das con lo que hace funcionar la página. Ni más ni menos. Los trucos se aprenden por experiencia ya que no hacemos ni conocemos esas páginas. Tú debes ser de los que creen que los infomráticos saben manejar cualquier programa por el hecho de ser informáticos.
Ni tú ni nadie (incluyendo nosotros) sabemos a priori lo que hay que activar o desactivar, ni sabemos si lo que activamos tiene trampa.
No ser estúpido y mover el culo para aprender en vez de quejarse también ayuda mucho. No lo uses si no quieres, es tu problema. No va a existir nada que lo automatice porque es algo que sólo alguien con sentido común puede hacer, no es algo que se pueda programar.
#55 tampoco hay que ser sheldon para sacarle partido, por ejemplo puedes activar el javascritp de la pagina que quieres ver pero seguir bloquando los javascripts que te carga desde servidores de terceras empresas de publicidad y tracking, que no suelen ser pocos por cierto.
#65 Wow. Buen consejo. ¡Gracias!
#46 Joder, después de todo lo que he leído de todos... acabo de actualizar curriculum
Saludos
#13 Coño!!! @.cocopino está a salvo de este problema. En el fondo eso de desactivar Js era cosa de sabios.
#13 La única dice... los usuarios del lynx no están de acuerdo. Ni los del links2, ni los del elinks, ni los de...
#2 Por lo que entiendo, este ataque se centra en la unidad de gestión de memoria (MMU) que se encarga de regular los accesos a memoria de la CPU. Mediante un ataque en javascript (es decir, que se puede ejecutar si entras en una página web maliciosa) pueden romper el ASLR (una protección que escribe memoria en zonas aleatorias para que el atacante no sepa dónde se guarda qué en memoria), permitiendo saber dónde se están guardando las cosas, por lo que se podrá sacar información de ella y utilizarlo para ejecutar exploits que les permitan acceder a todo el sistema operativo. Además esto da lugar a que exploits antiguos puedan estar de nuevo accesibles.
#2 Cuando querías entrar en un servidor, se ejecutaba contra el una larguisima peticion de datos maliciosa , con el fin que el comando que querías ejecutase se saltase la posicion de memoria del programa (donde sería rechazada) y penetrase en otra posicion donde sí funcionaría. Por ejm, si pides "abremeunasesion" te responderia NO , pero si envias algo del tipo "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXabremeunasesion" entonces, SI.
Como saber cuantas "X" hay que poner exactamente? pues leyendo el código y contando los bytes que hacen falta hasta alcanzar la posicion deseada.
Este sistema ASLR pone las partes del programa aleatoriamente en posiciones distintas, por lo cual es imposible saber nunca cuantas "X" habría que poner, y por lo tanto, el buffer oveflow es imposible de llevar a cabo.
Fuí hacker y programaba mis exploits en quickbasic 4.5
Para #2. No os desespereis con el NoScript. Recien instalado tienes que ir diciéndole que cargue si siempre los scripts de vuestras páginas web de confianza, las habituales como Google, Menéame, Gmail, etc. Si no lo haceis las páginas muestran parte del contenido pero pierden algunas o todas las funcionalidades.
Es muy, muy fácil de usar aunque esté en inglés. Le dais a la 'S' que aparece en alguna esquina del navegador y os sale un menu muy sencillo en el que cada rectangulo es un script a activar. Arriba del todo puedes seleccionar 'activar todos los scripts de esta página' y ya queda grabado. Cualquier cambio se puede deshacer con noScript, activar y desactivar en cualquier momento los scripts de cada página.
#29 ¿Y cómo sé qué scripts activar y cuales desactivar cuando visito una página nueva?
#42 empieza por bloquear los que se cargan desde dominios diferentes al que querias visitar, con esto ya te quitas todos los trackers que no es broma.
#2 Un procesador ejecuta las instrucciones de un programa que se alojan en la memoria. La MMU es una especie de controlador que ayuda a la CPU a encontrar las instrucciones que necesita en la parte de la memoria correspondiente. Si eres capaz de saber en qué parte de la memoria se está ejecutando un programa en ese momento, puedes introducir código malicioso en esa sección a través de un programa en ejecución (por ejemplo un navegador) y hacer que el procesador lo ejecute en vez del legítimo. De esa forma puedes controlar el PC de la víctima.
El ASLR es una técnica que consiste en utilizar direcciones de memoria aleatorias. Es decir, el código no se ejecuta de forma ordenada en las celdas de la memoria, sino que cada vez elige un lugar diferente. De esa forma no es tan fácil saber en qué parte de la memoria se está ejecutando.
Por lo que parece la MMU comparte información sobre esas direcciones aleatorias con algunos programas (como navegadores). Por lo tanto, se podría obtener información de las direcciones de memoria en donde se están ejecutando las instrucciones, introducir las tuyas propias y tomar el control del sistema. Una forma de acceder sería a través de Java Script, ya que es un lenguaje que se utiliza en muchas páginas web.
#2 Una de las formas de "atacar" un sistema, es enviarle un programa conseguir que se ejecute, haciendo lo que el atacante quiera.
Un programa, son datos que el procesador puede interpretar como instrucciones. Pero para que lo haga, algún otro programa tiene que saltar primero a la zona de memoria donde se han almacenado los datos que representan las instrucciones del siguiente programa.
Una de las formas de atacar un sistema, es enviarle unos datos que pueden ser interpretados como un programa, que serán guardados en alguna zona de memoria, y aprovechando algún fallo de algún programa que ya se esté ejecutando en el sistema y que permita pasar a ejecutar datos/instrucciones desde cualquier zona de memoria, solicitar la ejecución de las instrucciones contenidas en esos datos. Pero... para ello hace falta saber dónde en la memoria están esos datos.
Para ponerles las cosas difíciles a los atacantes, los sistemas operativos llevan tiempo incluyendo un mecanismo llamado ASLR que, aprovechando que las direcciones de memoria se traducen entre virtuales y físicas, lo que hace es asignar direcciones de memoria virtuales "más o menos aleatorias" a cada cacho de memoria que solicite un programa para guardar sus datos.
Un lenguaje como JavaScript, no tiene mecanismos propios para conocer la dirección de memoria exacta en la que se guardan los datos que maneja, lo cual unido al ASLR hace que un atacante que envía un programa a un navegador, no tenga forma de deducir la posición en la que están guardados esos datos, y por tanto no pueda usar ningún otro fallo para hacer que se ejecuten... HASTA AHORA.
Ahora, un atacante podrá enviar su programa al navegador de la víctima, donde quedará almacenado como datos en una zona aleatoria de memoria... y usando lo de esta noticia, podrá descubrir la posición de memoria exacta donde ha quedado almacenado, para aprovechando algún otro fallo que permita ejecutar desde cualquier zona de memoria, ejecutar su programa malicioso.
Para conseguirlo, han usado el "truco" de que los procesadores relativamente modernos incluyen un controlador de memoria con una caché, del cual han conseguido deducir los tiempos que se tarda en acceder a distintas posiciones de memoria y de ahí la posición de memoria de los datos que han almacenado en ella.
#2 No es algo fácil de explicar de manera más o menos completa sin asumir cierta base.
a) Los buffer overflows son vulnerabilidades de tipo:
Hay una variable, ya sea en memoria local ( pila ) o en memoria dinámica ( heap ) donde tengo un numero determinado de bytes de espacio. En un momento dado algo que viene del usuario, de un fichero, de una petición que una aplicación ( un navegador, por ejemplo ) hace a una librería o un módulo con mayores privilegios de ejecución ( más permisos, modo ring0 si es el kernel del sistema operativo, etc. ) se copia a esa variable y, por un error de comprobar el tamaño o carambolas como un error de cálculo en ese tamaño o lo que sea, lo que se copia a esa variable es de mayor tamaño que lo que se ha reservado para esa variable.
Así pues, se da ese desbordamiento de buffer. Bien, pues lo que ocurre, y aquí hay todo un abanico de posibilidades, es que al desbordar ese buffer, lo que se "pisa de más" acaba por alcanzar cosas críticas como por ejemplo una dirección de retorno a la función que llamó a esta función que tiene el fallo de desborde. Este es solo un ejemplo y se conoce como stack overflow. Stack o pila, por que el buffer overflow es de una variable local y las variables locales se almacenan en el marco de pila de la función ( cada función suele reservar un trozo de memoria decreciendo un puntero en un segmento de memoria que decrece -reserva un marco- según se van haciendo llamadas y vuelve a crecer -libera un marco- según se va volviendo de esas funciones ).
Luego estan los buffer overflows tipo heap overflow, que en vez de ser en variables locales es en variables dinámicas ( allocs, mallocs, allocs de pools de kernel, etc. ) y lo que se "pisa de más" suele ser la información de control que hay entre esas allocs... más largo, más difícil y más variado para explicar.
Bueno, pues hasta hace unos años, un buffer overflow se explotaba siguiendo estos pasos:
Hago ingeniería inversa del problema de una aplicación, servicio, kernel del sistema operativo o lo que sea "en casa" y veo en que posición de memoria esta esa variavble donde el tamaño no se controla y donde yo, con lo que le mando a ese módulo vulnerable, controlo lo que se copia.
Supongamos que es una web en un servidor y que esa web tiene un login donde no controlan la longitud de la password que introduzco. Y supongamos que, depurando en casa con un depurador, veo que esa password esta en la dirección de pila 0012F040 y que sé que el tamaño reservado para esa password es de 16 caracteres o bytes y que en la dirección 0012F060 esta la dirección de retorno a la función que llamo a la de hacer el login ( la que se esta ejecutando cuando nos pide la password y la que tiene el problema de no controlar que no introduzcamos más que 16 caracteres ). Pues bien, cuando algo así pasa, si tu introduces más caracteres que 16, generalmente el servicio ( la aplicación que sirve el puerto 80 en ese servidor ) casca y deja la pagina tonta durante un rato o tira la pagina abajo o se relanza ( hoy día sería lo normal ) o tal. Pero el tema es que casca. Lo que pasa es que, si yo pongo esos 16 caracteres, luego otros 16 de relleno y luego "algo" que justo queda encima de la dirección 0012F060 y pisando la dirección de retorno a la función que llamó a la función de hacer el login, consigo que, cuando la función de hacer login termine, no se vuelva a la dirección desde donde la función anterior nos llamó; como he machacado esa dirección con ese "algo", puedo hacer que el flujo del programa vaya a donde apunta ese "algo". Ese "algo" es una dirección que puede ser por ejemplo 0012F050 ( un poco más allá de 0012F040, donde yo he introducido la password y que puede ser lo que yo quiera, por ejemplo un poquito de código máquina para expandir una shell con su entrada/salida conectada a un puerto y a donde luego yo puedo hacer una conexión como atacante remoto o puede ser código para crearme un usuario en la base de datos o... cualquier cosa. A ese codiguillo se le conoce como "shellcode" por que los primeros exploits para estas vulnerabilidades eran código para crear una shell remota.
b) Visto esto, verás que hay una necesidad para el atacante que explota esa vulnerabilidad: tener cierto determinismo o conocimiento de las direcciones donde se carga esa variable no controlada en la pila ( o en el heap ). Además de esto, voy a omitir bastantes cosas como la protección que los procesadores de hace unos años aquí traen y que los sistemas operativos utilizan: la posibilidad de hacer que páginas de datos o de pila no sean ejecutables ( NX o W^X, No eXecute o Write es excluyente de eXecute; "lo que es escribible no es ejecutable" ) para evitar que ese "algo" salte a la pila donde yo he escrito la password ( y en la que he añadido código malicioso mio ) y ejecute cosas que deberías ser eso, datos, no código ejecutable.
Volviendo a esa necesidad de determinismo de DONDE están las cosas en la variable vulnerable o cosas como componentes del sistema operativo necesarias para el código inyectado, etc. Lo que se hace hoy día es aleatorizar las posiciones donde se ponen las cosas, sean pilas, sean módulos del sistema operativo, etc. Esto se hace para que yo no pueda extrapolar esas direcciones que yo veo cuando miro la vulnerabilidad "en casa" a otra máquina donde se ejecuta ese programa vulnerable. Esos 0012F040..0012F060 que te ponía en el ejemplo, por ejemplo, en otra máquina podrían ser 0083C240 o en esa misma máquina, 2 segundos más tarde, podrían ser 00013040.
ASLR viene de Address Space Layout Randomization: Aleatorización de la Disposición del Espacio de Direcciones. Vamos, que todo se reordena en cada ejecución, haciendo más dificil que haya un ataque exitoso cuando se intenta explotar una vulnerabilidad de estas ( y de otros tipos ).
c) Lo que esta gente ha hecho es, por así decirlo, espiar la actividad de memoria del kernel del sistema operativo, "mirar" donde ha ido accediendo el kernel del sistema operativo a base de medir tiempos de acceso y otras cosas que tienen que ver con la cache del procesador para ver por donde parece que ha habido accesos ( si un acceso anterior a X dirección se queda en cache, un futuro acceso a esa dirección tarda menos... ). Con esto sacan un mapa de direcciones y pueden "cocinar" esos datos que pasan a la función vulnerable del kernel, ya con direcciones que apuntan a sitios deterministas y asegurando o mejorando mucho la probabilidad de éxito del ataque.
Esto último, es mucho más complicado y hay que saber sobre la arquitectura de memoria virtual del procesador, como hace la paginación el sistema operativo, etc., pero bueno, quédate con la idea de que espiando al sistema operativo de una forma bastante indirecta, sacan información de donde se encuentran ciertas cosas del kernel del sistema operativo desde su codigo en javasript que se ejecuta en una aplicación con menos privilegios que el kernel del sistema operativo. Ese paso es previo a luego lanzar un ataque a una función vulnerable, y ya sabiendo donde están las cosas en memoria, para acabar tomando el control ( ejecutando un codiguillo que envían desde el navegador ) del kernel del sistema operativo. Lo que se llama una escalada de privilegios.
En cuanto a explotar el timming de los accesos y la cache para enviar datos de forma sigilosa/imparable o para descubrir pistas sobre la actividad de memoria de otros módulos, esta charla es muy buena, del 33avo Chaos Communication Congress de diciembre pasado. Va en la línea del tema y explica los conceptos bastante bien:
https://c3subtitles.de/talk/648/
#15, mira lo que he escrito en #41. Sé que es un poco largo ;( pero quizá te de una idea...
#44 Gracias lo miro
Para #41. Creo que deberias haber empezado aclarando que hablas desde el punto de vista de las internalidades del propio sistema operativo. Te ha quedado un texto bastante confuso para el lector medio (por lo avanzado que se te ve en el tema), en cualquier caso es un buen aporte.
#51 Sí, tienes razón no sé si es deformación profesional o que... y las frases son densas O:) Esto es mucho, mucho más fácil con una pizarra Gracias.
#2 Han encontrado una forma para que una web pueda entrar y acceder a tu ordenador.
#2 A ver si te lo puedo explicar de manera sencilla:
Uno de los ataques más usuales consiste en enviar a un equipo más datos de los que espera (buffer overflow). Si el programa no está bien hecho, esos datos que sobran pisan algo que ya estuviera en la memoria. El ataque se prepara de tal manera de sobreescribir algún programa con otro nuevo, forzando al equipo a ejecutar el código malicioso.
Obviamente la solución para esto es que los programas tengan en cuenta esta posibilidad y descarten los datos extra que les lleguen, pero evitar estas cosas lleva tiempo y esfuerzo y cuando el producto tiene que estar listo la semana que viene... el programador confía en que es ilegal atacar sistemas así que todo vendrá como tiene que venir y listo. Ya será después problema de otro...
Para mitigar este problema, Microsoft incorporó el ASLR, que lo que hace es colocar los datos en lugares aleatorios. De esta manera el atacante no puede saber donde va a quedar el programa que inyecte. O sea, que no evita que envíes un programa malicioso, pero al no saber donde fue a quedar, no puedes ejecutarlos.
Lo que dice la noticia es que han logrado mediante un simple javascript poder localizar esos datos, lo cual anularía la ventaja del ASLR dejando al sistema igual de expuesto que antes.
Las protecciones informáticas basadas en la aleatoriedad casi siempre son un coladero. Ya sea por la porque la función aleatoria no lo es en realidad o porque tienes que guardar registros accesibles de esos números "aleatorios" para manejar los procesos al final te la acaban colando.
Notician que merece estar en portada, sin duda va a ser un tema controvertido y que va a dar mucho que hablar a lo largo de la semana.
Se estan planeando incluso movilizaciones ciudadanas a modo de protesta.
Mi madre entra aquí y lee esto y se va haciendo la croqueta
"que un atacante ejecute código arbitrario en una maquina haciendo que los bloques de código y datos se carguen en direcciones aleatorias que impiden al atacante..." Se lo impide a si mismo? No lo entiendo...
#15, la frase es ambigua.
«haciendo que los bloques de código y datos se carguen en direcciones aleatorias que impiden al atacante saber dónde está el código y ejecutarlo» no es la descripción de lo que el atacante hace, sino de lo que la protección hace.
Creo, vaya.
#15
" Esta protección sirve para evitar que un atacante ejecute código arbitrario en una maquina "
---> habla de la protección
"haciendo que los bloques de código y datos se carguen en direcciones aleatorias que impiden al atacante saber dónde está el código y ejecutarlo, "
---> "haciendo" = La protección hace algo que impide al atacante...
(no es que el atacante ejecute algo haciendo no se qué... sino que la protección evita algo haciendo algo, es la protección la que lo hace)
Lo que dijo #23
pero lo he desmenuzado para que se vea más claro.
#15 Se refiere a "las direcciones".
#12 Es posible que puedas escribirte el código tú mismo, la idea parece bastante simple: https://www.vusec.net/projects/anc/
El que se hayan saltado la seguridad es algo que puede suceder, los sistemas tienen vulnerabilidades. Pero que lo haga un lenguaje interpretado de scripts como javascript, eso es una vergüenza. Es como si un bebé, con su pala de plástico, jugando dentro de una caja de arena, se saltara la seguridad de los sistemas de una nación entera, incluyendo los submarinos nucleares, sistemas antimisiles, satélites espías, etc.
Esto en Upday no sería portada
Pues que lo paguen. Quien rompe, paga.
Malditos. Siempre rompiendo cosas. No se os puede dejar nada bonito.
Despues de flash hay que acabar con javascript porque no es seguro.
https://translate.googleusercontent.com/translate_c?depth=1&hl=es&prev=search&rurl=translate.google.es&sl=en&sp=nmt4&u=https://www.vusec.net/projects/anc/&usg=ALkJrhiqgcRJigQU4AlSSK7KPdNWtQIVBg
y el source donde está? mi cpu está en la lista ...
No he entendido una puta mierda
#53 REsumiendo.. que hay mucha gente lista en el mundo y en lugar de arreglar los problemas que tenemos, contaminación, superpoblación, crisis por que no necesitamos tanta producción, etc. Se dedican a averiguar como sacarle el dinero a las tragaperras o como hacer que los cajeros escupan dinero sin meter la tarjeta.
Que seria del mundo sin los hackers...