Se ha detectado una vulnerabilidad en el kernel de Linux que permite escalar privilegios para conseguir acceso root, y que existe en el kernel desde hace 3 años. Algunas plataformas Android también están afectadas por el bug.
#23:
#1 Por mi experiencia profesional, de ya unos cuantos años, la respuesta del usuario típico de cada SO a una noticia de este tipo es:
- MacOS: pa que quieres saber eso jaja saludos
- Windows: yo ke se tio xd
- Linux: toca actualizar
He visto a fanboys de todo pelaje, pero nunca me he encontrado a ningún fanboy de Linux interesado en encubrir un fallo en el kernel para exculpar no sé muy bien el qué.
Aunque, para ser honesto, también debo reconocer que tampoco me he encontrado a muchos fanboys de MacOS o Windows... que supiesen lo que es un kernel...
#4:
Menos mal que linux sólo lo usan cuatro frikis pajilleros
Enviado desde mi Android
#30:
#21 Perdona, pero llevo diez años en esto y no he visto esa escena con GNU/Linux en la vida (y me he movido mucho). Tu estas confundiendo un administrador de sistemas que maneje GNU/Linux con soltura con un "cuñao de" coleccionista de PC Actual. No nos desviemos...
#14:
#9 Cuando se trata del kernel Linux, siempre es Linux. En este caso se trata de un bug en el kernel Linux; así que cualquier dispositivo que tenga instalado un kernel Linux 3.18 o versiones superiores, está afectado.
Cuando el fallo está en el núcleo, da igual como se llame el OS que use ese núcleo. No hay discusión en esto.
Otra cosa es cuando falla algún componente del OS Android y aparece alguien preguntando cosas como "Hoy Android no es Linux??".
Linux es el nombre de un núcleo que utilizan muchos sistemas operativos del tipo "UNIX".
Todo lo demás no es Linux, será "ponga aquí el nombre/Linux"; para indicar que usa el kernel Linux.
#57:
Al igual que ayer con el fallo de windows, vamos a intentar hacer una explicación sencilla por si alguien sin mucha experiencia quiere entender como funciona esto (gente con experiencia, no os lanzeis a mi cuello, este comentario no es para vosotros)
El kernel es dios, con poder para hacer cualquier cosa en nuestro sistema. Para poner un buen ejemplo en nuestra sociedad, digamos que el kernel es un banco. Como banco tiene un montón de trabajadores, dinero y similar. Una de las cosas que tiene son cajas de seguridad, muchas cajas de seguridad. El banco es bastante paranoico para evitar robos, por lo que no nos va a dejar entrar dentro de la zona segura del banco, ahi solo pueden entrar los trabajadores del mismo. Sin embargo, el banco pone a disposicion de los usuarios ciertos servicios. Uno de ellos (entre una multitud ingente) es almacenar tu carne del videoclub). Pero claro, el banco no te va a dejar entrar en la camara segura para recuperar el carné, lo que te dice es que tiene un empleado llamado Jose que es el que se encarga de traer y llevarte el carné.
Para ello, el banco coje una caja de seguridad (la 2237, por ejemplo) y la reserva para tu carne de videoclub y te da la llave de la caja que en su llavero pone el 2237. Mientras tanto, el banco apunta que esa caja esta ocupada y jose apunta en su libreta que tu tienes una copia de dicha llave. Cada vez que quieres ir al videoclub, solo tienes que ir al banco, avisar a jose, mostrarle la llave que apunta a la caja 2237 (mostrarle le basta, el banco tiene una llave maestra) y el amablemente te acompaña al videoclub para enseñar ahi tu carne y todo funciona. Si algun día quieres dejar de utilizar ese servicio, jose borra tu nombre de la libreta y el banco dice que la caja 2237 esta libre para usar por cualquiera de los otros trabajadors y servicios del banco
Ahora bien, esto es un engorro, no porque tengas que pasar por el banco antes de ir al videoclub, sino porque acabas de casarte y tu esposa también tiene un carne para el videoclub. Dado que los carnés son familiares, no necesitais dos, os vale con uno, por lo que decidís que a partir de ahora utilizareis el vuestro. Vais juntos al banco llamais a jose y se lo explicais. Tu mujer a partir de ahora no va a usar el carne que ella tenia guardado, sino el tuyo. Jose dice que no hay problema, le pide a tu señora que le devuelva la llave que ella tenía con su caja y le entrega una copia de la llave 2237. Adicionalmente, apunta en la libreta que ha entregado dos copias de dicha llave a clientes, por lo que hasta que no le devuelvan dos copias de la llave 2237, no puede avisar en el banco que la caja ya no está en uso.
El día de mañana podeis tener hijos que no hay problema, Jose se aburrira de entregar llaves, llevando la cuenta de cuantas ha entregado para saber cuando le han devuelto todas.
Ahora expliquemos como podemos engañar al banco. Yo, con mi copia de la llave 2237 voy a Jose y le digo que a partir de ahora no voy a usar la llave que tengo, sino que voy a utilizar la llave 2237. Jose te mira extrañado, ya que tu ya estas usando la llave 2237, pero intenta cumplir con su trabajo, pero comete un error. Aunque en principio a mi me ha dado una llave y me ha quitado una, en su libreta solo ha apuntado que me ha dado una llave. Esto puede tener un pequeño problema, posteriormente le devolvemos todas las llaves a Jose, segun su libreta no le salen las cuentas, todavía hay una llave en circulación, por lo que no se puede reutilizar esta caja. La llave no va a aparecer nunca, por lo que esa caja jamas quedará libre. Si Jose comete este error muchas veces, el banco puede empezar a tener problemas porque no le van a quedar cajas libres
Sin embargo, el problema es un poco más complejo. Ya hemos visto que Jose, aunque diligente, no es especialmente bueno con las matemáicas, especialmente con los numeros grandes. Jose solo sabe contar hasta un numero grande, pongamos 999 (la realidad es que jose cuenta hasta algo más de 4000 millones, que no esta mal, pero simplifiquemos a 999) Si en algun momento Jose ha entregado 999 llaves y entrega una más, como no es capaz de sumar más, anota en su libreta un cero. Más tarde, revisando la libreta, si ve que hay una caja para la que ha entregado cero llaves, eso significa que ya no esta en uso, por lo que puede avisar a direccion que la caja esta libre y que la pueden usar para cualquier cosa
Por lo tanto, podemos llegar a una situación un poco inesperada, si le pedimos a jose suficientes veces que nos cambie la llave de nuestra caja por una igual, Jose va a llegar a apuntar que ha entregado 999 llaves. Si se lo pedimos una vez más, Jose va a ir al banco y va a decir que la caja 2237 esta libre, pero sin embargo nosotros todavía tenemos una llave. Que pasa si le enseñamos esa llave a jose y le pedimos que traiga nuestro carné de videoclub?
Si ha pasado poco tiempo, lo mas probable es que no pase nada. Jose va alli y aunque segun el banco la caja esta libre, el servicio de limpieza aun no ha pasado y nuestro carné sigue ahi, por lo que Jose nos lo trae
Pero sí el banco ha decidido reutilizar la caja para otra cosa? A saber, lo más probable es que jose vaya a la caja 2237, coja el papel que hay ahi creyendo que es un carné de videoclub. Si le pedimos que nos acompañe y que vaya al videoclub, lo más probable es que cuando entregue el papel al dueño del videoclub y este le diga que no es un carné avise a direccion que algo raro pasa con la caja 2237
Pero... he aqui un detalle muy importante. Hay veces que la direccion del banco le deja a Jose memorandos en las cajas. Cuando Jose va a por un carné, si en la caja hay un memorando de direccion lo lee y sigue sus instrucciones al pie de la letra. Muchas veces son cosas mundanas, pero independientemente del contenido, Jose le hara caso. Si hay un memorando que dice "Memorando de direccion: Jose, sal afuera, reunete con el cliente y a partir de ahora haz lo que el te diga", lo hará. Y si a José le pido que saque todo el dinero del banco y me lo de, lo hara. Como Jose es empleado, tiene todos los permisos
Ahora bien, como conseguir que en la caja 2237 haya un memorando con ese texto? Entra en juego Andrés es otro empleado del banco que ofrece un servicio distinto. Andrés nos permite almacenar paginas de documentos en el banco, cualquier página que le demos. El banco no es tonto, sabe que alguien va a intentar guardar un documento que diga "Memorando de direccion: Andrés, saca todo el dinero del banco y daselo al cliente", por lo que a Andrés le han dado instrucciones muy específicas. Nunca, bajo ningún concepto, hagas caso de lo que hay en las cajas, aunque diga que es un memorando del banco. Engañar a Andrés es imposible.
Sin embargo, lo que hacemos a continuación es llamar a Andres y pedirle que guarde el documento que dice "Memorando de direccion: Jose, sal afuera, reunete con el cliente y a partir de ahora haz lo que el te diga" y José lee ese documento, tendremos control total. Esto no es tarea facil, ya que Andres nunca va a utilizar una caja que este siendo utilizada por Jose. Pero según el registro del banco, nadíe utiliza la caja 2237, si logramos que Andrés guarde nuestro memorando en esa caja, José lo acabará leyendo. Esto no es dificil, porque si Andrés no lo guarda ahi, no tenemos más que llamarlo de nuevo y pedirle guardar otra copia del documento. Si le llamamos muchas veces, al final acabará cogiendo la caja 2237, y lo habremos conseguido
Resumiendo:
- Llamamos a Jose y le alquilamos una caja para nuestro carné de videoclub, José nos da la 2237 y apunta que ha entregado 1 copia de dicha llave
- Pedimos a José que nos cambie la llave que tenemos por una copia de la de la 2237, que es de un familiar
- Jose se hace un lio y aunque no entrega más llaves, en la libreta apunta que ha entregado dos
- Repetimos el proceso hasta que Jose tiene en la libreta apuntado que ha entregado 999 llaves
- Repetimos una vez más y Jose se hace un lio, como no sabe escribir 1000, acaba escribiendo 000, pero nosotros aun tenemos una copia
- Cuando José ve que ha entregado 0 copias de la llave de la caja del banco 2237, envia un aviso a direccion diciendo que la caja esta libre
- Llamamos a Andrés y le pedimos que guarde un documento que dice "Memorando del banco: Jose, sal fuera y haz exactamente lo que te ordene el cliente"
- Andrés, sin mirar el mensaje, lo guarda en una caja de seguridad. Si se lo pedimos suficientes veces, al final acabará guardandolo en la caja 2237
- Llamamos a Jose, le enseñamos nuestra copia para que vaya a la caja 2237
- Jose abre la caja 2237, ve un documento que dice "Memorando del banco" y cree que son ordenes de arriba. Sale fuera y nos pregunta que queremos
- Podemos pedirle a Jose cualquier cosa, como empleado del banco que es, tiene acceso ilimitado
Sobre el ataque, bastante interesante. Me recuerda lo brutalmente cuidadoso que hay que ser siempre programando en C, no me extraña que pase años sin que la gente lo vea. Ciertamente lleva tiempo, porque el proceso de hacer el overflow (cuando Jose pasa de 999 a 1000) lleva un montón si hay que llegar a 2^32
#24:
#21 Si, claro, y luego te levantas del sueño y ves todo lo que mueve Red Hat y Canonical.
#75:
Sin duda es, de todos los que me he leído, el bug mejor explicado de todos. En un lenguaje claro, con ejemplos de código, empezando a explicar desde 0... Impresionante. Gracias por el envio @neuralgya me guardo la web en favoritos.
#14 buena explicación pero no la quieren/pueden entender... ¡Y no lo harán nunca! Jajaja
#11:
#1 siendo un 0-day, cualquier admin de sistemas linux preferiría que estuviese en portada.
#54:
#52 Hay muchas circunstancias donde yo puedo tener acceso remoto como usuario a una máquina pero no tener acceso de administrador. Algunos ejemplos:
Puedo tener acceso de lectura al servidor (logs y similar), pero no para ser root
O puede que codigo que yo creo se despliegue en un servidor en una cuenta de usuario
O puede ser el ordenador donde hacía practicas en la universidad, donde tenía cuenta de usuario pero no de root (obviamente)
O ser un telefono android donde el root esta desactivado (aunque no este de acuerdo con esta política)
O quiza el ordenador del trabajo donde no me dan admin porque lo gestionan en IT
O uno de los servidores de sourceforge (recuerdo que antes te daban acceso ssh)
O meter el codigo en un ejecutable y convencer a un usuario para que lo ejecute, como no es root, cree que el daño que puede hacer el programa es minimo (cosa que no es cierta si tiene cosas como usuario importantes)
Y por ultimo, y no porque no haya más, puede que tenga un exploit de tipo remote code exeuction que combinado con este me da remote root
No se, yo la lista la veo muy larga
#74:
#44 Si tengo, una chica que me limpia la casa y me hace la plancha 2 días a la semana
#55:
#52 Imagínate: servidor web, una cagada en algún .php que permita guardar un fichero php y llamarlo desde la web (como usuario "apache" probablemente), que descarga un exploit, que a su vez salta a usuario "root" y te manda una copia de las claves privadas del certificado SSL de la web hospedada en ese servidor para que puedas hacer phishing más a gusto, o que instale el rootkit que más te mole.
#5:
#3 No sólo ocurren en windows, Linux también tiene. Lo que pasa es que en linux se corrigen hoy y se descubren la semana que viene. Lo importante es el tiempo de reacción.
#9 parece que hay un 66% de androids afectados As of the date of disclosure, this vulnerability has implications for approximately tens of millions of Linux PCs and servers, and 66 percent of all Android devices (phones/tablets).
#19 Bueno, veo complicadillo que exploten este bug en Android, salvo que te instales tu mismo el exploit.... Una manera fácil de rootear el dispositivo?.... promete.
#19 Mis colegas se extrañan cuando me ven con un móvil BQ (el nuevo M5). Es precisamente por estas movidas por lo que lo compré, te aseguran 2 años de actualizaciones desde la salida del dispositivo, y son frecuentes.
Si no necesitara doble SIM habría pillado un Nexus, claro está.
#13#20 Me acordé de una vez que cierto software libre muy conocido corrigió un fallo horas antes incluso de ser descubierto, y todos aplaudieron la rapidez.
¿cómo? la gente muchas veces confunde la fecha de la noticia con la fecha real en la que los responsables conocieron el bug. Ese bug llevaría como un mes descubierto, lo único que ocurrió es que esperaron a que hubiese un parche antes de publicar la noticia, para evitar que explotaran el fallo.
Y con linux ocurre lo mismo, los comentarios que dicen "lo corrigieron en horas, ya puedo actualizar", las veces que me puse a mirar, había al menos una semana o dos que se conocía el bug, que sigue siendo rápido pero no "en horas".
#22 En cuanto a Android, la mitad de los teléfonos afectados ¿corregirá algún día ese fallo?
#9 Cuando se trata del kernel Linux, siempre es Linux. En este caso se trata de un bug en el kernel Linux; así que cualquier dispositivo que tenga instalado un kernel Linux 3.18 o versiones superiores, está afectado.
Cuando el fallo está en el núcleo, da igual como se llame el OS que use ese núcleo. No hay discusión en esto.
Otra cosa es cuando falla algún componente del OS Android y aparece alguien preguntando cosas como "Hoy Android no es Linux??".
Linux es el nombre de un núcleo que utilizan muchos sistemas operativos del tipo "UNIX".
Todo lo demás no es Linux, será "ponga aquí el nombre/Linux"; para indicar que usa el kernel Linux.
Sin duda es, de todos los que me he leído, el bug mejor explicado de todos. En un lenguaje claro, con ejemplos de código, empezando a explicar desde 0... Impresionante. Gracias por el envio@neuralgya me guardo la web en favoritos.
#14 buena explicación pero no la quieren/pueden entender... ¡Y no lo harán nunca! Jajaja
#21 Perdona, pero llevo diez años en esto y no he visto esa escena con GNU/Linux en la vida (y me he movido mucho). Tu estas confundiendo un administrador de sistemas que maneje GNU/Linux con soltura con un "cuñao de" coleccionista de PC Actual. No nos desviemos...
#30 Ehem, oye que no quiero seguir con la polémica, pero es que me los encuentro semana sí y otra nó, que no les cabe en la cabeza que su endiosado Debian les esté dejando tirados y que la sombra del paro les ponga histéricos y con malos modos.
#31 Pues chico, diles que se pongan las pilas y vayan a donde quieren contratar administradores de Debian. Que me parece que confundes "no quieren contratar" con "no quieren contratar linuxeros". Mira la que esta cayendo y aqui estoy, pegandome con Debian, JBoss y familia...
#34 vale, veo que eres un crack, ¿esa solución con la que estás "pegandote" está en un entorno de producción de una empresa donde si se cae puede perder mucha pasta? ¿es una institución académica o fundación?
Te contrato y te pago lo que no está escrito si me aseguras cero euros de perdidas con una solución sin soporte y en la que solo puedo confiar en tu capacidad.
#43 había entendido tu comentario al revés, entendí que insinuabas que con windows no era necesario ningún tipo de soporte para ofrecer confiabilidad. Estamos de acuerdo, ninguna opción sin soporte es adecuada para un entorno serio, a menos que tu equipo de sysadmins sea nivel Champion... Y ni así. De todas formas, linux también lo puedes encontrar con soporte, Redhat por ejemplo.
#36 En un gobierno autonómico, y hasta ahí puedo leer sin saltarme mi contrato.
Y si tienes una empresa con presupuesto de informática, eres un kamikaze si utilizas una solución con cero soporte, habiendo equivalentes con empresas detrás que te dan soporte. El problema no es meter GNU/Linux, el problema es meter un GNU/Linux cualquiera en lugar de uno que de soporte a empresas, que los hay y muchos. O contratar a un admin cualquiera en vez de uno con experiencia demostrada y/o certificaciones. Que los hay y muchos, pero no les puedes pagar con cacahuetes, claro... Españistan way of life, y todo eso.
#30 A lo que se refiere es que hay mucho converso advenedizo, de esos que son más radicales a la hora de defender Linux, pero luego su nivel como bien dices no pasa de Cuñao Google Avanzado.
Profesionales de Linux los hay de primera y curtidos en mil batallas.
#27 Si la empresa que tiene el problema tiene soporte activo con Microsoft, vamos a lo mismo $$$$, con un tiempo de respuesta decente, te puedo asegurar que se mueven muchos culos para solucionarlo.
#39 Pues mira que han publicado el código fuente y hay negocios con servidores windows a los que doy soporte, hasta ahora: cero problemas de este tipo reportados.
#28 Claro, el soporte de Microsoft lo dan seres de luz, no administradores estrella de esos que no saben administrar su sistema...
Linux es usado en la inmensa mayoría de los servidores de las mayores compañías del mundo porque sus jefes son unos frikis que están encantados de que sus servidores se caigan cada 20 minutos...
Deberías hablar con Larry Page y decirle que migren todo Google a Windows, que es un friki no sabe qué está haciendo.
#27 Los SLA de Red Hat valen una fortuna, se te ha ocurrido echarle un vistazo a los precios?
Lo de fallos que te obliguen a tumbar sistemas o dejarte los cuernos solucionándolos es un clásico hables del sistema que hables. Aún tengo frescas en la mente cagadas de Apache, OpenSSL y por supuesto un buen puñado en Windows Server.
Al igual que ayer con el fallo de windows, vamos a intentar hacer una explicación sencilla por si alguien sin mucha experiencia quiere entender como funciona esto (gente con experiencia, no os lanzeis a mi cuello, este comentario no es para vosotros)
El kernel es dios, con poder para hacer cualquier cosa en nuestro sistema. Para poner un buen ejemplo en nuestra sociedad, digamos que el kernel es un banco. Como banco tiene un montón de trabajadores, dinero y similar. Una de las cosas que tiene son cajas de seguridad, muchas cajas de seguridad. El banco es bastante paranoico para evitar robos, por lo que no nos va a dejar entrar dentro de la zona segura del banco, ahi solo pueden entrar los trabajadores del mismo. Sin embargo, el banco pone a disposicion de los usuarios ciertos servicios. Uno de ellos (entre una multitud ingente) es almacenar tu carne del videoclub). Pero claro, el banco no te va a dejar entrar en la camara segura para recuperar el carné, lo que te dice es que tiene un empleado llamado Jose que es el que se encarga de traer y llevarte el carné.
Para ello, el banco coje una caja de seguridad (la 2237, por ejemplo) y la reserva para tu carne de videoclub y te da la llave de la caja que en su llavero pone el 2237. Mientras tanto, el banco apunta que esa caja esta ocupada y jose apunta en su libreta que tu tienes una copia de dicha llave. Cada vez que quieres ir al videoclub, solo tienes que ir al banco, avisar a jose, mostrarle la llave que apunta a la caja 2237 (mostrarle le basta, el banco tiene una llave maestra) y el amablemente te acompaña al videoclub para enseñar ahi tu carne y todo funciona. Si algun día quieres dejar de utilizar ese servicio, jose borra tu nombre de la libreta y el banco dice que la caja 2237 esta libre para usar por cualquiera de los otros trabajadors y servicios del banco
Ahora bien, esto es un engorro, no porque tengas que pasar por el banco antes de ir al videoclub, sino porque acabas de casarte y tu esposa también tiene un carne para el videoclub. Dado que los carnés son familiares, no necesitais dos, os vale con uno, por lo que decidís que a partir de ahora utilizareis el vuestro. Vais juntos al banco llamais a jose y se lo explicais. Tu mujer a partir de ahora no va a usar el carne que ella tenia guardado, sino el tuyo. Jose dice que no hay problema, le pide a tu señora que le devuelva la llave que ella tenía con su caja y le entrega una copia de la llave 2237. Adicionalmente, apunta en la libreta que ha entregado dos copias de dicha llave a clientes, por lo que hasta que no le devuelvan dos copias de la llave 2237, no puede avisar en el banco que la caja ya no está en uso.
El día de mañana podeis tener hijos que no hay problema, Jose se aburrira de entregar llaves, llevando la cuenta de cuantas ha entregado para saber cuando le han devuelto todas.
Ahora expliquemos como podemos engañar al banco. Yo, con mi copia de la llave 2237 voy a Jose y le digo que a partir de ahora no voy a usar la llave que tengo, sino que voy a utilizar la llave 2237. Jose te mira extrañado, ya que tu ya estas usando la llave 2237, pero intenta cumplir con su trabajo, pero comete un error. Aunque en principio a mi me ha dado una llave y me ha quitado una, en su libreta solo ha apuntado que me ha dado una llave. Esto puede tener un pequeño problema, posteriormente le devolvemos todas las llaves a Jose, segun su libreta no le salen las cuentas, todavía hay una llave en circulación, por lo que no se puede reutilizar esta caja. La llave no va a aparecer nunca, por lo que esa caja jamas quedará libre. Si Jose comete este error muchas veces, el banco puede empezar a tener problemas porque no le van a quedar cajas libres
Sin embargo, el problema es un poco más complejo. Ya hemos visto que Jose, aunque diligente, no es especialmente bueno con las matemáicas, especialmente con los numeros grandes. Jose solo sabe contar hasta un numero grande, pongamos 999 (la realidad es que jose cuenta hasta algo más de 4000 millones, que no esta mal, pero simplifiquemos a 999) Si en algun momento Jose ha entregado 999 llaves y entrega una más, como no es capaz de sumar más, anota en su libreta un cero. Más tarde, revisando la libreta, si ve que hay una caja para la que ha entregado cero llaves, eso significa que ya no esta en uso, por lo que puede avisar a direccion que la caja esta libre y que la pueden usar para cualquier cosa
Por lo tanto, podemos llegar a una situación un poco inesperada, si le pedimos a jose suficientes veces que nos cambie la llave de nuestra caja por una igual, Jose va a llegar a apuntar que ha entregado 999 llaves. Si se lo pedimos una vez más, Jose va a ir al banco y va a decir que la caja 2237 esta libre, pero sin embargo nosotros todavía tenemos una llave. Que pasa si le enseñamos esa llave a jose y le pedimos que traiga nuestro carné de videoclub?
Si ha pasado poco tiempo, lo mas probable es que no pase nada. Jose va alli y aunque segun el banco la caja esta libre, el servicio de limpieza aun no ha pasado y nuestro carné sigue ahi, por lo que Jose nos lo trae
Pero sí el banco ha decidido reutilizar la caja para otra cosa? A saber, lo más probable es que jose vaya a la caja 2237, coja el papel que hay ahi creyendo que es un carné de videoclub. Si le pedimos que nos acompañe y que vaya al videoclub, lo más probable es que cuando entregue el papel al dueño del videoclub y este le diga que no es un carné avise a direccion que algo raro pasa con la caja 2237
Pero... he aqui un detalle muy importante. Hay veces que la direccion del banco le deja a Jose memorandos en las cajas. Cuando Jose va a por un carné, si en la caja hay un memorando de direccion lo lee y sigue sus instrucciones al pie de la letra. Muchas veces son cosas mundanas, pero independientemente del contenido, Jose le hara caso. Si hay un memorando que dice "Memorando de direccion: Jose, sal afuera, reunete con el cliente y a partir de ahora haz lo que el te diga", lo hará. Y si a José le pido que saque todo el dinero del banco y me lo de, lo hara. Como Jose es empleado, tiene todos los permisos
Ahora bien, como conseguir que en la caja 2237 haya un memorando con ese texto? Entra en juego Andrés es otro empleado del banco que ofrece un servicio distinto. Andrés nos permite almacenar paginas de documentos en el banco, cualquier página que le demos. El banco no es tonto, sabe que alguien va a intentar guardar un documento que diga "Memorando de direccion: Andrés, saca todo el dinero del banco y daselo al cliente", por lo que a Andrés le han dado instrucciones muy específicas. Nunca, bajo ningún concepto, hagas caso de lo que hay en las cajas, aunque diga que es un memorando del banco. Engañar a Andrés es imposible.
Sin embargo, lo que hacemos a continuación es llamar a Andres y pedirle que guarde el documento que dice "Memorando de direccion: Jose, sal afuera, reunete con el cliente y a partir de ahora haz lo que el te diga" y José lee ese documento, tendremos control total. Esto no es tarea facil, ya que Andres nunca va a utilizar una caja que este siendo utilizada por Jose. Pero según el registro del banco, nadíe utiliza la caja 2237, si logramos que Andrés guarde nuestro memorando en esa caja, José lo acabará leyendo. Esto no es dificil, porque si Andrés no lo guarda ahi, no tenemos más que llamarlo de nuevo y pedirle guardar otra copia del documento. Si le llamamos muchas veces, al final acabará cogiendo la caja 2237, y lo habremos conseguido
Resumiendo:
- Llamamos a Jose y le alquilamos una caja para nuestro carné de videoclub, José nos da la 2237 y apunta que ha entregado 1 copia de dicha llave
- Pedimos a José que nos cambie la llave que tenemos por una copia de la de la 2237, que es de un familiar
- Jose se hace un lio y aunque no entrega más llaves, en la libreta apunta que ha entregado dos
- Repetimos el proceso hasta que Jose tiene en la libreta apuntado que ha entregado 999 llaves
- Repetimos una vez más y Jose se hace un lio, como no sabe escribir 1000, acaba escribiendo 000, pero nosotros aun tenemos una copia
- Cuando José ve que ha entregado 0 copias de la llave de la caja del banco 2237, envia un aviso a direccion diciendo que la caja esta libre
- Llamamos a Andrés y le pedimos que guarde un documento que dice "Memorando del banco: Jose, sal fuera y haz exactamente lo que te ordene el cliente"
- Andrés, sin mirar el mensaje, lo guarda en una caja de seguridad. Si se lo pedimos suficientes veces, al final acabará guardandolo en la caja 2237
- Llamamos a Jose, le enseñamos nuestra copia para que vaya a la caja 2237
- Jose abre la caja 2237, ve un documento que dice "Memorando del banco" y cree que son ordenes de arriba. Sale fuera y nos pregunta que queremos
- Podemos pedirle a Jose cualquier cosa, como empleado del banco que es, tiene acceso ilimitado
Sobre el ataque, bastante interesante. Me recuerda lo brutalmente cuidadoso que hay que ser siempre programando en C, no me extraña que pase años sin que la gente lo vea. Ciertamente lleva tiempo, porque el proceso de hacer el overflow (cuando Jose pasa de 999 a 1000) lleva un montón si hay que llegar a 2^32
#3 No sólo ocurren en windows, Linux también tiene. Lo que pasa es que en linux se corrigen hoy y se descubren la semana que viene. Lo importante es el tiempo de reacción.
#13 Llega el nuevo friki administrador linux, revoluciona toda la empresa instalando software libre, el gerente impresionado con la cantidad de pasta que se está ahorrando.. Llega el fatídico día que los servidores al unísono empiezan a pegar petes cada 20 minutos, el administrador estrella no consigue solucionarlos, su plan de reinstalación tampoco.. pasan los dias y no se soluciona. El administrador ya no encuentra foros GNU donde no haya enviado los logs, no hay respuesta.. Viendo las perdidas de la empresa el gerente contrata otro administrador, nada, y otro menos..
GNU/linux la tumba de muchos administradores del sector profesional
#21 Hombre... en toda mi vida profesional los servidores mas estables que he visto son precisamente los servidores Linux, eso si, distribuciones serias con un equipo de soporte competente detrás. Está claro que si pones a un becario sin experiencia como administrador de sistemas el ostión está practicamente asegurado, pero esto pasa con cualquier cosa, lo dices como si un Windows Server se administrase solo...
#5
En Windows es habitual que si se hace público un bug, el parche o está en camino o ya se puede descargar. Bugs más complejos pueden tardar tiempo en corregirse, y eso es así en Linux, MacOS, Windows y el sistema que sea.
#1 Por mi experiencia profesional, de ya unos cuantos años, la respuesta del usuario típico de cada SO a una noticia de este tipo es:
- MacOS: pa que quieres saber eso jaja saludos
- Windows: yo ke se tio xd
- Linux: toca actualizar
He visto a fanboys de todo pelaje, pero nunca me he encontrado a ningún fanboy de Linux interesado en encubrir un fallo en el kernel para exculpar no sé muy bien el qué.
Aunque, para ser honesto, también debo reconocer que tampoco me he encontrado a muchos fanboys de MacOS o Windows... que supiesen lo que es un kernel...
#35 Apple lleva dando gratis actualizaciones mayores de OSX desde hace 4 o 5 años, de hecho fue el primer SO privativo que lo hizo... pero de algun topico hay que tirar para criticar a OSX, ya que tecnicamente es dificil, pues es un sistema unix cojonudo.
#23 Cuando el usuario que opina tiene conocimientos técnicos o es al menos administrador de sistemas (de los de verdad, de los que viven de eso), no se suele tomar posición de fanboy. Y ni de coña encubren bugs con no se sabe qué oscuros intereses.
#90 De ahi que hablase del usuario medio. Aunque no puedo negar cierto apetito por el flame
Más allá de consideraciones técnicas, que en muchos casos suelen derivar en estériles polémicas entre fanboys, es innegable que el usuario medio de Linux conoce mucho mejor su SO y está más implicado a la hora de reportar bugs. Lo cual hace que sus sistemas suelan estar mucho más actualizados y por tanto sean más seguros.
Obviamente todo esto deja de aplicarse en un sistema concreto basado en Linux: Android. Ya que muchos frabricantes no proporcionan las actualizaciones necesarias para sus dispositivos y, aún siendo el caso, muchos usuarios simplemente no las instalan.
#23 Yo todavía estoy esperando ver a un usuario de linux que no demuestre su absoluta ignorancia cuando habla de Windows. Y llevo unos cuantos años ya.
#1 Esa es la pequeña diferencia entre el software abierto y el cerrado,en el software abierto se publican los fallos para encontrar soluciones y en el software cerrado las empresas ocultan sus bugs hasta que se hacen demasiado evidente.
Para explotar esa vulnerabilidad tienes que tener acceso físico al sistema y además que estén instaladas las herramientas de compilación. Es bueno tener instalado solamente el software que necesitas y cuanto menos software tengas instalado más seguro será el sistema. Si no piensas compilar nada, si solamente usas los binarios oficiales que vienen en tu distribución, no es necesario que tengas instalado los paquetes necesarios para hacer la compilación, no necesitas añadir paquetes.dev, etc.
Me parece recordar que una vez hubo un caso parecido, un programa en C que lo compilabas y luego podías acceder a root por la cara, pero si no tienes acceso físico a la máquina ni están instaladas las herramientas de compilación, a ver como coño lo haces.
Cada vez que se encuentra una vulnerabilidad en Linux más seguro y más robusto se hace el sistema porque en cuestión de horas la comunidad publica el correspondiente parche, no como hacen en Windows que esconden la mierda debajo de la alfombra para que sus clientes no la vea.
#17Para explotar esa vulnerabilidad tienes que tener acceso físico al sistema y además que estén instaladas las herramientas de compilación.
No solo eso, ese acceso a la máquina tiene que ser largo si le máquina tiene uno de los últimos modelos de microprocesador i7, el atacante necesita media hora!!
#17 acabo de leer el parche, no termino de entender tu comentario
Efectivamente, necesitas tener acceso al sistema, pero no veo por que no puedes hacerlo con un acceso remoto
Segundo, tampoco veo para que necesitas compilar el exploit en la maquina objetivo. Lo compilas en otro lado y copias el binario
Mañana si tengo tiempo analizare el problema en detalle
#52 Hay muchas circunstancias donde yo puedo tener acceso remoto como usuario a una máquina pero no tener acceso de administrador. Algunos ejemplos:
Puedo tener acceso de lectura al servidor (logs y similar), pero no para ser root
O puede que codigo que yo creo se despliegue en un servidor en una cuenta de usuario
O puede ser el ordenador donde hacía practicas en la universidad, donde tenía cuenta de usuario pero no de root (obviamente)
O ser un telefono android donde el root esta desactivado (aunque no este de acuerdo con esta política)
O quiza el ordenador del trabajo donde no me dan admin porque lo gestionan en IT
O uno de los servidores de sourceforge (recuerdo que antes te daban acceso ssh)
O meter el codigo en un ejecutable y convencer a un usuario para que lo ejecute, como no es root, cree que el daño que puede hacer el programa es minimo (cosa que no es cierta si tiene cosas como usuario importantes)
Y por ultimo, y no porque no haya más, puede que tenga un exploit de tipo remote code exeuction que combinado con este me da remote root
No se, yo la lista la veo muy larga
#54 Tal ves sea por mi corta experiencia, pero sigo sin entender porque dar acceso al sistema operativo a un usuario (en el caso de servidores), si es para ver reportes se puede enviar a un correo o verlo a través de una página diseñada para tal propósito.
En el extremo de necesitarlo (como ser pobre y no tener un servidor para cada cosa) dar permiso para escritura y lectura en algunas carpetas para imágenes documentos y demás, sin embargo se puede hacer lo mismo a través de un servidor web bien configurado.
#52 Imagínate: servidor web, una cagada en algún .php que permita guardar un fichero php y llamarlo desde la web (como usuario "apache" probablemente), que descarga un exploit, que a su vez salta a usuario "root" y te manda una copia de las claves privadas del certificado SSL de la web hospedada en ese servidor para que puedas hacer phishing más a gusto, o que instale el rootkit que más te mole.
#55 basicamen hoy menos del 0.1% de los servidores tienen abierto llamadas de sistema desde php.
Basicamente estamos hablando de expltar una vulnerabilidad desde otra vulnerabilidad
#56 ¿Llamadas de sistema? Nada de llamadas de sistema, con un simple exec desde un php controlado por el atacante basta y sobra.
De lo que estamos hablando es de tomar el control completo del sistema, explotable desde cualquier descuido chorra.
#59 Con llamada a sistema me refieron a Exec y system. Bienen por defecto bloqueados en todas las configuraciones de produccion y habilitarlo sin control alguno ya es un problema de seguridad por si solo, considerando que ademas deberia tener otra vulnerabilidad para subir archivos php, estamos hablando de algo que por si puede liarla en el servidor.
Mas el fallo que se describe hablamos que deben haber 3 vulnerabilidades en el sevidor, algo extremadamente raro hoy en 2016
#52 me parece lo más normal del mundo tener acceso no-root remoto a un servidor Linux. De hecho es root quien suele tener restringido el acceso remoto.
Si "solo los admin" deberían acceder, qué gracia tiene tener un sistema de red multi-usuario.
#72 hay más tipos de servicios que la web, para los que se requiere acceso ssh.
Incluso en web, muchos servicios de hosting dan acceso ssh.
Pero no sólo existen servidores para páginas web. En mi empresa por ejemplo el servidor linux local precisamente lo que no sirve es web, sirve cuentas ssh que se usan en un 90% para compilar código.
Vamos, que hay vida más allá del hosting web pelado sin ssh ni nada.
#78 lo que quieres es una configuración posible, pero limitada en funcionalidad.
En mi caso se quedaría corto, yo tengo scripts entre mi servidor local y el servidor remoto vía ssh para gestionar la web y la bdd sql.
#17 solo necesito tener acceso a una shell, por ejemplo ssh.
Que no esten las herramientas de compilación me la sopla, compilo en mi pc y lo ejecuto en remoto.
solo necesita las librerias : ldd cve_2016_0728
linux-vdso.so.1 (0x00007ffeda3cb000)
libkeyutils.so.1 => /usr/lib/libkeyutils.so.1 (0x00007f8f00cd5000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f8f00931000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8f00ed9000)
que ademas puedo compilar de manera estatica, para que este incluidas en el ejecutable.
Por otro lado sino tengo acceso a ssh, no significa que no pueda aprovecharme de otra vulnerabilidad para conseguir ejecutar codigo en la maquina remota, por ejemplo con un shellexploit.
Una escalada de privilegios es un asunto muy serio, como para que le restes importancia.
The vulnerability affects any Linux Kernel version 3.8 and higher. SMEP & SMAP will make it difficult to exploit as well as SELinux on android devices.
#15 Comparado con microkernels que ejecutan drivers en ring 0 como el de Windows, ¿no? Bah...
Lo que sí es importante es PaX, y grsec, y SELinux. Y no empecemos con los hipervisores, que también son un cacho de software que puede tener sus fallos.
#51 Los microkernels precisamente, el tema de los drivers lo tienen separado. Y corren en espacio de usuario, o sea, que nada de Ring 0 ni como Windows ni como Linux. Los microkernels son mucho más seguros y si un driver falla no tiene porque dar kernel panic.
"If the hardware provides multiple rings or CPU modes, the microkernel may be the only software executing at the most privileged level, which is generally referred to as supervisor or kernel mode. Traditional operating system functions, such as device drivers, protocol stacks and file systems, are typically removed from the microkernel itself and are instead run in user space.[1]"
#51 Ya te he dejado otro comentario pero esto creo que es importante:
"Monolithic operating systems (e.g., Windows, Linux, BSD) have millions of lines of kernel code. There is no way so much code can ever be made correct. In contrast, MINIX 3 has about 4000 lines of executable kernel code. We believe this code can eventually be made fairly close to bug free."
"In monolithic operating systems, device drivers reside in the kernel. This means that when a new peripheral is installed, unknown, untrusted code is inserted in the kernel. A single bad line of code in a driver can bring down the system. This design is fundamentally flawed. In MINIX 3, each device driver is a separate user-mode process. Drivers cannot execute privileged instructions, change the page tables, perform I/O, or write to absolute memory. They have to make kernel calls for these services and the kernel checks each call for authority."
#15 La de gente que he visto que solo jala la imagen de docker sin verificar y piensa que puede sustituir el manejador de paquetes de la distribucion. Con un poco de mala leche podria divertirme creando una imagen.
#77#66 DragonFly es bastante "parecido" a Linux desde el punto de vista del usuario y hasta tienes acceleración 3D parece, solo que con menos locks en el Kernel y su diseñó hará que en el largo plazo sea más rápido que el Kernel de Linux. Y Minix 3 está avanzando bastante.
Cada vez que sale algún fallo de este tipo me encuentro antes la actualización en el SO que la noticia que hable de ello.
Eso sí, los payasos diciendo de forma sarcástica que solo hay fallos en Windows y nunca en Linux me los tengo que leer igual. Me pregunto de donde sale ese victimismo, no se de ningún linuxero que afirme que no haya ningún tipo de fallo en el kernel de Linux.
Supongo que solo intentan ir de rebeldes y no saben ni como.
Estoy seguro que mi flamante Samsung no está afectado... imposible tener mas Bugs a parte de los que ya trae de serie para espiar mi prolífica e interesante vida
Comentarios
Serious Linux Kernel Vulnerability Patched https://www.reddit.com/r/linux/comments/41opdo/serious_linux_kernel_vulnerability_patched/
#7 -> #6
#6 Corregido tan solo seis comentarios después.
Menos mal que linux sólo lo usan cuatro frikis pajilleros
Enviado desde mi Android
#4 ¿Hoy Android sí es Linux?
#9 parece que hay un 66% de androids afectados
As of the date of disclosure, this vulnerability has implications for approximately tens of millions of Linux PCs and servers, and 66 percent of all Android devices (phones/tablets).
#10 ¿Otra vulnerabilidad crítica en Android que la mayoría de los móviles nunca llegarán a tener parcheada? Genial...
Va a ser mejor meterlo en una jaula de Faraday excepto cuando necesite llamar.
#19 Bueno, veo complicadillo que exploten este bug en Android, salvo que te instales tu mismo el exploit.... Una manera fácil de rootear el dispositivo?.... promete.
#19 Mis colegas se extrañan cuando me ven con un móvil BQ (el nuevo M5). Es precisamente por estas movidas por lo que lo compré, te aseguran 2 años de actualizaciones desde la salida del dispositivo, y son frecuentes.
Si no necesitara doble SIM habría pillado un Nexus, claro está.
#10 Entiendo que ese 66% de teléfonos Android llevan una semana con el bug corregido por lo que dice #5
#22 Entiendes mal: el 33% de teléfonos Android llevan 3 años con el bug corregido.
#13 #20 Me acordé de una vez que cierto software libre muy conocido corrigió un fallo horas antes incluso de ser descubierto, y todos aplaudieron la rapidez.
¿cómo? la gente muchas veces confunde la fecha de la noticia con la fecha real en la que los responsables conocieron el bug. Ese bug llevaría como un mes descubierto, lo único que ocurrió es que esperaron a que hubiese un parche antes de publicar la noticia, para evitar que explotaran el fallo.
Y con linux ocurre lo mismo, los comentarios que dicen "lo corrigieron en horas, ya puedo actualizar", las veces que me puse a mirar, había al menos una semana o dos que se conocía el bug, que sigue siendo rápido pero no "en horas".
#22 En cuanto a Android, la mitad de los teléfonos afectados ¿corregirá algún día ese fallo?
Android es un poco penoso actualizando.
#10 a ver si está el mio y puedo rootearlo sin necesidad de hacer todo el proceso.
#9 Cuando se trata del kernel Linux, siempre es Linux. En este caso se trata de un bug en el kernel Linux; así que cualquier dispositivo que tenga instalado un kernel Linux 3.18 o versiones superiores, está afectado.
Cuando el fallo está en el núcleo, da igual como se llame el OS que use ese núcleo. No hay discusión en esto.
Otra cosa es cuando falla algún componente del OS Android y aparece alguien preguntando cosas como "Hoy Android no es Linux??".
Linux es el nombre de un núcleo que utilizan muchos sistemas operativos del tipo "UNIX".
Todo lo demás no es Linux, será "ponga aquí el nombre/Linux"; para indicar que usa el kernel Linux.
Sin duda es, de todos los que me he leído, el bug mejor explicado de todos. En un lenguaje claro, con ejemplos de código, empezando a explicar desde 0... Impresionante. Gracias por el envio@neuralgya me guardo la web en favoritos.
#14 buena explicación pero no la quieren/pueden entender... ¡Y no lo harán nunca! Jajaja
#9 https://www.meneame.net/search?u=sorrillo&w=comments&q=android linux
Madremía... ¿Y aún no lo has entendido?
#25 Pa que, si puede soltar la cuñadarería del día, y pasar página.
#9 Android siempre es Linux, nunca es GNU/Linux, ni tampoco es Ubuntu.
#4 y la mayoria de los servidores de internet
#16 la mayoría de los servers de internet, manejados claro esta por los mismos 4 frikis pajilleros
#21 Perdona, pero llevo diez años en esto y no he visto esa escena con GNU/Linux en la vida (y me he movido mucho). Tu estas confundiendo un administrador de sistemas que maneje GNU/Linux con soltura con un "cuñao de" coleccionista de PC Actual. No nos desviemos...
#30 Ehem, oye que no quiero seguir con la polémica, pero es que me los encuentro semana sí y otra nó, que no les cabe en la cabeza que su endiosado Debian les esté dejando tirados y que la sombra del paro les ponga histéricos y con malos modos.
#31 Pues chico, diles que se pongan las pilas y vayan a donde quieren contratar administradores de Debian. Que me parece que confundes "no quieren contratar" con "no quieren contratar linuxeros". Mira la que esta cayendo y aqui estoy, pegandome con Debian, JBoss y familia...
#34 vale, veo que eres un crack, ¿esa solución con la que estás "pegandote" está en un entorno de producción de una empresa donde si se cae puede perder mucha pasta? ¿es una institución académica o fundación?
Te contrato y te pago lo que no está escrito si me aseguras cero euros de perdidas con una solución sin soporte y en la que solo puedo confiar en tu capacidad.
#36 crees que con windows se puede hacer lo que dices?
#40 Sí se puede, la presión de un contrato de soporte y un SLA es muy efectiva.
#43 había entendido tu comentario al revés, entendí que insinuabas que con windows no era necesario ningún tipo de soporte para ofrecer confiabilidad. Estamos de acuerdo, ninguna opción sin soporte es adecuada para un entorno serio, a menos que tu equipo de sysadmins sea nivel Champion... Y ni así. De todas formas, linux también lo puedes encontrar con soporte, Redhat por ejemplo.
#36 "si me aseguras cero euros de perdidas con una solución sin soporte y en la que solo puedo confiar en tu capacidad."
Ningún administrador de sistemas que se precie te va a vender eso. El "cuñao" que te decían antes, ese sí, te vende eso y más.
#36 En un gobierno autonómico, y hasta ahí puedo leer sin saltarme mi contrato.
Y si tienes una empresa con presupuesto de informática, eres un kamikaze si utilizas una solución con cero soporte, habiendo equivalentes con empresas detrás que te dan soporte. El problema no es meter GNU/Linux, el problema es meter un GNU/Linux cualquiera en lugar de uno que de soporte a empresas, que los hay y muchos. O contratar a un admin cualquiera en vez de uno con experiencia demostrada y/o certificaciones. Que los hay y muchos, pero no les puedes pagar con cacahuetes, claro... Españistan way of life, y todo eso.
#36 A donde hay que mandar el currículum y de qué sueldo hablamos ?
#30 A lo que se refiere es que hay mucho converso advenedizo, de esos que son más radicales a la hora de defender Linux, pero luego su nivel como bien dices no pasa de Cuñao Google Avanzado.
Profesionales de Linux los hay de primera y curtidos en mil batallas.
#21 Si, claro, y luego te levantas del sueño y ves todo lo que mueve Red Hat y Canonical.
#24 Si claro, con soporte fresquito y pagando, con un SLA para la solución de problemas.
Al final lo barato GNU sale caro.
#26 Sí, como el fallo de AD del otro día, el cual hay que tirar el arbol AD y muchas veces el dominio DNS asociado abajo.
¿A cuanto sale el soporte de semejante cagada?
#27 Si la empresa que tiene el problema tiene soporte activo con Microsoft, vamos a lo mismo $$$$, con un tiempo de respuesta decente, te puedo asegurar que se mueven muchos culos para solucionarlo.
#28 En el caso de AD las pérdidas por el servicio sin estar en activo (al ser más monolítico) son más numerosas.
#39 Pues mira que han publicado el código fuente y hay negocios con servidores windows a los que doy soporte, hasta ahora: cero problemas de este tipo reportados.
#28 Claro, el soporte de Microsoft lo dan seres de luz, no administradores estrella de esos que no saben administrar su sistema...
Linux es usado en la inmensa mayoría de los servidores de las mayores compañías del mundo porque sus jefes son unos frikis que están encantados de que sus servidores se caigan cada 20 minutos...
Deberías hablar con Larry Page y decirle que migren todo Google a Windows, que es un friki no sabe qué está haciendo.
Madremía el cuñadismo...
#27 Los SLA de Red Hat valen una fortuna, se te ha ocurrido echarle un vistazo a los precios?
Lo de fallos que te obliguen a tumbar sistemas o dejarte los cuernos solucionándolos es un clásico hables del sistema que hables. Aún tengo frescas en la mente cagadas de Apache, OpenSSL y por supuesto un buen puñado en Windows Server.
#26 Fascinante, ahora va a resultar que si pagas soporte las cosas se solucionan sin problemas. Menuda novedad, oye.
#45 lis empresauriis no compran licencias por el soporte, lo compran para delegar la responsabilidad de ciertos fallos.
#26 no tienes ni idea de lo que hablas. Uno de mis clientes es una empresa con 15 años que esta facturando 12 millones de dolares al dia.
Practicamente todo es software libre. Invierten en ingenieros en vez de licencias de soporte.
Supongo que los que decis chorradas de este calibre estáis a sueldo de Ms, Oracle o alguna de estas, si no no me lo explico.
Al igual que ayer con el fallo de windows, vamos a intentar hacer una explicación sencilla por si alguien sin mucha experiencia quiere entender como funciona esto (gente con experiencia, no os lanzeis a mi cuello, este comentario no es para vosotros)
El kernel es dios, con poder para hacer cualquier cosa en nuestro sistema. Para poner un buen ejemplo en nuestra sociedad, digamos que el kernel es un banco. Como banco tiene un montón de trabajadores, dinero y similar. Una de las cosas que tiene son cajas de seguridad, muchas cajas de seguridad. El banco es bastante paranoico para evitar robos, por lo que no nos va a dejar entrar dentro de la zona segura del banco, ahi solo pueden entrar los trabajadores del mismo. Sin embargo, el banco pone a disposicion de los usuarios ciertos servicios. Uno de ellos (entre una multitud ingente) es almacenar tu carne del videoclub). Pero claro, el banco no te va a dejar entrar en la camara segura para recuperar el carné, lo que te dice es que tiene un empleado llamado Jose que es el que se encarga de traer y llevarte el carné.
Para ello, el banco coje una caja de seguridad (la 2237, por ejemplo) y la reserva para tu carne de videoclub y te da la llave de la caja que en su llavero pone el 2237. Mientras tanto, el banco apunta que esa caja esta ocupada y jose apunta en su libreta que tu tienes una copia de dicha llave. Cada vez que quieres ir al videoclub, solo tienes que ir al banco, avisar a jose, mostrarle la llave que apunta a la caja 2237 (mostrarle le basta, el banco tiene una llave maestra) y el amablemente te acompaña al videoclub para enseñar ahi tu carne y todo funciona. Si algun día quieres dejar de utilizar ese servicio, jose borra tu nombre de la libreta y el banco dice que la caja 2237 esta libre para usar por cualquiera de los otros trabajadors y servicios del banco
Ahora bien, esto es un engorro, no porque tengas que pasar por el banco antes de ir al videoclub, sino porque acabas de casarte y tu esposa también tiene un carne para el videoclub. Dado que los carnés son familiares, no necesitais dos, os vale con uno, por lo que decidís que a partir de ahora utilizareis el vuestro. Vais juntos al banco llamais a jose y se lo explicais. Tu mujer a partir de ahora no va a usar el carne que ella tenia guardado, sino el tuyo. Jose dice que no hay problema, le pide a tu señora que le devuelva la llave que ella tenía con su caja y le entrega una copia de la llave 2237. Adicionalmente, apunta en la libreta que ha entregado dos copias de dicha llave a clientes, por lo que hasta que no le devuelvan dos copias de la llave 2237, no puede avisar en el banco que la caja ya no está en uso.
El día de mañana podeis tener hijos que no hay problema, Jose se aburrira de entregar llaves, llevando la cuenta de cuantas ha entregado para saber cuando le han devuelto todas.
Ahora expliquemos como podemos engañar al banco. Yo, con mi copia de la llave 2237 voy a Jose y le digo que a partir de ahora no voy a usar la llave que tengo, sino que voy a utilizar la llave 2237. Jose te mira extrañado, ya que tu ya estas usando la llave 2237, pero intenta cumplir con su trabajo, pero comete un error. Aunque en principio a mi me ha dado una llave y me ha quitado una, en su libreta solo ha apuntado que me ha dado una llave. Esto puede tener un pequeño problema, posteriormente le devolvemos todas las llaves a Jose, segun su libreta no le salen las cuentas, todavía hay una llave en circulación, por lo que no se puede reutilizar esta caja. La llave no va a aparecer nunca, por lo que esa caja jamas quedará libre. Si Jose comete este error muchas veces, el banco puede empezar a tener problemas porque no le van a quedar cajas libres
Sin embargo, el problema es un poco más complejo. Ya hemos visto que Jose, aunque diligente, no es especialmente bueno con las matemáicas, especialmente con los numeros grandes. Jose solo sabe contar hasta un numero grande, pongamos 999 (la realidad es que jose cuenta hasta algo más de 4000 millones, que no esta mal, pero simplifiquemos a 999) Si en algun momento Jose ha entregado 999 llaves y entrega una más, como no es capaz de sumar más, anota en su libreta un cero. Más tarde, revisando la libreta, si ve que hay una caja para la que ha entregado cero llaves, eso significa que ya no esta en uso, por lo que puede avisar a direccion que la caja esta libre y que la pueden usar para cualquier cosa
Por lo tanto, podemos llegar a una situación un poco inesperada, si le pedimos a jose suficientes veces que nos cambie la llave de nuestra caja por una igual, Jose va a llegar a apuntar que ha entregado 999 llaves. Si se lo pedimos una vez más, Jose va a ir al banco y va a decir que la caja 2237 esta libre, pero sin embargo nosotros todavía tenemos una llave. Que pasa si le enseñamos esa llave a jose y le pedimos que traiga nuestro carné de videoclub?
Si ha pasado poco tiempo, lo mas probable es que no pase nada. Jose va alli y aunque segun el banco la caja esta libre, el servicio de limpieza aun no ha pasado y nuestro carné sigue ahi, por lo que Jose nos lo trae
Pero sí el banco ha decidido reutilizar la caja para otra cosa? A saber, lo más probable es que jose vaya a la caja 2237, coja el papel que hay ahi creyendo que es un carné de videoclub. Si le pedimos que nos acompañe y que vaya al videoclub, lo más probable es que cuando entregue el papel al dueño del videoclub y este le diga que no es un carné avise a direccion que algo raro pasa con la caja 2237
Pero... he aqui un detalle muy importante. Hay veces que la direccion del banco le deja a Jose memorandos en las cajas. Cuando Jose va a por un carné, si en la caja hay un memorando de direccion lo lee y sigue sus instrucciones al pie de la letra. Muchas veces son cosas mundanas, pero independientemente del contenido, Jose le hara caso. Si hay un memorando que dice "Memorando de direccion: Jose, sal afuera, reunete con el cliente y a partir de ahora haz lo que el te diga", lo hará. Y si a José le pido que saque todo el dinero del banco y me lo de, lo hara. Como Jose es empleado, tiene todos los permisos
Ahora bien, como conseguir que en la caja 2237 haya un memorando con ese texto? Entra en juego Andrés es otro empleado del banco que ofrece un servicio distinto. Andrés nos permite almacenar paginas de documentos en el banco, cualquier página que le demos. El banco no es tonto, sabe que alguien va a intentar guardar un documento que diga "Memorando de direccion: Andrés, saca todo el dinero del banco y daselo al cliente", por lo que a Andrés le han dado instrucciones muy específicas. Nunca, bajo ningún concepto, hagas caso de lo que hay en las cajas, aunque diga que es un memorando del banco. Engañar a Andrés es imposible.
Sin embargo, lo que hacemos a continuación es llamar a Andres y pedirle que guarde el documento que dice "Memorando de direccion: Jose, sal afuera, reunete con el cliente y a partir de ahora haz lo que el te diga" y José lee ese documento, tendremos control total. Esto no es tarea facil, ya que Andres nunca va a utilizar una caja que este siendo utilizada por Jose. Pero según el registro del banco, nadíe utiliza la caja 2237, si logramos que Andrés guarde nuestro memorando en esa caja, José lo acabará leyendo. Esto no es dificil, porque si Andrés no lo guarda ahi, no tenemos más que llamarlo de nuevo y pedirle guardar otra copia del documento. Si le llamamos muchas veces, al final acabará cogiendo la caja 2237, y lo habremos conseguido
Resumiendo:
- Llamamos a Jose y le alquilamos una caja para nuestro carné de videoclub, José nos da la 2237 y apunta que ha entregado 1 copia de dicha llave
- Pedimos a José que nos cambie la llave que tenemos por una copia de la de la 2237, que es de un familiar
- Jose se hace un lio y aunque no entrega más llaves, en la libreta apunta que ha entregado dos
- Repetimos el proceso hasta que Jose tiene en la libreta apuntado que ha entregado 999 llaves
- Repetimos una vez más y Jose se hace un lio, como no sabe escribir 1000, acaba escribiendo 000, pero nosotros aun tenemos una copia
- Cuando José ve que ha entregado 0 copias de la llave de la caja del banco 2237, envia un aviso a direccion diciendo que la caja esta libre
- Llamamos a Andrés y le pedimos que guarde un documento que dice "Memorando del banco: Jose, sal fuera y haz exactamente lo que te ordene el cliente"
- Andrés, sin mirar el mensaje, lo guarda en una caja de seguridad. Si se lo pedimos suficientes veces, al final acabará guardandolo en la caja 2237
- Llamamos a Jose, le enseñamos nuestra copia para que vaya a la caja 2237
- Jose abre la caja 2237, ve un documento que dice "Memorando del banco" y cree que son ordenes de arriba. Sale fuera y nos pregunta que queremos
- Podemos pedirle a Jose cualquier cosa, como empleado del banco que es, tiene acceso ilimitado
Sobre el ataque, bastante interesante. Me recuerda lo brutalmente cuidadoso que hay que ser siempre programando en C, no me extraña que pase años sin que la gente lo vea. Ciertamente lleva tiempo, porque el proceso de hacer el overflow (cuando Jose pasa de 999 a 1000) lleva un montón si hay que llegar a 2^32
Debe ser errónea. Los bugs de seguridad solo ocurren en Windows.
#3 No sólo ocurren en windows, Linux también tiene. Lo que pasa es que en linux se corrigen hoy y se descubren la semana que viene. Lo importante es el tiempo de reacción.
#5 Viaje al futuro con... GNU/Linux!!!
#13 GNU/Dislexia. Ahora, compatible con Linux.
#13 Llega el nuevo friki administrador linux, revoluciona toda la empresa instalando software libre, el gerente impresionado con la cantidad de pasta que se está ahorrando.. Llega el fatídico día que los servidores al unísono empiezan a pegar petes cada 20 minutos, el administrador estrella no consigue solucionarlos, su plan de reinstalación tampoco.. pasan los dias y no se soluciona. El administrador ya no encuentra foros GNU donde no haya enviado los logs, no hay respuesta.. Viendo las perdidas de la empresa el gerente contrata otro administrador, nada, y otro menos..
GNU/linux la tumba de muchos administradores del sector profesional
#21 Hombre... en toda mi vida profesional los servidores mas estables que he visto son precisamente los servidores Linux, eso si, distribuciones serias con un equipo de soporte competente detrás. Está claro que si pones a un becario sin experiencia como administrador de sistemas el ostión está practicamente asegurado, pero esto pasa con cualquier cosa, lo dices como si un Windows Server se administrase solo...
#21 Unsuccessful troll is unsuccessful.
#21 palabra de cuñadmin, dí que si!!
#21 ¿ Sabes lo grasioso que resulta que digas eso en un sitio que corre bajo GNU/Linux y es uno de los sitios con más visitas de toda España?
#21 que chungo vivir con la cabeza metida dentro de tu propio culo.
#5
En Windows es habitual que si se hace público un bug, el parche o está en camino o ya se puede descargar. Bugs más complejos pueden tardar tiempo en corregirse, y eso es así en Linux, MacOS, Windows y el sistema que sea.
No entiendo mucho, pero espero que esta llegue a portada al igual que llegó esta:
Elevación de privilegios sencilla (a la 1ª) en todos los Windows. Si llevas un AD (Active Directory) reza, no hay parche
Elevación de privilegios sencilla (a la 1ª) en tod...
twitter.comA no ser que venga el comando pingüinero a tumbarla.
#1 siendo un 0-day, cualquier admin de sistemas linux preferiría que estuviese en portada.
#1 Por mi experiencia profesional, de ya unos cuantos años, la respuesta del usuario típico de cada SO a una noticia de este tipo es:
- MacOS: pa que quieres saber eso jaja saludos
- Windows: yo ke se tio xd
- Linux: toca actualizar
He visto a fanboys de todo pelaje, pero nunca me he encontrado a ningún fanboy de Linux interesado en encubrir un fallo en el kernel para exculpar no sé muy bien el qué.
Aunque, para ser honesto, también debo reconocer que tampoco me he encontrado a muchos fanboys de MacOS o Windows... que supiesen lo que es un kernel...
#23: Relacionada:
#35 La de Mac es optimista, está dando por hecho que la actualización incluye ese dispositivo...
#35 Apple lleva dando gratis actualizaciones mayores de OSX desde hace 4 o 5 años, de hecho fue el primer SO privativo que lo hizo... pero de algun topico hay que tirar para criticar a OSX, ya que tecnicamente es dificil, pues es un sistema unix cojonudo.
#23 Tu si que eres un fanboy.
#41 Estás lleno de argumentos, eh?
#23 Posss me paso a FreeBSD
#62 Hay una empresa que ha desarrollado un desktop muy chulo para FreeBSD y lo vende con unos ordenadores to guapos. MacOS le llaman
#23 Cuando el usuario que opina tiene conocimientos técnicos o es al menos administrador de sistemas (de los de verdad, de los que viven de eso), no se suele tomar posición de fanboy. Y ni de coña encubren bugs con no se sabe qué oscuros intereses.
#90 De ahi que hablase del usuario medio. Aunque no puedo negar cierto apetito por el flame
Más allá de consideraciones técnicas, que en muchos casos suelen derivar en estériles polémicas entre fanboys, es innegable que el usuario medio de Linux conoce mucho mejor su SO y está más implicado a la hora de reportar bugs. Lo cual hace que sus sistemas suelan estar mucho más actualizados y por tanto sean más seguros.
Obviamente todo esto deja de aplicarse en un sistema concreto basado en Linux: Android. Ya que muchos frabricantes no proporcionan las actualizaciones necesarias para sus dispositivos y, aún siendo el caso, muchos usuarios simplemente no las instalan.
#23 Yo todavía estoy esperando ver a un usuario de linux que no demuestre su absoluta ignorancia cuando habla de Windows. Y llevo unos cuantos años ya.
#1: el comando pingüinero
Parece una canción de los Def Con Dos.
#1 Esa es la pequeña diferencia entre el software abierto y el cerrado,en el software abierto se publican los fallos para encontrar soluciones y en el software cerrado las empresas ocultan sus bugs hasta que se hacen demasiado evidente.
#33 que te publiquen un 0day no tiene nada que ver con el tipo de licencia d tu software.
#68 Si miras el comentario al que respondo verás que no me refiero a lo que creías.
Para explotar esa vulnerabilidad tienes que tener acceso físico al sistema y además que estén instaladas las herramientas de compilación. Es bueno tener instalado solamente el software que necesitas y cuanto menos software tengas instalado más seguro será el sistema. Si no piensas compilar nada, si solamente usas los binarios oficiales que vienen en tu distribución, no es necesario que tengas instalado los paquetes necesarios para hacer la compilación, no necesitas añadir paquetes.dev, etc.
Me parece recordar que una vez hubo un caso parecido, un programa en C que lo compilabas y luego podías acceder a root por la cara, pero si no tienes acceso físico a la máquina ni están instaladas las herramientas de compilación, a ver como coño lo haces.
Cada vez que se encuentra una vulnerabilidad en Linux más seguro y más robusto se hace el sistema porque en cuestión de horas la comunidad publica el correspondiente parche, no como hacen en Windows que esconden la mierda debajo de la alfombra para que sus clientes no la vea.
#17 Para explotar esa vulnerabilidad tienes que tener acceso físico al sistema y además que estén instaladas las herramientas de compilación.
No solo eso, ese acceso a la máquina tiene que ser largo si le máquina tiene uno de los últimos modelos de microprocesador i7, el atacante necesita media hora!!
#29 Bueno, es un overflow a un Int a base de incrementar uno a uno su valor. Estas cosas llevan su tiempo
#17 "tener acceso físico al sistema"
Acceso local, no acceso físico. Con una web mal configurada que te permita guardar y ejecutar cosas, es más que suficiente.
"que estén instaladas las herramientas de compilación"
Como si no se pudiese subir ya compilado, o en el peor caso subir las herramientas.
#29 "ese acceso a la máquina tiene que ser largo"
Los servidores suelen dar acceso 24/7.
#53 Además, en los UNIX/Linux el acceso remoto es el pan nuestro de cada día. Este tipo de vulnerabilidades son más serias en Linux que en Windows
#53 Como si no se pudiese subir ya compilado, o en el peor caso subir las herramientas.
Lo cual no te serviría de mucho si los lugares donde puedes escribir como usuario no tienen permiso de ejecución.
#17 acabo de leer el parche, no termino de entender tu comentario
Efectivamente, necesitas tener acceso al sistema, pero no veo por que no puedes hacerlo con un acceso remoto
Segundo, tampoco veo para que necesitas compilar el exploit en la maquina objetivo. Lo compilas en otro lado y copias el binario
Mañana si tengo tiempo analizare el problema en detalle
#49 ya, y si tienes el acceso remoto ya para que quieres el exploit?
Solo los admin deben de tener acceso al servidor, para que más?.
#52 Hay muchas circunstancias donde yo puedo tener acceso remoto como usuario a una máquina pero no tener acceso de administrador. Algunos ejemplos:
Puedo tener acceso de lectura al servidor (logs y similar), pero no para ser root
O puede que codigo que yo creo se despliegue en un servidor en una cuenta de usuario
O puede ser el ordenador donde hacía practicas en la universidad, donde tenía cuenta de usuario pero no de root (obviamente)
O ser un telefono android donde el root esta desactivado (aunque no este de acuerdo con esta política)
O quiza el ordenador del trabajo donde no me dan admin porque lo gestionan en IT
O uno de los servidores de sourceforge (recuerdo que antes te daban acceso ssh)
O meter el codigo en un ejecutable y convencer a un usuario para que lo ejecute, como no es root, cree que el daño que puede hacer el programa es minimo (cosa que no es cierta si tiene cosas como usuario importantes)
Y por ultimo, y no porque no haya más, puede que tenga un exploit de tipo remote code exeuction que combinado con este me da remote root
No se, yo la lista la veo muy larga
#54 Tal ves sea por mi corta experiencia, pero sigo sin entender porque dar acceso al sistema operativo a un usuario (en el caso de servidores), si es para ver reportes se puede enviar a un correo o verlo a través de una página diseñada para tal propósito.
En el extremo de necesitarlo (como ser pobre y no tener un servidor para cada cosa) dar permiso para escritura y lectura en algunas carpetas para imágenes documentos y demás, sin embargo se puede hacer lo mismo a través de un servidor web bien configurado.
#52 Imagínate: servidor web, una cagada en algún .php que permita guardar un fichero php y llamarlo desde la web (como usuario "apache" probablemente), que descarga un exploit, que a su vez salta a usuario "root" y te manda una copia de las claves privadas del certificado SSL de la web hospedada en ese servidor para que puedas hacer phishing más a gusto, o que instale el rootkit que más te mole.
#55 basicamen hoy menos del 0.1% de los servidores tienen abierto llamadas de sistema desde php.
Basicamente estamos hablando de expltar una vulnerabilidad desde otra vulnerabilidad
#56 ¿Llamadas de sistema? Nada de llamadas de sistema, con un simple exec desde un php controlado por el atacante basta y sobra.
De lo que estamos hablando es de tomar el control completo del sistema, explotable desde cualquier descuido chorra.
#59 Con llamada a sistema me refieron a Exec y system. Bienen por defecto bloqueados en todas las configuraciones de produccion y habilitarlo sin control alguno ya es un problema de seguridad por si solo, considerando que ademas deberia tener otra vulnerabilidad para subir archivos php, estamos hablando de algo que por si puede liarla en el servidor.
Mas el fallo que se describe hablamos que deben haber 3 vulnerabilidades en el sevidor, algo extremadamente raro hoy en 2016
#56 El 0.1% siguen siendo muchísimos servidores. Y hablamos que combinados es tener control total
#55 Yep, justo lo que decía antes, ¿tienes un remote execution? ¡Whops, ahora es remote root!
#52 me parece lo más normal del mundo tener acceso no-root remoto a un servidor Linux. De hecho es root quien suele tener restringido el acceso remoto.
Si "solo los admin" deberían acceder, qué gracia tiene tener un sistema de red multi-usuario.
#61 Si es a través de php o algún otro, es lo mas normal; pero porque directamente al sistema operativo del servidor?
#72 hay más tipos de servicios que la web, para los que se requiere acceso ssh.
Incluso en web, muchos servicios de hosting dan acceso ssh.
Pero no sólo existen servidores para páginas web. En mi empresa por ejemplo el servidor linux local precisamente lo que no sirve es web, sirve cuentas ssh que se usan en un 90% para compilar código.
Vamos, que hay vida más allá del hosting web pelado sin ssh ni nada.
#73 Mi idea es mas usar el servidor web como un filtro / puente entre el usuario y el servidor.
#78 lo que quieres es una configuración posible, pero limitada en funcionalidad.
En mi caso se quedaría corto, yo tengo scripts entre mi servidor local y el servidor remoto vía ssh para gestionar la web y la bdd sql.
#52 No es lo mismo acceso sin privilegios que con ellos
#17 solo necesito tener acceso a una shell, por ejemplo ssh.
Que no esten las herramientas de compilación me la sopla, compilo en mi pc y lo ejecuto en remoto.
solo necesita las librerias : ldd cve_2016_0728
linux-vdso.so.1 (0x00007ffeda3cb000)
libkeyutils.so.1 => /usr/lib/libkeyutils.so.1 (0x00007f8f00cd5000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f8f00931000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8f00ed9000)
que ademas puedo compilar de manera estatica, para que este incluidas en el ejecutable.
Por otro lado sino tengo acceso a ssh, no significa que no pueda aprovecharme de otra vulnerabilidad para conseguir ejecutar codigo en la maquina remota, por ejemplo con un shellexploit.
Una escalada de privilegios es un asunto muy serio, como para que le restes importancia.
#60 Sip, yo acabo de compilar ropa en la lavadora
#17 Y puedes denegar la ejecución a las carpetas de usuario...
The vulnerability affects any Linux Kernel version 3.8 and higher. SMEP & SMAP will make it difficult to exploit as well as SELinux on android devices.
Si tienes un kernel de esos, pues a actualizar.
Ufff, ya no duermo tranquila hasta que no se solucione este asunto
#2 Claramente no tienes servidores que dependan de ti. ¿Suerte?
#44 Si tengo, una chica que me limpia la casa y me hace la plancha 2 días a la semana
#74 Ella no depende de ti, dependes tú de ella
Es lo que tiene un kernel que ocupa una burrada, comparado con microkernels. Eso y que no integran PaX.
Y encima si tienes docker también te afecta porque corre en el kernel, no es un hypervisor real lo que separa los contenedores.
#15 Comparado con microkernels que ejecutan drivers en ring 0 como el de Windows, ¿no? Bah...
Lo que sí es importante es PaX, y grsec, y SELinux. Y no empecemos con los hipervisores, que también son un cacho de software que puede tener sus fallos.
#51 Los microkernels precisamente, el tema de los drivers lo tienen separado. Y corren en espacio de usuario, o sea, que nada de Ring 0 ni como Windows ni como Linux. Los microkernels son mucho más seguros y si un driver falla no tiene porque dar kernel panic.
"If the hardware provides multiple rings or CPU modes, the microkernel may be the only software executing at the most privileged level, which is generally referred to as supervisor or kernel mode. Traditional operating system functions, such as device drivers, protocol stacks and file systems, are typically removed from the microkernel itself and are instead run in user space.[1]"
Mirate ejemplos como Minix 3.
#51 Ya te he dejado otro comentario pero esto creo que es importante:
"Monolithic operating systems (e.g., Windows, Linux, BSD) have millions of lines of kernel code. There is no way so much code can ever be made correct. In contrast, MINIX 3 has about 4000 lines of executable kernel code. We believe this code can eventually be made fairly close to bug free."
"In monolithic operating systems, device drivers reside in the kernel. This means that when a new peripheral is installed, unknown, untrusted code is inserted in the kernel. A single bad line of code in a driver can bring down the system. This design is fundamentally flawed. In MINIX 3, each device driver is a separate user-mode process. Drivers cannot execute privileged instructions, change the page tables, perform I/O, or write to absolute memory. They have to make kernel calls for these services and the kernel checks each call for authority."
#15 La de gente que he visto que solo jala la imagen de docker sin verificar y piensa que puede sustituir el manejador de paquetes de la distribucion. Con un poco de mala leche podria divertirme creando una imagen.
#77 #66 DragonFly es bastante "parecido" a Linux desde el punto de vista del usuario y hasta tienes acceleración 3D parece, solo que con menos locks en el Kernel y su diseñó hará que en el largo plazo sea más rápido que el Kernel de Linux. Y Minix 3 está avanzando bastante.
http://blog.darknedgy.net/technology/2016/01/01/0/
#15 Lo suyo es usar Gnu Hurd
Imagino que el parche llegará en pocas horas.
El ancho del embudo: van a por un bug contra GNU/Linux pero nos tragamos un millón de Windows.
#71 Es como lo de P0dem0s y PPS03...
Cada vez que sale algún fallo de este tipo me encuentro antes la actualización en el SO que la noticia que hable de ello.
Eso sí, los payasos diciendo de forma sarcástica que solo hay fallos en Windows y nunca en Linux me los tengo que leer igual. Me pregunto de donde sale ese victimismo, no se de ningún linuxero que afirme que no haya ningún tipo de fallo en el kernel de Linux.
Supongo que solo intentan ir de rebeldes y no saben ni como.
Estoy seguro que mi flamante Samsung no está afectado... imposible tener mas Bugs a parte de los que ya trae de serie para espiar mi prolífica e interesante vida
#63 Llevaría tiempo (por lo de hacer 2^32 llamadas), pero no veo por que esto no se podría utilizar para rootear móviles sin pasar por el bootloader
#65 Ése es un punto muuuuuuuy interesante. ¿Cómo se podría explotar?
Y a estas alturas el 95% de ese 0.1% lo tiene bien filtrado, como para que no ejecute cualquier cosa.
Que no, esto es mentira, es una falacia. en linux no hay bugs.