El pasado mes de abril, un mensaje en la lista del kernel Linux alertaba de un fallo de seguridad en la función ‘sw_perf_event_destroy’ de kernel/events/core.c. Su autor, Tommi Rantala, comentaba que lo había encontrado ejecutando una versión de Trinity modificada por él mismo. Se trata de una herramienta para emplear técnicas de fuzzing en las llamadas al sistema que proporciona el kernel Linux.
#4 La de malabares que hacéis para que cualquier cosa se ponga a vuestro favor.
#6 Sí, quien pudiera tener el código de windows para poder arreglar estos errores y añadir el parche al repositorio del kernel, como hacen en linux.
Aunque en realidad eso lo hicieran los encargados del kernel, como ocurre en windows, pero que la realidad no te estropee tu ilusión.
#11 "El fallo fue reportado en abril, y pasó un poco de puntillas por la lista de desarrolladores, sin levantar demasiado revuelo. Pero parece que no pasó tan desapercibido para todo el mundo. Un poco más tarde, en mayo, un tercero hizo público un exploit para aprovechar la vulnerabilidad. Este hecho es el que realmente ha sacado a la luz que el fallo, es en realidad un grave problema de seguridad."
El fallo lo arreglaron los desarrolladores del kernel de linux y en windows también son los desarrolladores quienes arreglan los fallos y estos tienen abierto el código de windows, te lo aseguro.
#12 Si, pero en Linux no solo lo pueden descubrir los "desarrolladores oficiales", sino tu mismo si tienes conocimientos o una empresa ajena al desarrollo del kernel o estudiantes universitarios que experimenten con su codigo, ....
Ademas, creo que son muchos los "desarrolladores oficiales" de Linux.
#13 Y en windows también. Este fallo no lo descubrieron leyendo el código, de hecho, normalmente no se descubren leyendo el código.
Si los fallos en windows sólo pudiesen ser descubiertos por los "desarrolladores oficiales" los hackers y los creadores de malware lo tendrían crudo para descubrir y aprovecharse de una vulnerabilidad para infectarlo. Y tú bien sabes que windows tiene mucho malware y que se sirve de los fallos descubiertos por los creadores de malware, o de un tercero ajeno a MS porque los "desarrolladores oficiales" no publican los fallos hasta que están corregidos.
#18 "De entrada, Linux es Linux. Si crees que un proyecto como éste, de millones de líneas de código, es diferente por añadir unas pocas miles... Pues qué decir."
¿Qué dices?
"Los ciclos de desarrollo de Linux pueden no coincidir con los términos de soporte de Red Hat, por ejemplo, y que el código esté disponible permite a esta empresa solucionar el problema para sus usuarios antes de que salga un parche en la rama principal del kernel."
Los "desarrolladores oficiales" de Red Hat son Red Hat y los que arreglan en la mayoría de veces los problemas de Red Hat son los "desarrolladores oficiales" de red hat o los encargados de la rama principal del kernel, no un tercero ajeno a ambos, que es lo que digo, al contrario de lo que dice #13 que dice que lo puedo arreglar yo mismo, los universitarios...
¿Que esto no ocurriría en windows? es que de windows sólo hay una versión que es la oficial de Microsoft, no hay tropecientas distribuciones usando el kernel de windows, es como si sólo existiese Red Hat, y "la rama principal del kernel" y las empresas que usan el kernel son lo mismo: Microsoft. Pero tanto en windows como en linux son las empresas, ya sean las encargadas de la distribución en concreto o los encargados de la rama principal del kernel, quienes arreglan los problemas e incorporan los parches. En el caso de windows la empresa es Microsoft tanto para el kernel como para todo, en el caso de linux tendrás a Red Hat pero no yo o un universitario o un hippie.
Si Microsoft cediese a un tercero, digamos "Red Window", su kernel para que esa hiciese un derivado de windows, te aseguro que esa empresa también podría hacer lo mismo que "Red Hat".
Que sí, que alguna vez se puede dar el caso de que un tercero se ponga con el código y arregle él el problema pero eso no es lo normal. A parte, lo que un tercero haga no le sirve de nada a la mayoría hasta que la corrección es incorporada por los encargados vía actualización automática porque la mayoría no está al tanto de los bugs y ni se enterarían... o al menos no se enterarían si el porcentaje de uso abarcase a alguien más allá del 2% de frikis que usan linux.
#19 Si sabes arreglarlo puedes arreglarlo. Es software libre y ése es el punto en el que te pierdes.
"Que sí, que alguna vez se puede dar el caso de que un tercero se ponga con el código y arregle él el problema pero eso no es lo normal."
Te he dado el ejemplo de Red Hat.
"A parte, lo que un tercero haga no le sirve de nada a la mayoría hasta que la corrección es incorporada por los encargados vía actualización automática porque la mayoría no está al tanto de los bugs y ni se enterarían... o al menos no se enterarían si el porcentaje de uso abarcase a alguien más allá del 2% de frikis que usan linux."
Ya tardaba la falacia trolera de siempre. Pero claro, como Linux no se utiliza en la inmensísima mayoría de dispositivos integrados, teléfonos móviles o servidores, pues supongo que tienes razón
#20 Si sabes arreglarlo, puedes arreglarlo... si sabes, que lo normal no es eso porque ¿qué porcentaje de casos se han dado en donde fuese así? y aunque lo arregles, tu solución valdrá para ti y para alguno que de casualidad se entere de tu solución pero la mayoría recibirá el parche vía canal oficial y la inmensa mayoría de parches son hechos por los desarrolladores.
Red hat no es un tercero, Red Hat es una empresa con ganancias de casi mil millones de dólares dedicada a mantener una distribucción, red Hat no es tú o yo o un universitario.
2% de escritorio pero si quieres meterte en móviles, muy bien, pregúntale a cualquiera que tenga android si está al tanto de este bug o de cualquier otro que me voy a reír.
P.D: de paso dile eso de que linux no tiene malware
#21 Red Hat es un tercero. Busca el término en el diccionario. Cuando sus ingenieros actúan como desarrolladores del kernel que desean hacer un "pull request", no.
El problema que veo aquí es que no entiendes la dinámica de desarrollo ya no del kernel Linux sino del software libre. En particular en el kernel hay muchísimos patchsets mantenidos por terceros que añaden funcionalidad o solucionan fallos que no se contemplan en el Linux "vanilla" o no han llegado al ciclo esperado de desarrollo.
No le des más vueltas a la falacia del 2%. Linux no se utiliza en un 2% de los dispositivos, eso es mentira. Y si vamos a buscar usuarios que sean conscientes de los fallos de su sistema operativo, ¿conoces a alguno que tenga Windows y sepa qué arregla cada hotfix que recibe mensualmente?
#22 Vale, muy bien, yo, tú, el universitario y Red Hat estamos al mismo nivel, ellos son una empresa que gana 600 millones y se dedican a esto y yo un don nadie programador pero sí, somos lo mismo, un tercero.
En cuanto al 2% ¿no te das cuenta de que me estás dando la razón? Lo que trato de decirte con eso es que cuando un SO es usado por mucha gente "normal", que tú el universitario puedas arreglar un fallo en el kernel porque tienes el código y casualmente sabes hacerlo, no soluciona el problema de la inmensa mayoría de usuarios porque estos no están pendientes de los bugs, ni de sus soluciones ni de nada, pasan olímpicamente. Entonces ese fallo en sus ordenadores sólo será arreglado si un desarrollador oficial corrige y distribuye el parche vía actualización, vamos, como el windows update.
Yo no creo haber dicho "2% de dispositivos" sino "2% de escritorio" pero si tú te empeñas en meter esos "dispositivos" muy bien, metamos el 66% (creo) de móviles donde la gente se entera todavía menos y el párrafo anterior es todavía más cierto. Como tú quieras.
P.D: Los de windows se enteran todavía menos, al nivel de los de Android, por eso o hacemos que los "desarrolladores oficiales" solucionen el problema o que tú arregles un fallo a mi no me sirve de nada.
#23 Voy a dejarlo porque si no entras en razón no vamos a ninguna parte, pero...
Entiendes que los que mantienen los paquetes del kernel Linux son los empleados de cada distribución y que por tanto un parche de, digamos, Debian o Red Hat se incorporará cuando digan en Debian o Red Hat, ¿no?
#24 Sí ¿y tú entiendes que no puedes ponerme al mismo nivel los empleados de cada distribución y un tercero cualquiera como tú, yo, o un universitario? ¿que los empleados de cada distribución son a su distribución prácticamente lo que los empleados de Microsoft son a windows?
#12 "Aunque en realidad eso lo hicieran los encargados del kernel, como ocurre en windows, pero que la realidad no te estropee tu ilusión."
Los ciclos de versiones del kernel Linux no contemplan los mismos tiempos para un hotfix que un proveedor comercial, por ejemplo Red Hat. Por eso el kernel de Red Hat tiene parches desarrollados por sus ingenieros, ya no sólo para esta clase de problemas sino para funcionalidades no estándares.
#17 De entrada, Linux es Linux. Si crees que un proyecto como éste, de millones de líneas de código, es diferente por añadir unas pocas miles... Pues qué decir.
Y dices que el problema se solucionó igual que ocurriría con Windows. Mentira. Los ciclos de desarrollo de Linux pueden no coincidir con los términos de soporte de Red Hat, por ejemplo, y que el código esté disponible permite a esta empresa solucionar el problema para sus usuarios antes de que salga un parche en la rama principal del kernel.
Como? Vulnerabilidad que permite tomar el control del ordenador en linux? Pero pero pero pe pero estas cosas no pasaban solo en windooooooze????? Pero no puede ser!!! si linux era perrrrfeccto!!
Gracias a tener el codigo abierto se arreglan estos problemas en menos que canta un gallo. Con Windows ni te enteras porque hasta Microsoft te puede meter lo que le de la gana y nadie se daria cuenta si ellos quieren (quien sabe...).
Esto, junto a la enormeeeeeee potencia y flexibilidad que puede dar el disponer de todo el codigo fuente, es una de la mayores ventajas de Linux y el software libre en general. No son pocas las empresas y particulares que deciden toquetear sus Linux para adaptarlos o crearse nuevas funcionalidades que no existen en el kernel original. De esto Windows creo que tragas con lo que hay y poco mas.
Que alguien me de las instrucciones para saber si mi sistema es vulnerable a este bug. Primero necesito saber si tengo la versión del kernel vulnerable.
Comentarios
Este tipo de cosas no pasan en Windows porque no se tiene acceso al código.
#1 Este tipo de cosas no
pasanlas puedes solucionar en Windows porque no se tiene acceso al código.http://www.linuxinsider.com/story/Linux-The-Gold-Standard-of-Code-78051.html
#1 Claaaaaroooooo
#4 La de malabares que hacéis para que cualquier cosa se ponga a vuestro favor.
#6 Sí, quien pudiera tener el código de windows para poder arreglar estos errores y añadir el parche al repositorio del kernel, como hacen en linux.
Aunque en realidad eso lo hicieran los encargados del kernel, como ocurre en windows, pero que la realidad no te estropee tu ilusión.
#11 "El fallo fue reportado en abril, y pasó un poco de puntillas por la lista de desarrolladores, sin levantar demasiado revuelo. Pero parece que no pasó tan desapercibido para todo el mundo. Un poco más tarde, en mayo, un tercero hizo público un exploit para aprovechar la vulnerabilidad. Este hecho es el que realmente ha sacado a la luz que el fallo, es en realidad un grave problema de seguridad."
El fallo lo arreglaron los desarrolladores del kernel de linux y en windows también son los desarrolladores quienes arreglan los fallos y estos tienen abierto el código de windows, te lo aseguro.
#12 Si, pero en Linux no solo lo pueden descubrir los "desarrolladores oficiales", sino tu mismo si tienes conocimientos o una empresa ajena al desarrollo del kernel o estudiantes universitarios que experimenten con su codigo, ....
Ademas, creo que son muchos los "desarrolladores oficiales" de Linux.
#13 Y en windows también. Este fallo no lo descubrieron leyendo el código, de hecho, normalmente no se descubren leyendo el código.
Si los fallos en windows sólo pudiesen ser descubiertos por los "desarrolladores oficiales" los hackers y los creadores de malware lo tendrían crudo para descubrir y aprovecharse de una vulnerabilidad para infectarlo. Y tú bien sabes que windows tiene mucho malware y que se sirve de los fallos descubiertos por los creadores de malware, o de un tercero ajeno a MS porque los "desarrolladores oficiales" no publican los fallos hasta que están corregidos.
#18 "De entrada, Linux es Linux. Si crees que un proyecto como éste, de millones de líneas de código, es diferente por añadir unas pocas miles... Pues qué decir."
¿Qué dices?
"Los ciclos de desarrollo de Linux pueden no coincidir con los términos de soporte de Red Hat, por ejemplo, y que el código esté disponible permite a esta empresa solucionar el problema para sus usuarios antes de que salga un parche en la rama principal del kernel."
Los "desarrolladores oficiales" de Red Hat son Red Hat y los que arreglan en la mayoría de veces los problemas de Red Hat son los "desarrolladores oficiales" de red hat o los encargados de la rama principal del kernel, no un tercero ajeno a ambos, que es lo que digo, al contrario de lo que dice #13 que dice que lo puedo arreglar yo mismo, los universitarios...
¿Que esto no ocurriría en windows? es que de windows sólo hay una versión que es la oficial de Microsoft, no hay tropecientas distribuciones usando el kernel de windows, es como si sólo existiese Red Hat, y "la rama principal del kernel" y las empresas que usan el kernel son lo mismo: Microsoft. Pero tanto en windows como en linux son las empresas, ya sean las encargadas de la distribución en concreto o los encargados de la rama principal del kernel, quienes arreglan los problemas e incorporan los parches. En el caso de windows la empresa es Microsoft tanto para el kernel como para todo, en el caso de linux tendrás a Red Hat pero no yo o un universitario o un hippie.
Si Microsoft cediese a un tercero, digamos "Red Window", su kernel para que esa hiciese un derivado de windows, te aseguro que esa empresa también podría hacer lo mismo que "Red Hat".
Que sí, que alguna vez se puede dar el caso de que un tercero se ponga con el código y arregle él el problema pero eso no es lo normal. A parte, lo que un tercero haga no le sirve de nada a la mayoría hasta que la corrección es incorporada por los encargados vía actualización automática porque la mayoría no está al tanto de los bugs y ni se enterarían... o al menos no se enterarían si el porcentaje de uso abarcase a alguien más allá del 2% de frikis que usan linux.
#19 Si sabes arreglarlo puedes arreglarlo. Es software libre y ése es el punto en el que te pierdes.
"Que sí, que alguna vez se puede dar el caso de que un tercero se ponga con el código y arregle él el problema pero eso no es lo normal."
Te he dado el ejemplo de Red Hat.
"A parte, lo que un tercero haga no le sirve de nada a la mayoría hasta que la corrección es incorporada por los encargados vía actualización automática porque la mayoría no está al tanto de los bugs y ni se enterarían... o al menos no se enterarían si el porcentaje de uso abarcase a alguien más allá del 2% de frikis que usan linux."
Ya tardaba la falacia trolera de siempre. Pero claro, como Linux no se utiliza en la inmensísima mayoría de dispositivos integrados, teléfonos móviles o servidores, pues supongo que tienes razón
#20 Si sabes arreglarlo, puedes arreglarlo... si sabes, que lo normal no es eso porque ¿qué porcentaje de casos se han dado en donde fuese así? y aunque lo arregles, tu solución valdrá para ti y para alguno que de casualidad se entere de tu solución pero la mayoría recibirá el parche vía canal oficial y la inmensa mayoría de parches son hechos por los desarrolladores.
Red hat no es un tercero, Red Hat es una empresa con ganancias de casi mil millones de dólares dedicada a mantener una distribucción, red Hat no es tú o yo o un universitario.
2% de escritorio pero si quieres meterte en móviles, muy bien, pregúntale a cualquiera que tenga android si está al tanto de este bug o de cualquier otro que me voy a reír.
P.D: de paso dile eso de que linux no tiene malware
#21 Red Hat es un tercero. Busca el término en el diccionario. Cuando sus ingenieros actúan como desarrolladores del kernel que desean hacer un "pull request", no.
El problema que veo aquí es que no entiendes la dinámica de desarrollo ya no del kernel Linux sino del software libre. En particular en el kernel hay muchísimos patchsets mantenidos por terceros que añaden funcionalidad o solucionan fallos que no se contemplan en el Linux "vanilla" o no han llegado al ciclo esperado de desarrollo.
No le des más vueltas a la falacia del 2%. Linux no se utiliza en un 2% de los dispositivos, eso es mentira. Y si vamos a buscar usuarios que sean conscientes de los fallos de su sistema operativo, ¿conoces a alguno que tenga Windows y sepa qué arregla cada hotfix que recibe mensualmente?
Te estás enfangando tú solo.
#22 Vale, muy bien, yo, tú, el universitario y Red Hat estamos al mismo nivel, ellos son una empresa que gana 600 millones y se dedican a esto y yo un don nadie programador pero sí, somos lo mismo, un tercero.
En cuanto al 2% ¿no te das cuenta de que me estás dando la razón? Lo que trato de decirte con eso es que cuando un SO es usado por mucha gente "normal", que tú el universitario puedas arreglar un fallo en el kernel porque tienes el código y casualmente sabes hacerlo, no soluciona el problema de la inmensa mayoría de usuarios porque estos no están pendientes de los bugs, ni de sus soluciones ni de nada, pasan olímpicamente. Entonces ese fallo en sus ordenadores sólo será arreglado si un desarrollador oficial corrige y distribuye el parche vía actualización, vamos, como el windows update.
Yo no creo haber dicho "2% de dispositivos" sino "2% de escritorio" pero si tú te empeñas en meter esos "dispositivos" muy bien, metamos el 66% (creo) de móviles donde la gente se entera todavía menos y el párrafo anterior es todavía más cierto. Como tú quieras.
P.D: Los de windows se enteran todavía menos, al nivel de los de Android, por eso o hacemos que los "desarrolladores oficiales" solucionen el problema o que tú arregles un fallo a mi no me sirve de nada.
#23 Voy a dejarlo porque si no entras en razón no vamos a ninguna parte, pero...
Entiendes que los que mantienen los paquetes del kernel Linux son los empleados de cada distribución y que por tanto un parche de, digamos, Debian o Red Hat se incorporará cuando digan en Debian o Red Hat, ¿no?
Pues eso.
#24 Sí ¿y tú entiendes que no puedes ponerme al mismo nivel los empleados de cada distribución y un tercero cualquiera como tú, yo, o un universitario? ¿que los empleados de cada distribución son a su distribución prácticamente lo que los empleados de Microsoft son a windows?
#12 "Aunque en realidad eso lo hicieran los encargados del kernel, como ocurre en windows, pero que la realidad no te estropee tu ilusión."
Los ciclos de versiones del kernel Linux no contemplan los mismos tiempos para un hotfix que un proveedor comercial, por ejemplo Red Hat. Por eso el kernel de Red Hat tiene parches desarrollados por sus ingenieros, ya no sólo para esta clase de problemas sino para funcionalidades no estándares.
Así que te equivocas.
#16 "El kernel de Red Hat" "Los ingenieros de Red Hat" como "el kernel de windows" "los ingenieros de Windows"
¿dónde dices que me equivoco?
#17 De entrada, Linux es Linux. Si crees que un proyecto como éste, de millones de líneas de código, es diferente por añadir unas pocas miles... Pues qué decir.
Y dices que el problema se solucionó igual que ocurriría con Windows. Mentira. Los ciclos de desarrollo de Linux pueden no coincidir con los términos de soporte de Red Hat, por ejemplo, y que el código esté disponible permite a esta empresa solucionar el problema para sus usuarios antes de que salga un parche en la rama principal del kernel.
Eso no ocurrirá con Windows jamás.
#1 No, en Windows pasan otras muchas cosas más
#14 Con uname -m en un terminal te dirá la arquitectura.
Como? Vulnerabilidad que permite tomar el control del ordenador en linux? Pero pero pero pe pero estas cosas no pasaban solo en windooooooze????? Pero no puede ser!!! si linux era perrrrfeccto!!
#3 Casi perfecto es aquel que reconoce pronto sus errores, los admite, y le dice al mundo "yo fallé en esto y lo corregí así"
Ya'sta solucionao desd'hace tiempos.
Gracias a tener el codigo abierto se arreglan estos problemas en menos que canta un gallo. Con Windows ni te enteras porque hasta Microsoft te puede meter lo que le de la gana y nadie se daria cuenta si ellos quieren (quien sabe...).
Esto, junto a la enormeeeeeee potencia y flexibilidad que puede dar el disponer de todo el codigo fuente, es una de la mayores ventajas de Linux y el software libre en general. No son pocas las empresas y particulares que deciden toquetear sus Linux para adaptarlos o crearse nuevas funcionalidades que no existen en el kernel original. De esto Windows creo que tragas con lo que hay y poco mas.
Que alguien me de las instrucciones para saber si mi sistema es vulnerable a este bug. Primero necesito saber si tengo la versión del kernel vulnerable.
#8 En un terminal:
uname -r
#9 3.2.0-43-generic-pae
Pero no se si tengo la de 32 o la de 64 bits.
Pero creo que lo solucionaron en su momento, no?
#2 Si, el parche fue lanzado el mismo mes. Decir que solo afectaría a los kernels de 64 bits de las versiones 2.6.37 a la 3.8.8