Google parchea un fallo crítico en el uso del protocolo TCP en el kernel de Linux

Hace varios días, un grupo de ingenieros de Google identificaron un fallo crítico en el kernel de Linux relacionado directamente con la conectividad. Este fallo llevaba presente en el código del núcleo desde hace más de 10 años (siendo una de las vulnerabilidades más antiguas del mismo) y afectaba perjudicialmente sobre el rendimiento de las conexiones a Internet que utilizaban el protocolo TCP

[#35 Fingolfin]

Sensacionalista, no es ningún "fallo crítico", simplemente un fallo que hace que se tarde algo más en adaptarse a las fluctuaciones de la velocidad de la red. Nada de seguridad, ni "crítico". Teniendo en cuenta los años que se ha tardado en detectarlo, probablemente sea un caso muy poco habitual que apenas se note y no afecte a casi nadie. Es un fallo menor y totalmente irrelevante, pero la cobertura de los blogs de software, ya se sabe como es.

[#85 conversador]

#35 Anda, lee un poco http://www.securityfocus.com/bid/49289

[#89 Fingolfin]

#85 ¿Qué tal si te lo lees tú, y me cuentas qué tiene que ver ese enlace con el bug de esta noticia?

[#94 conversador]

#89 Con el bug de la noticia nada pero si muestra un informe de seguridad titulado "Linux Kernel TCP Sequence Number Generation Security Weakness" que relaciona secuencialmente las debilidades de seguridad TCP de los kernel de Linux. Como ves la lista es numerosa y justifica que Google se haya decidido a "parchear el fallo". Simplemente quería ponerte de manifiesto que antes de hace las afirmaciones de #35 calificando la noticia de "sensacionalista" y apuntarte tu momento de gloria tengo que discrepar en eso que afirmas de que simplemente es un fallo que hace que se tarde algo más en adaptarse a las fluctuaciones de la velocidad de la red. Se trata de un FALLO GORDO y que venía persistiendo en el tiempo y no es nada de "menor y totalmente irrelevante" , como afirmas, pero puedes pedir plaza en Google ya que sabes tanto de informática

[#97 Fingolfin]

#94 Hombre, más que tú desde luego que se, nada más verte. El fallo de la noticia, y el fallo de tu enlace, NO TIENEN NADA QUE VER, tratan de dos cosas distintas. El de la noticia no es ningún "fallo gordo", es un fallo menor e irrelevante, lo digo y lo reafirmo.

[#98 conversador]

#97 Si ya me he dado cuenta de que de esto sabes un rato

[#16 Desactivado]

#15 >muycomputer como fuente
>Que copia de la National Vulnerability Database
>Incluir Heartbleed como vulnerabilidad de Linux
>Ignorar que Windows tiene más HIGHs que Linux

Y te habrás quedado tan ancho, lo que hace la ignorancia.

[#3 earthboy]

Este va a ser el año de parchear un fallo crítico en el uso del protocolo TCP en el kernel de Linux en el escritorio.

[#8 Desactivado]

#3 Y por lo visto también sera el año de las gracietas absurdas y vacias de los primeros comentarios, aspiraciones a payasos o karmawhores...

[#44 earthboy]

#3 #8 Hombre, veo que tus "gracietas" complejas y llenas de contenido están a otro nivel. Tienes mucha clase.

Juzgan a unos padres por matar a su hijo de tres años tras meterlo en la lavadora

Y tu comentario:
-Bueno bueno, tampoco pongais verde a los padres, que digo yo que algo habria hecho el niño de marras....


juzgan-unos-padres-matar-hijo-tres-anos-tras-meterlo-lavadora/c013#c-13

Juzgan a unos padres por matar a su hijo de tres a...

Aspirantes a palurdos...

[#45 Desactivado]

#44 No te ofendas tontito, mis gracias buscan molestar no karma

[#59 Desactivado]

#45

[#38 Fingolfin]

#3 No es un fallo crítico, ni tan siquiera es un fallo de seguridad o un cuelgue. Sólo se trata de un problema de adaptarse a los cambios de velocidad que probablemente no afecte a casi nadie. La noticia era que Google había encontrado un bug con una década de antigüedad, el sensacionalismo de los medios hace el resto.

[#52 Ovlak]

#38 Amén

[#20 Shotokax]

¿"El kernel de Linux"? ¿Eso es el kernel del kernel? ¿El rekernel? ¿El subkernel?

Edito:

Aunque Linux es un sistema operativo no comercial y mantenido principalmente por la comunidad...

Linux no es un sistema operativo y hay sistemas operativos comerciales que llevan Linux. Otra cosa es que sea libre, pero la disyuntiva libre o comercial es incorrecta.

Vaya mierda de artículo, y la página presume de ser un portal sobre redes.

[#32 llou]

#20 Linux es un sistema operativo. Cumple con todas las caracerísticas que se le pide a un sistema operativo y se puede ejecutar de forma totalmente autónoma.

https://es.wikipedia.org/wiki/Sistema_operativo

[#33 Shotokax]

#32 ¿ah, sí? Mira, descárgate Linux y me dices si puedes instalarlo y usarlo como sistema operativo completo. Aquí te dejo el enlace:

https://www.kernel.org/

Me pregunto por qué en el tema de Linux habla tanta gente si tener ni puta idea. Es peor que en política.

[#34 llou]

#33 Perfectamente, implemento un programa en C que se arranque en vez del init y tira millas si ningún problema.

[#56 jixbo]

#34 Vamos, lo típico que tienes que añadir a todos los sistemas operativos antes de arrancar

[#62 llou]

#56 No se si entiendes el concepto de sistema operativo. Es una capa de abstracción entre el software y la máquina. Linux cumple por si misma esa definición.

[#69 jixbo]

#62 definición de la wikipedia de sistema operativo:
...programa o conjunto de programas de un sistema informático que gestiona los recursos de hardware y provee servicios a los programas de aplicación...
La definición que tu das es la de kernel únicamente.
El kernel es sólo una parte imprescindible del sistema operativo, pero no es un sistema operativo.

[#70 llou]

#69 Gestiona los recursos de hardware y provee servicios a los programas de aplicación. Cosas como el sistema de archivos, la red y todo lo demás son los servicios. El núcleo es el sistema operativo.

[#63 Hanxxs]

#34 ¿Y cómo interactuas con el núcleo, si puede saberse?

[#65 llou]

#63 ¿A través de las llamadas al sistema?

https://es.wikipedia.org/wiki/Llamada_al_sistema

[#67 Desactivado]

#65 La respuesta correcta que estaban esperando es: "Lo hace un mago".

[#71 Hanxxs]

#65 Sin sistema gráfico, sin shell, muy interactivo, ya veo. Tu debes ser de los que pican el código en ensamblador, supongo.

[#72 llou]

#71 Puedes programarlo en C sin problemas generar una imagen y arrancarla. Para una cosa sencilla, por ejemplo devolver un un ping en una red para que quieres mas.

[#74 Hanxxs]

#72 Bueno, aceptamos responder con un ping como interactividad.

[#75 llou]

#74 Me da igual lo que acepteis o no, estrictamente hablando lo es.

[#80 Desactivado]

#79 Él (#72) es el que te ha dado una lección, tú esperabas pillarle con tus tecnicismos y al final ha sido que no.

[#81 Shotokax]

#80 vale, que no tienes ni puta idea y no has entendido la conversación. Te lo voy a contar, aunque, como vas de pedante, no sé si tienes interés en saber de qué iba o solo en corregir por corregir.

No le he contestado porque su último comentario era de cachondeo. Decía que si se programa algo que corra por encima del núcleo tiene un sistema operativo o lo puede hacer correr. Lógico, y si te programas GNOME tienes un entorno de escritorio, pero eso no quiere decir que Linux incluya el entorno de escritorio, que era la discusión.

Deja de hacer el ridículo, por favor.

[#82 Desactivado]

#81 ¿Insistes?

[#83 Shotokax]

#82 a ti te falta un verano, chaval.

[#87 Desactivado]

#34 y ese programa en C con el kernel compondrán el SO. El kernel sólo no es un SO. Linux es un Kernel, y con GNU o Android o el que sea, forma el SO.

[#88 llou]

#87 No de acuerdo a la definición de wikipedia.

Un sistema operativo (SO o, frecuentemente, OS —del inglés Operating System—) es un programa o conjunto de programas de un sistema informático que gestiona los recursos de hardware y provee servicios a los programas de aplicación, ejecutándose en modo privilegiado respecto de los restantes (aunque puede que parte de él se ejecute en espacio de usuario).

[#90 Desactivado]

#88 la parte que se te escapa en esa definición es "provee servicios a los programas de aplicación".

Y no seas pelma, que es de primero de carrera, y fácil de entender hasta por mi abuela.

[#91 llou]

#90 El kernel provee todos los servicios. Sistema de archivos, red, memoria, que mas quieres.

[#93 Desactivado]

#91 venga chaval, un poco de lo básico, que te hace falta:

https://es.wikipedia.org/wiki/Demonio_%28inform%C3%A1tica%29

https://es.wikipedia.org/wiki/Proceso_%28inform%C3%A1tica%29

Te los lees y luego me rebates lo que quieras.

[#96 llou]

#93 Que limitados sois los informáticos. Dejo la conversación aquí porque os da muy poco la cabeza.

[#99 Desactivado]

#96 ingeniero industrial con postgrado y tres másteres, entre los que se incluye uno muy muy relacionado con esto, pero bueno, montate tu película...

[#102 llou]

#99 Lo que eres es un cantamañanas, que colecciona títulos porque no desarrolla nada.

[#104 Waskachu]

#99 jope... Haz otro master si acaso... Yo no me arriesgaría a comentar en meneame sin, como mínimo, 4 masters

[#64 Desactivado]

#33 Qué rabia dan, sólo deberían dejar entrar en Internet a los gurús.

[#76 Shotokax]

#64 yo no soy ningún gurú. Hablo de lo que más o menos sé.

Me gustan los proverbios chinos. Hay uno chino que dice: "El hombre sabio tiene los ojos y las orejas grandes y la boca pequeña".

[#78 Desactivado]

#76 Gurú:
👌 Decir a los demás que no tienen ni puta idea
👌 Dar lecciones de manera airada
👌 Utilizar proverbios chinos

[#79 Shotokax]

#78 tú eres el primero que estás dando lecciones, paliza.

[#46 Desactivado]

#20 Es un portal sobre redes pero su admin no tiene puta idea y contrataba falsos autonomos.
Algunos usuarios nos piramos cuando miramos el percal.

[#17 anv]

#10 Sí, tomó 10 años pero lo descubrieron. ¿Preferirías que no lo hubieran descubierto nunca o es que 10 años te parece mucho?

Si te parece mucho 10 años, tendrías que preguntarte por qué pasó tanto tiempo. Lo que ocurre es que no es un problema fácilmente notable. No afecta al funcionamiento en general porque el sistema funciona, aunque no de manera óptima en casos extremos e incluso cuando falla funciona mejor que un servidor windows (por eso se usa tanto linux en servidores). Cuando hay poco tráfico no falla, y cuando hay mucho tráfico es difícil ver el problema entre tantos paquetes.

Ese es el motivo por el que se tardaron 10 años. El motivo por el que el error no quedó ahí para siempre como habría ocurrido en un sistema cerrado es que el código puede revisarse y corregirse.

[#12 Desactivado]

#10 Hay errores de Windows que se han tirado más años (y los que quedará por descubrir). Esa ventaja es absolutamente cierta, quien lo usa puede leer el código y encontrar un error y arreglarlo (como precisamente ha pasado con esto). Otra cosa es que sea fácil.

Este error jamás se habría encontrado ni solucionado en Windows.

[#15 Desactivado]

#12 Por eso Windows es menos vulnerable http://www.muycomputer.com/2015/02/23/mac-os-x-ios-y-linux-son-mas-vulnerables-que-windows

[#6 Magankie]

#4 Felicidades

[#13 Desactivado]

#6 No alimentes al troll.

[#51 anv]

#13 No seas aguafiestas. A veces es divertido.

[#22 GoDie]

TCP Cubic no ninguna implementación TCP standard.

https://en.wikipedia.org/wiki/CUBIC_TCP

[#27 Waskachu]

#22 justo lo que había dicho yo en #11

[#1 conversador]

Más datos sobre el kernel de Linux
Imagen del Kernel de linux

Imagen del Kernel de linux

Publicada por fin la versión 4.8.15.16.23.42 del kernel Linux [EN]

Publicada por fin la versión 4.8.15.16.23.42 del k...

[#36 noexisto]

#1 Fakeame?

cc@LogMe

[#2 Magankie]

Será cuestión de actualizar mi Debian de la 2.6 a la nueva...

[#4 Desactivado]

#2

Siempre me ha parecido que todos los que dicen "mi debian", "mi ubuntu", "mi gentoo" , etc etc ...son gilipollas

[#37 Pijus_Magnificus]

#4 ¿Y si a mi me suda mis pelotas tu comentario?

[#55 Desactivado]

#4

[#86 abnog]

#4 Entonces, tú habiéndolo dicho tres veces...

[#11 Waskachu]

Un momento un momento. Que haya un error crítico en el protocolo TCP no indica que el error sea de Linux en sí (GNU/Linux). Es un error aislado de una parte opcional de software adicional... Y como veis el método de correción funciona. Sin ir más lejos yo ya he parcheado mi Gentoo.

[#23 GoDie]

#11 Innecesariamente por que a ti ni te va ni te viene.

[#24 Waskachu]

#23 no entiendo tu comentario.

[#25 GoDie]

#24 Pues después de votar negativo a un comentario que no entiendes no esperes nada.

[#26 Waskachu]

#25 perdona se me fue el ratón. Debe de ser un fallo del TCP. Voy a parchear otra vez del kernel. Pero bueno que te vote negativo a ti ni te va ni te viene.

[#28 GoDie]

#26 Pues bien me la suda ciertamente, aquí tienes otro, para que te sientes mejor contigo mismo.

[#29 Waskachu]

#28 que tenga otro a ti ni te va ni te viene muchacho.

[#92 Desactivado]

#23 CUBIC TCP is implemented and used by default in Linux kernels from 2.6.19 to 3.1.

https://en.m.wikipedia.org/wiki/CUBIC_TCP

Ante una congestión de tráfico en cualquier Linux entre esas versiones, tiene relevancia. Listillo...

CC #11

[#95 GoDie]

#92 Si no entiendes lo que lees para que te metes.

[#100 Desactivado]

#95 hay que estar muy acomplejado para ir de gurú por la vida (sin tener ni puta idea)

[#101 GoDie]

#100 Tu sabrás.

[#41 borteixo]

cuidado con ese parche no vayan meter un backdoor de la NSA así al despiste

[#31 Desactivado]

#10 Ig no ran te

[#40 dphi0pn]

#18 Evitar arreglar, la lógica del vago hackeado

[#48 anv]

#40 En este caso es una lógica empresarial: ganar lo más posible y gastar lo menos posible. Si ya te vendí el producto, ¿para qué gastar en arreglarlo si no me pagas nada por ello? Sólo si el problema amenaza con afectar las ventas futuras valdrá la pena solucionarlo.

[#50 dphi0pn]

#48 No estoy hablando de la lógica de microsoft/apple, sino de las empresas que usan soft privativo y los sistemas de los anteriores en concreto.

[#54 anv]

#50 Ah, pero si sigues el hilo verás que la cosa viene Microsoft que tardó 19 años en arreglar una vulnerabilidades.

[#19 Desactivado]

#18 Claro hombre, asi se lo ponen mas fácil a la NSA

[#77 dudo]

#19 No importa, la NSA es un sistema cerrado asi que debe tener muchos fallos.

[#53 Benjamin_Linus]

No es un *fallo critico* ni de broma. Negativo al canto, sorry. Además, ni un enlace dentro del articulo a la fuente original (esperaba algún enlace a LWN o a la LKML por lo menos).

[#68 Desactivado]

Adoro las discusiones de linuxeros.

[#5 Desactivado]

Otro fracaso de millones de ojos revisan el código.

[#7 Desactivado]

#5 ¿Tú sabes lo que es el código del kernel? Que puedas verlo no significa que vayas a encontrar el error en millones de líneas de código (literalmente) y a menudo bastante complejo.

Cómo os gusta a los mindundis ningunear el trabajo de los demás que jamás sabríais hacer.

[#10 Desactivado]

#7 A mí no me cuentes nada; díselo a los que están siempre citando como una gran ventaja que evita errores el disponer del código y que hay mucha gente que lo revisa.

#9 Solo 10 años de nada

[#60 Hanxxs]

#10 Ya, ahora encuentra un fallo de seguridad crítico en Windows XP y a ver quien te lo arregla sin acceso al código.

[#9 anv]

#5 Al contrario: es otra muestra de que el código abierto permite que tarde o temprano alguien encontrará los errores. ¿O acaso piensas que un error así en un sistema cerrado se habría solucionado algunaa vez?

[#14 Desactivado]

#5 Como esto no http://www.bbc.com/mundo/ultimas_noticias/2014/11/141112_ultnot_tecnologia_microsoft_parche_windows_office_az? Windows tiene una vulnerabilidad durante 19 años, para una empresa que vale mas de 600.000 millones de dolares deberían mirarse lo , el fallo llevaba desde Windows 95 hasta Windows 10

[#18 anv]

#14 Justamente, la empresa vale tanto porque no gastan dinero "inútilmente" arreglando cosas que puedan evitar arreglar.

[#21 GoDie]

#5 Imaginate lo que hay en el codigo cerrado que nadie revisa

[#30 PythonMan8]

#5 En realidad nunca ha habido millones de ojos revisando el código. Algunos aspectos del kernel son demasiados complejo para ser revisado por más de un centenar de personas en todo el mundo. Lo que garantiza el código abierto en este caso es que "el genio" que trabaja en estos subsistemas del kernel pueda formarse desde joven teniendo el acceso al código.
Un fallo de este tipo sería/es prácticamente indetectable en Windows pues no hay personal cualificado suficiente para trabajar en él. Muy pocos empleados tienen acceso al código del kernel de Windows y para cuando llegan a tener acceso están demasiado mayores como para dominarlo como pasaría si empezasen de jóvenes.

Es el mismo caso que los idiomas. Cuanto más joven se empieza mejor se habla. Si tuviesemos que esperar a tener permiso de Microsoft para empezar a estudiar un idioma no hablaríamos ni dos frases de inglés.

[#43 Desactivado]

#30 El windows su Rwin es dinamico desde el windows vista y linux me acuerdo que se vendia en los tiempos xp como dinamico cuando estaba buegeado.

[#84 Comrade]

#30 ¿En serio no hay nadie (o solo unos pocos) en Microsoft capaz de entender el Kernel? guau, me dejas francamente sorprendido con tal aseveración. Sinceramente, creo que tanto código opensource como privativo puede ser revisado el mismo número de veces a lo largo del tiempo, siempre y cuando se trate de un desarrollo vivo. ¿A una empresa con código privativo le interesa que solo unos pocos privilegiados accedan a la parte esencial de su producto? Apostaría a que cualquiera que participe en el desarrollo del SO en Microsoft puede acceder a cualquier parte del código, otra cosa es cómo gestionan los arreglos, a quién se reporta, cuándo se lanzan al público, si interesa realmente arreglarlo, etc...

[#103 Desactivado]

#84 La diferencia es bastante simple:

Yo, que no trabajo en el desarrollo de Linux, cuando he tenido algunos problemas que afectaban al kernel, he pillado y he mirado el código. No he encontrado fallos graves, ni he parcheado problemas de seguridad, pero esas horas que he metido bien puedes contarlas como una revisión de código. Igual que yo, millones de personas en todo el mundo todos los días, que trabajan en cosas distintas pero que aún así tienen capacidad para mirar uno u otro cacho de código.

En Microsoft, acceso al código del kernel a lo mejor tienen unos pocos miles, que se dedican a mirar solo los problemas más importantes en función de lo que hayan decidido sus jefes o sus equipos de trabajo. Los millones de personas que puedan tener un problema en un momento puntual, con experiencia suficiente y que podrían mirar el trocito de código que les afecta personalmente... a la mierda, se pueden dar con un canto en los dientes.

El kernel, y muchos otros componentes básicos de un sistema, son ese tipo de software básico y popular en el que ninguna empresa puede competir contra la gran cantidad de usuarios-desarrolladores capacitados para revisarlo. En software específico para no-desarrolladores, ahí sí pueden competir; en componentes básicos, es simplemente imposible.

[#39 dphi0pn]

#5 Al menos se revisa

[#47 joffer]

#5 te voy a poner un palmface

[#49 jixbo]

#5 Si eso pasa en un programa de código abierto imagina lo que habrá en los códigos cerrados y no supervisados.
Otra ventaja de que un programa sea abierto es que no puede estar diseñado para robarte de forma premeditada, sería muy cantoso. Sin embargo muchos programas de código cerrado si tienen funcionalidad para robarte.

[#58 Desactivado]

#5 Dirás "otro éxito de la posibilidad de revisar y contribuir al código":
- Los ingenieros de Google han detectado un problema que disminuía el rendimiento en TCP, lo han corregido y estará en breve en los kernels de todo el mundo, mejorando el rendimiento desde servidores web, smartphones, superecomputadores y pcs con Linux de todo el mundo.

[#42 Desactivado]

Pero primero le habrán pedido permiso a Torvalds ... ¿no?

[#57 jixbo]

#42 todos los parches los supervisa linus.

[#61 anv]

#42 No es exactamente así: Tu encuentras el fallo, escribes el parche para solucionarlo y avisas a los desarrolladores. Entonces Linus lo revisa y si le parece bien lo incorpora al kernel. Si no le gusta explica por qué y ya tendrás ocasión de mejorarlo si quieres.

[#66 Desactivado]

La noticia es completamente sensacionalista y opuesta a la realidad:
- No existe ningún "fallo crítico" (no hay ningún problema de seguridad o cuelgue).
- Se ha encontrado un problema de rendimiento, se ha corregido y mejorado, y los ingenieros han sido felicitados por su solución.

[#73 amospalla]

Desde cuando un tema de rendimiento es una vulnerabilidad critica?

Mantenida por la comunidad? Sera por la comunidad de empresas que aportan codigo lo cual no supone porcentaje precisamente bajo. Dicho asi suena a que lo mantienen pescadores y carpinteros en su tiempo libre, los cuales no creo que entre otras cosas tengan acceso al hardware necesario para escribir drivers.

Vaya pantochada.