#2:
Leído hace dos minutos y tachan, ya están actualizándolo. Igualito que el windows.
#17:
#5 que si te conectas por consola de comandos a un servidor chungo te pueden robar las contraseñas de otros servidores. Lo más simplificado posible.
#13:
Theo de Raadt1, fundador de OpenBSD y OpenSSH, y el mismo que anuncia originalmente esta vulnerabilidad en la lista de correos. Es famoso por ser exigente en el manejo del software y la comunidad alrededor, de este enfoque se ha derivado la fama de OpenBSD como un sistema "seguro". Para que te hagas a la idea, Linus Torvalds lo ha descrito como una persona dificil de tratar, me imagino que este chiste no debio agradarle mucho.
Tenia entendido que los procesos para aceptar codigo en OpenBSD eran muy estrictos, hasta llegar al punto de limitar el hardware soportado en este SO. Tal vez las cosas han cambiado, tal vez ha sido causa de un descuido. Creo que @Ander_ esta mas enterado sobre esta comunidad.
#18 El otro día leí a uno por aquí que se atrevió a afirmar que windows es el sistema más seguro que existía... Claro está que si esperar meses a que micro$osft solucione el agujero es muy fiable. Por estas cosas me gusta el software libre.
Theo de Raadt1, fundador de OpenBSD y OpenSSH, y el mismo que anuncia originalmente esta vulnerabilidad en la lista de correos. Es famoso por ser exigente en el manejo del software y la comunidad alrededor, de este enfoque se ha derivado la fama de OpenBSD como un sistema "seguro". Para que te hagas a la idea, Linus Torvalds lo ha descrito como una persona dificil de tratar, me imagino que este chiste no debio agradarle mucho.
Tenia entendido que los procesos para aceptar codigo en OpenBSD eran muy estrictos, hasta llegar al punto de limitar el hardware soportado en este SO. Tal vez las cosas han cambiado, tal vez ha sido causa de un descuido. Creo que@Ander_ esta mas enterado sobre esta comunidad.
OpenBSD es muy estricto, prima la seguridad y estabilidad por encima de todo, incluso la velocidad.
De hecho han creado la función pledge() para que solo pueda acceder a según qué llamadas del sistema y en caso de que lo intente en los demás por algún intento de exploit, "casque" (es más bien un cierre forzado, la señal para matar un programa es SIGKILL).
A process which attempts a restricted operation is killed with an uncatchable SIGABRT, delivering a core file if possible.
#4 se necesita que el cliente haga uso de esa función y que el servidor esté comprometido. Es serio, como dice #7, pero dentro de una organización debería estar contenido.
¿Desde cuando conocía esta vulnerabilidad la nsa?
¿El olvido de incluir esta funcionalidad que no habia sido "activada" en el codigo del server, es accidental?
¿Hay registros de quienes exactamente hicieron los commit de estos asuntos?
¿Quizás les suplantaron?
Lo que si veo luego es que el parche o codigo debia ser auditado. No sé en qué consiste esa auditoria o pruebas de calidad para aceptar un parche en la rama main y en la versión release.
"It's not in the patch which was mentioned on this list. I don't want it
to be a moving target so I'm not going to add any features to it until
it's been audited and accepted. But please feel free to enhance it and
it can be added when/if this patch is committed.
/Andreas"
Quizas este bug debería servir para revisar esos procesos o procedimientos de auditoria.
Para tranquilizar a la gente: el problema está en el cliente, no en el servidor. Y sólo es explotable si el cliente se conecta a un servidor mailicioso. O sea que no hace falta correr a ajustar la configuración de todos los servidores.
Resumen para vagos:
A. Un servidor malicioso podría llegar a robarte la clave privada de SSH por culpa del roaming del cliente: solución desactivarlo o actualizar el cliente.
B. Un servidor malicioso podría ejecutar código en tu máquina pero la conexión tiene que usar ProxyComand y ForwardAgent o ForwardX11. Cosa un tanto enrevesada.
Woah, super interesante para aprender nuevas cosas.
Por cierto, ¿esto tiene algo que ver con la revisión de seguridad que OpenBSD empezó con LibreSSL (desde OpenSSL) o con el dinero nuevo destinado a aplicaciones fundamentales de seguridad de Google, Linux Foundation etc?
Comentarios
Leído hace dos minutos y tachan, ya están actualizándolo. Igualito que el windows.
#2 En una Mint LTS que tengo instalada se actualizó ayer sobre las tres de la madrugada A esta misma versión que pones en la imagen.
#2 Leído hace dos minutos y descubierto hace dos o tres días. Igualito que windows, que no ha tenido el fallo, y que se actualiza semanalmente.
#18 El otro día leí a uno por aquí que se atrevió a afirmar que windows es el sistema más seguro que existía... Claro está que si esperar meses a que micro$osft solucione el agujero es muy fiable. Por estas cosas me gusta el software libre.
#2 A mi también me sale . Eso si que es rapidez.
Theo de Raadt1, fundador de OpenBSD y OpenSSH, y el mismo que anuncia originalmente esta vulnerabilidad en la lista de correos. Es famoso por ser exigente en el manejo del software y la comunidad alrededor, de este enfoque se ha derivado la fama de OpenBSD como un sistema "seguro". Para que te hagas a la idea, Linus Torvalds lo ha descrito como una persona dificil de tratar, me imagino que este chiste no debio agradarle mucho.
Tenia entendido que los procesos para aceptar codigo en OpenBSD eran muy estrictos, hasta llegar al punto de limitar el hardware soportado en este SO. Tal vez las cosas han cambiado, tal vez ha sido causa de un descuido. Creo que@Ander_ esta mas enterado sobre esta comunidad.
1: https://en.wikipedia.org/wiki/Theo_de_Raadt
#13 Estaba sopa >_<
OpenBSD es muy estricto, prima la seguridad y estabilidad por encima de todo, incluso la velocidad.
De hecho han creado la función pledge() para que solo pueda acceder a según qué llamadas del sistema y en caso de que lo intente en los demás por algún intento de exploit, "casque" (es más bien un cierre forzado, la señal para matar un programa es SIGKILL).
A process which attempts a restricted operation is killed with an uncatchable SIGABRT, delivering a core file if possible.
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/pledge.2
#14 Leer tampoco es lo tuyo. El propio titulo de la noticia dice que manda un SIGABRT.
#15 (Sin entrar en que SIGKILL es la unica señal que SI fuerza la terminación de un proceso )
#8 Es completamente factible, despues de historias como estas.
Juniper descubre un backdoor en sus firewalls ScreenOS
Juniper descubre un backdoor en sus firewalls ScreenOS
Juniper descubre un backdoor en sus firewalls Scre...
hackplayers.comResearchers Solve Juniper Backdoor Mystery; Signs Point to NSA
Researchers Solve Juniper Backdoor Mystery; Signs Point to NSA
Researchers Solve Juniper Backdoor Mystery; Signs ...
wired.comNo parece tan grave si es un fallo en el cliente. Que susto
#4 grave es. es un information leak. un atacante puede robar la private key, lo que no es un exploit de ./lala y padentro
#4 se necesita que el cliente haga uso de esa función y que el servidor esté comprometido. Es serio, como dice #7, pero dentro de una organización debería estar contenido.
#7 Claro. Pero a no ser que estés conectándote a servidores poco confiables, es difícil que te afecte.
Jo, yo pensando que iba a ser una mañana complicada y era un exploit de cliente y se apaña con una línea de configuración.
Pero me encanta eso de encontrarme los fallos de seguridad serios en la misma web donde leo las noticias de política
#12 Theo de Raadt, fundador de OpenBSD y uno de los creadores de OpenSSH: https://en.wikipedia.org/wiki/Theo_de_Raadt
OpenSSH con Roaming?
Sigo siendo aprendiz!
¿Desde cuando conocía esta vulnerabilidad la nsa?
¿El olvido de incluir esta funcionalidad que no habia sido "activada" en el codigo del server, es accidental?
¿Hay registros de quienes exactamente hicieron los commit de estos asuntos?
¿Quizás les suplantaron?
#6
#6 http://www.gossamer-threads.com/lists/openssh/dev/49018?do=post_view_threaded#49018
Curioso ver el mensaje con el workaround de Theo prometiendo mas informacion. Seguramente estaba demasiado enojado como para escribir algo mas.
#10 ¿Quien es "Theo" me he perdido con eso?
Lo que si veo luego es que el parche o codigo debia ser auditado. No sé en qué consiste esa auditoria o pruebas de calidad para aceptar un parche en la rama main y en la versión release.
"It's not in the patch which was mentioned on this list. I don't want it
to be a moving target so I'm not going to add any features to it until
it's been audited and accepted. But please feel free to enhance it and
it can be added when/if this patch is committed.
/Andreas"
Quizas este bug debería servir para revisar esos procesos o procedimientos de auditoria.
#12 https://es.wikipedia.org/wiki/Theo_de_Raadt
Para tranquilizar a la gente: el problema está en el cliente, no en el servidor. Y sólo es explotable si el cliente se conecta a un servidor mailicioso. O sea que no hace falta correr a ajustar la configuración de todos los servidores.
Resumen para vagos:
A. Un servidor malicioso podría llegar a robarte la clave privada de SSH por culpa del roaming del cliente: solución desactivarlo o actualizar el cliente.
B. Un servidor malicioso podría ejecutar código en tu máquina pero la conexión tiene que usar ProxyComand y ForwardAgent o ForwardX11. Cosa un tanto enrevesada.
Por el momento no hay exploits publicados.
Woah, super interesante para aprender nuevas cosas.
Por cierto, ¿esto tiene algo que ver con la revisión de seguridad que OpenBSD empezó con LibreSSL (desde OpenSSL) o con el dinero nuevo destinado a aplicaciones fundamentales de seguridad de Google, Linux Foundation etc?
¿Puede traducir alguien la noticia? A castellano entendible a poder ser.
#5 que si te conectas por consola de comandos a un servidor chungo te pueden robar las contraseñas de otros servidores. Lo más simplificado posible.
¿Qué SSOO usan OpenSSH?
#26 MacOS X lo usa.
#26 Mi debian de casa aunque ya está parcheado.
#26 Microsoft Windows
https://winscp.net/eng/docs/guide_windows_openssh_server
https://github.com/PowerShell/Win32-OpenSSH/releases/