Portada
mis comunidades
otras secciones
#4:
Ya parcheado en Debian Stretch y Jessie, en Buster en las próximas horas.
#2:
Justo hoy estaba haciendo un poco de documentacion para el trabajo sobre esto.
Que servidores tenemos afectados con version linux 2.6.25 o superior (solo hay uno que es tan viejo que se salva
)
Que servidores tenemos afectados con version linux 2.6.25 o superior (solo hay uno que es tan viejo que se salva
)
#11:
#9 no compromete datos exponiendolos hacia fuera, pero puede comprometer datos corrompiendolos.
Ten en cuenta que un kernel panic implica congelar la ejecución de cualquier código. Hoy dia todos los FS suelen usar journaling y no se escribe directamente en disco, con el fin de aumentar la eficiencia. Depende de lo que haga ese servidor, imagina que es una BBDD, las consecuencias pueden ser bastante malas.
Ten en cuenta que un kernel panic implica congelar la ejecución de cualquier código. Hoy dia todos los FS suelen usar journaling y no se escribe directamente en disco, con el fin de aumentar la eficiencia. Depende de lo que haga ese servidor, imagina que es una BBDD, las consecuencias pueden ser bastante malas.
#17:
#12 #9 La seguridad no es sólo la seguridad de los datos. También es mantener el sistema operando adecuadamente. Un kernel panic altera el entorno y provoca daños de forma inmediata como pérdida de disponibilidad.
Imagina que ese Linux está controlando robots industriales, un sistema de control militar, etc.
Imagina que ese Linux está controlando robots industriales, un sistema de control militar, etc.
#3:
No pude ser, ¿ un Ping de la muerte? A mis años?
Comentarios
Ya parcheado en Debian Stretch y Jessie, en Buster en las próximas horas.
#4 Y en RedHat, en SuSE, etc. desde unas pocas horas antes de la publicación del CVE.
Por cierto, los terminales Android ¿tienen algún "servidor" TCP de serie?... porque con esos lo tienen claro con las actualizaciones...
#3 Exacto. Un PoD TCP en toda regla.
#6 No estoy seguro de que en android esa funcionalidad este activa con /proc/sys/net/ipv4/tcp_sack diferente de 0
Justo hoy estaba haciendo un poco de documentacion para el trabajo sobre esto.
)
Que servidores tenemos afectados con version linux 2.6.25 o superior (solo hay uno que es tan viejo que se salva
No pude ser, ¿ un Ping de la muerte? A mis años?
Más y mejor info:
https://unaaldia.hispasec.com/2019/06/sack-panic-dos-a-traves-de-tcp-ip-en-el-kernel-linux.html
https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md
#12 cuando reinicias, los programas de cierran adecuadamente, no es un reinicio en caliente.
Qué faena. Justo ahora que era el año de Linux en el escritorio.
No tengo yo muy claro que a un bug cuya consecuencia más crítica sea un reinicio se le pueda llamar brecha de seguridad, pues no deja expuestos los datos de nadie, si que es cierto que es un fallo crítico que puede comprometer la disponibilidad, pero no dato alguno. Es cierto que de las 3 una si que permite obtener datos, pero no es a la que se le da más bombo.
#9 no compromete datos exponiendolos hacia fuera, pero puede comprometer datos corrompiendolos.
Ten en cuenta que un kernel panic implica congelar la ejecución de cualquier código. Hoy dia todos los FS suelen usar journaling y no se escribe directamente en disco, con el fin de aumentar la eficiencia. Depende de lo que haga ese servidor, imagina que es una BBDD, las consecuencias pueden ser bastante malas.
#11 El journaling protege, ni hace más vulnerable.
#11 Me parece que confundes journaling con caché.
O no tienes claro lo que es el journaling que al contrario de lo que dices protege las particiones de errores a través de un registro constantemente actualizado en disco precisamente para salvaguardar los datos.
#28 El journaling es simplemente anotar que transacciones han terminado y cuáles quedaron pendientes después del KP o del reinicio, para realizarlas o no en base a una serie de variables. Y efectivamente, confunde journal con caché.
#11 Gracias por ser el único que aunque discrepe conmigo me ha manifestado su opinión con educación y respeto.
#9 pues anda que no se necesitan reinicios para un montón de cosas... hablar sin saber es... bueno en fin
#12 #9 La seguridad no es sólo la seguridad de los datos. También es mantener el sistema operando adecuadamente. Un kernel panic altera el entorno y provoca daños de forma inmediata como pérdida de disponibilidad.
Imagina que ese Linux está controlando robots industriales, un sistema de control militar, etc.
#19 #12 #15 #14 #12
Que listos que sois todos, con vuestro halo de prepotencia y vuestra falta de comprensión lectora.
En ningún momento he dicho que no sea una brecha seria, y que no afecte a los datos, y que no pueda corromper los datos (aunque no tiene porqué corremperlos).
He hablado de seguridad en términos de robo de datos, no de que un fs o una BD se corrompa, para mi eso tiene más que ver con la disponibilidad y la integridad de los datos que con la seguridad, aunque admito que comparte digamos "raíz".
Pero claro, aunque llevo 15 años en esta mierda, enseguida soy tonto y no tengo ni puta idea de lo que hablo. Me gustaría saber cuantos de vosotros se han tenido que levantar a las 3 de la mañana para ir a apagar "fuegos" .
#43 pues nada oye... No corrijas la vulnerabilidad y levántate a las 3 de la manañana todos los días por que todo ha dejado de funcionar... Un servidor tiene como una de sus funciones más importantes sino la más dar servicio y que lo puedan resetear sin más elimina de por si la función de servidor! Por supuesto que pudieran robar datos aumentaría el problema a nivel exponencial pero de por si un servidor que se cae sin más ni es servidor ni es nada
#47 ¿Quien ha dicho que yo no corregiría la vulnerabilidad? Si te has leído el artículo, verías que dice que la vulnerabilidad puede ser usada para robar datos, y no es verdad. FIN.
¿Que si es un equipo crítico obviamente que todo falle es un problema de seguridad? Pues claro, por eso digo que comparten raíz. Ahí puedes meter firewalls, ordenadores que controlen procesor críticos, sanidad... etc.
¿Que puede aligerar el camino? Pues claro, si tiras el firewall de una empresa allanas el camino, pero no lo tienes ya todo hecho, ergo la vulnerabilidad no permite robar datos de per se, hace falta que falle algo más.
Pero yo me ciño a lo que el artículo dice, y todo el rato habla de un "atancante que robará datos".
#49 chico en serio háztelo mirar. Prepotentemente afirmas que no tenemos capacidad lectora y que somos prepotentes.
Leete el artículo y o usar el buscar en página NO SE USA LA PALABRA ROBAR NI DATOS ni se insinua nada de robo de datos NADA DE NADA, en absoluto, ni remotamente así que de donde sacas que el artículo lo dice?
#49 no dice toso el rato atacante, lo dice una sola vez y dice que atacante podrá realizar un Dos, afirmas saber de lo tuyo? Dos no es robar datos! Fin Fin Fin Dos es denial of service en cristiano tirar abajo una maquina. En serio si no sabes no hables y si no has leído menos aun
#49 quillo que? para decir que no lo leiste ni medio bien no me vas a responder?
#46 #43 ya veo q tu de prepotencia entiendes
#43 pues no, no tienes ni puta idea. Un montón de brechas de seguridad obtener Shell remota requieren de reinicios. Reinicios que pueden no ocurrir en años. Un método de reiniciar el sistema es una brecha de seguridad importantísima por que podría facilitar o permitir un acceso remoto. Ni puta idea tienes.
#9 si fuera en Windows estarías tirando te de los pelos, que te puedan tirar el servidor abajo es muy grave puede haber pérdidas de datos
#14 servidores Windows dice
#18 donde?
#18 En mi curro tenemos un servidor Windows. Jaque Mate.
#33 Ah, así que érais vosotros los del servidor Windows
#36 El día que compramos la licencia de Windows Server nos llamó Steve Ballmer en persona para darnos las gracias. La próxima vez espero la llamada de Satya Nutella.
#9 Afortunadamente tu concepto de ciberseguridad no es el que tenemos los que nos dedicamos a ello.
#15 ¿tu que sabes a que me dedico? igual te quedarías jodido, gilipollas.
#46 Imagino que a algo que no solo tiene nada que ver con ciberseguridad, pero que tampoco requiere de educación.
#9 ¿Tú eres tonto? ¿Te has parado a pensar que las máquinas que más frecuentemente reciben esos ataques son los cortafuegos y los servidores bastion? ¡Si esos caen dejan expuestas redes enteras!
#19 tampoco necesitas insultar
#22 lo que menos necesitaba yo era enseñarle algo
#23 lo que menos necesitamos todos es tus insultos, las formas te hacen perder la razon
#24 Tú cuando meas te la sujetas con un papel de fumar, ¿verdad?
#26 tu con papel de lija esta claro
#19 Hombre si está bien hecho lo que no se podría es acceder, no debería quedar nada expuesto. Pero si hablamos de sistemas críticos y se ponen a reiniciarlos todo el rato, bueno no puede ser por mucho journaling fs que lleven.
Todos los días salen vulnerabilidades, se arreglan y punto.
Esta en concreto es importante porque.... ¿? ¿Porqué está el nombre de Netflix? Vaya sensacionalismo. Si se publicasen noticias de las vulnerabilidades de Windows en Menéame, no habría cabida para nada más...
Que cracks los de Netflix!
Como cualquier vulnerabilidad, ahora que se sabe parece algo sencillo y hasta parece ridículo que nadie lo haya visto antes (al menos no públicamente)... Chapó por ellos
Netflix usa servidores Linux, porque Apple no existen y Windows no son de su confianza, es otra interpretación.
/con/con
#5 a mi me ha recordado más a:
https://en.m.wikipedia.org/wiki/Ping_of_death
Aunque me gusta mucho Linux y el software libre, creo que todos debemos aceptar la realidad.
En esta época ya no importa si sale KDE XP o GNOME Milenium. Cuando Linux tuvo la oportunidad de ganar un poco de mercado en el escritorio, perdió tiempo y esfuerzos duplicando el trabajo ya hecho. Si KDE y GNOME hubiesen trabajado hombro con hombro para dotar a Linux de un entorno de escritorio, seguramente tendríamos una interfaz gráfica de usuario decente. Pero en lugar de eso tenemos dos mediocres intentos que no pueden usarse a menos que se tenga 1Gb de RAM y todo el tiempo del mundo para configurar el protector de pantalla.
Mientras ambos equipos peleaban infantilmente, Microsoft consolidó su posición como líder en el mercado del cómputo de oficina dandole a los usuarios lo que pedían: una interfaz gráfica de usuario intuitiva que les permitiera ser productivos sin tener que memorizar el manual (Tan grande como una bíblia!) de vi o de TeX.
Y no sólo eso, M$ también llevó la facilidad de uso y eficiencia que caracteriza a sus productos a los servidores con el novedoso sistema operativo orientado a internet Windows 2000. Esto tiene como resultado que a medida que las empresas aumentan su productividad y ganancias; UNIX y Linux huyen en desbandada hacia otros mercados.
Cómo es posible que las corporaciones no usen Windows 2000 en lugar de otras soluciones shareware? Cualquier ejecutivo sabe que a la larga lo barato sale caro. Haciendo cuidadosos análisis numerosos estudios han comprobado que el costo total de propiedad es mayor en los sistemas Linux y UNIX debido principalmente a la falta de sistemas de capacitación y certificación estandar para el personal que opera estas plataformas.
Según nos enteramos recientemente, la Universidad Nacional Autónoma de México seguirá la innovadora iniciativa .NET de Microsoft, y después seguirán otras en otros países. Incluso existe la posibilidad que el campo del software de código abierto sea invadido usando projectos semi-libres como caballos de Troya, como es el caso de Mono y DotGNU.
Todo esto manda el mensaje que mientras el software libre tiene su lugar, ciertamente no es en los servidores de producción de corporaciones importantes, y menos en los centros de investigación y aprendizaje, donde se prueban hoy las tecnologías del futuro.
Si Linux y el software libre en general no luchan para democratizar su uso para el grueso de la población, dentro de poco veremos hecha realidad la visión del mundo de la computación que comparten Bill Gate$, Richardo Stalinmal, Steve Yobs, entre otros: A dónde quieres que te de permiso de ir hoy?
Gracias por su atención
#27 dios mío, han abierto la jaula de /.
#27 Te has gastado unas pasta en certificaciones Mocosoft y ahora te las estas comiendo con papas.
#27 ¿Windows 2000? Ese tipo de FUD no funcionó en los años '90 así que imagínate el ridículo que haría hoy. Por cierto Windows Server 2019 ya incorpora Windows Subsystem for Linux (WSL) . Imagina por qué...
Pues eso, que la vulnerabilidad facilita el camino porque puedes provocar un reinicio pero no puede ser usada por si sola para robar datos, necesitarás una brecha más.Ya se que es una brecha de seguridad, no lo he negado en ningún momento, simplemete el artículo me pareció que quería decir más que podía por si sola provocar un robo de datos, y no es verdad.
En principio las principales distribucones ya tenían solucionado esto.
Sin embargo se puede mitigar con
echo 0 > /proc/sys/net/ipv4/tcp_sack
¿Es malo deshabilitar tcp sack? En realidad según leo parece que realmente mejora las cosas en la mayoría de los casos. El TCP Sack permite reenviar partes intermedias de un grupo de paquetes si es que no llegan. Lo que pasa es que hoy en día las comuncaciones son muy estables así que casi nunca se pierden paquetes y deshabilitando esto se consigue cargar menos al sistema.
Es lo bueno del software libre..., que muchísimos expertos informáticos y programadores del copón que hacen cosas chulas en la consola usando tuberías y tal pueden inspeccionar el código y detectar posibles fallos..., ah no, ¡espera!
#25 Jajaja. Todo el mundo puede inspeccionar el código, pero casi nadie lo hace.
Sabeis que paquete de debian 9 y versión es en el que ya viene corregido?
#30 Me autorespondo: 4.9.168-1+deb9u3
Toda la info en debian: https://www.debian.org/security/2019/dsa-4465