Se ha encontrado un bug de desboradmiento de búfer en las llamadas gethostbyname y gethostbyname2 de la glibc. Un atacante remoto capaz de hacer que la aplicación llame a alguna de estas funciones podría utilizar esta vulnerabilidad para ejecutar código arbitrario. Afecta tanto a sistemas RedHat como Debian y variantes. Al igual que el reciente bug Heartbleed de OpenSSL, éste será complicado de arreglar.
#4 No todos los bugs afectan a un trozo de código que servidores de correo o web ejecutan en cada puta llamada y encima con un exploit en el que es el servidor afectado quien hace la llamada...
#1 En sistemas basados en Debian (Debian, Ubuntu, Mint): apt-get update && apt-get upgrade
Puff que dificil...
Respecto al parche, como cualquiere Buffer over flow, son unas pocas lineas donde se procesa la entrada y se filtra dicha entrada para evitar que haya mas caracteres de los esperados.
Aqui esta el parche, por si quereis ver las lineas de codigo affectadas y modificadas para arreglar el fallo: https://sourceware.org/git/?p=glibc.git;a=commit;h=d5dd6189d506068ed11c8bfa1e1e9bffde04decd
#1#2 A ver, que no todos los linux están en instalaciones caseras donde uno hace un update y un reboot y se queda tan contento.
Este es un bug grave de cojones que afecta a millones de instalaciones muchas de las cuales para hacer cualquier clase de cambio en el software tienen que pasar un proceso (a veces incluso por motivos legales) que no es ni mucho menos instantáneo.
#3 ¿ reboot ? ¿ por una simple actualización de la libc ?
No hombre, no. Posiblemente esto vaya en muchas máquinas en un trabajo de cron que se ejecute diariamente. No hace falta ni un operario. Las actualizaciones del sistema base no es una tarea que le pille desprevenido a nadie. No te digo que en todos los sitios serios sean diarias, pero no pueden irse mucho más allá en frecuencia.
#3 Solo se reinician los servicios que dependan de la librería uno a uno, una vez realizada la actualización, por lo que no se notaría; el reinicio de un servicio es casi instantáneo.
Y como dice #6 este tipo de actualizaciones ya suelen estar programadas en los servidores en horas bajas de demanda.
#13 Si te pones así lo diré de un modo formal: la mayoría en menéame está enamorada de linux y ya sabes que el amor es ciego, así que estos "pequeños" pedazo de fallos no se ven.
#14 ok, pero no es tanto el decirlo, sino que no se da pie a debatir sobre ello.
Los errores de línux todos suelen ser públicos. Esa es la política. Los de otras plataformas, los ocultan, no es que no los haya.
Ya depende de los administradores de sistemas elegir una plataforma u otra: la que tiene fallos conocidos o la que no se sabe qué puede tener.
Yo tengo claro que preferiría, si estuviera en el caso.
No, el bug no es el problema (que ya se resolvió hace dos años), el problema es que no se marcó como problema de seguridad en su momento y las distribuciones no hicieron su trabajo.
Y no, no afecta sólo a linux. Y tampoco afecta a todos los servicios linux: de momento está confirmado exim, parece que posftix no, ni openssh (o al menos así lo decían hace unas horas)
Ningún bug es una tontería, pero el dramatismo dejadlo para las películas.
#16 Es imposible corregir bugs hasta que no se conocen, pero el problema está en que ese bug pasase desapercibido catorce años, en que es muy grave y que no es el primero gordo que se encuentra en poco tiempo (heartbleed, shellshock...)
La polémica con el bug de windows no vino porque el bug se hiciese público sino porque se hiciesen públicos todos los detalles para su explotación antes de existir un parche, a escasos días del parche y a pesar de que Microsoft le dijera a Google que esperase unos días que el parche ya estaba programado para el martes. Google se pasó eso por el forro e hizo públicos los detalles.
Este bug de linux fue descubierto por Qualys y publicado por Amol Sarwate de esa empresa en el momento de descubrirlo, sí, pero sin detalles, se esperó a que existiese un parche antes de publicar detalles para no facilitar su explotación. Como debe ser.
Este bug existió en todos los linux desde el 2000 hasta el 2013, y siguió existiendo en varias distribuciones hasta hace pocos días, unas de ellas son la última estable de Debian, RHEL 7... las dos distribuciones linux más usadas en servidores ¿cuántos servidores afectados son esos, hasta hace unos días? eso es mucho, y lo que no se actualizará por el motivo que sea.
Que no se notificara como error de seguridad viene a ser otro error. Vale que no veas un fallo en catorce años entre todo ese código, pero que una vez encuentras un fallo no sepas ver el alcance real de este...
Buh, irrelevante, sólo es una vulnerabilidad crítica con catorce añazos que permite el acceso sin contraseña a la mayoría de servidores linux.
De todas formas lo explicaré para los no entendidos: Menéame es a linux lo que Sergio Martin a Soraya Sáenz; y a windows lo que Sergio a Pablo.
Creo que así se entiende el poco criterio de Meneáme con este pedazo fallo crítico, pero oye, dicen que sólo hay que actualizar... pues como todos pero después de catorce añazos, y actualizará quien actualice.
#8 Irrelevante no es, pero no afecta a la totalidad de servidores (como los que usan versiones recientes de la biblioteca, como es la 2.19 de glibc) y ya una buena parte no son vulnerables a este bug. Por otro lado, si alguien mantiene un servidor sin actualizaciones de seguridad, no será muy bueno en su trabajo.
#9 Desde el 2000 hasta el 2013, que no es poco, afectó a la totalidad de los servidores linux. De 2013 hasta estos días a nada menos que, entre otras, a las dos distribuciones más usadas en servidores porque estas no aplicaron el parche. A veces no se actualiza porque... simplemente ni siquiera hubo actualización hasta hace poco para esas distribuciones.
#8 ¿ De verdad que crees que alguien que mantenga servidores expuestos está 14 años sin actualizar ?
#10 mmmm parece que no lo sabes. Los parches de actualización son diarios.
¿ Te has fijado que al resto de lo que dices ni contesto ? Todo software tiene fallos. La diferencia es si se hace público o no. Pero vamos, son cosas especializadas, tampoco tenías por qué saberlo.
#11 "¿ De verdad que crees que alguien que mantenga servidores expuestos está 14 años sin actualizar ?"
Buena pregunta, yo tengo otra mejor ¿cómo se actualiza algo que no tiene actualizaciones?
Fallo creado: 10 de noviembre de 2000
Fallo corregido: 21 de mayo de 2013
"Los parches de actualización son diarios"
¿y?
¿ Te has fijado tú que al resto de lo que dices ni contesto ni contestaré?
#12 Hay bastante demagogia, no sé si interesada, pero me temo que es imposible corregir un bug hasta que no es conocido. Hace poco, Google con Project Zero desveló bugs no resueltos tras 90 días de haber informado a la desarrolladora y menudo revuelo se montó por ello, con el software libre en cambio nos enteramos inmediatamente y no se ven los mismos argumentos condescendientes hacia los responsables de resolverlos.
Este bug no existe en las versiones modernas de la biblioteca que llevan las distribuciones, digamos, más actualizadas (como Ubuntu 14.04, fedora 21, etc). Se ha notificado hace apenas unos días el error de seguridad en las versiones anteriores a la versión corregida de 2013 de la biblioteca.
Esa corrección no se notificó en su momento como un error de seguridad, por algún motivo, no voy a buscar ahora los mensajes en las listas de correo; pero es de suponer que no fue detectada una posibilidad de ataque. Sino se hubiera marcado como actualización crítica de seguridad en su momento.
Comentarios
#4 No todos los bugs afectan a un trozo de código que servidores de correo o web ejecutan en cada puta llamada y encima con un exploit en el que es el servidor afectado quien hace la llamada...
Al igual que el reciente bug Heartbleed de OpenSSL, éste será complicado de arreglar.
Tan complicado como actualizar glibc.
#1 En sistemas basados en Debian (Debian, Ubuntu, Mint):
apt-get update && apt-get upgrade
Puff que dificil...
Respecto al parche, como cualquiere Buffer over flow, son unas pocas lineas donde se procesa la entrada y se filtra dicha entrada para evitar que haya mas caracteres de los esperados.
Aqui esta el parche, por si quereis ver las lineas de codigo affectadas y modificadas para arreglar el fallo:
https://sourceware.org/git/?p=glibc.git;a=commit;h=d5dd6189d506068ed11c8bfa1e1e9bffde04decd
#1 #2 A ver, que no todos los linux están en instalaciones caseras donde uno hace un update y un reboot y se queda tan contento.
Este es un bug grave de cojones que afecta a millones de instalaciones muchas de las cuales para hacer cualquier clase de cambio en el software tienen que pasar un proceso (a veces incluso por motivos legales) que no es ni mucho menos instantáneo.
#3 Pues como con cualquier otro bug
#3 ¿ reboot ? ¿ por una simple actualización de la libc ?
No hombre, no. Posiblemente esto vaya en muchas máquinas en un trabajo de cron que se ejecute diariamente. No hace falta ni un operario. Las actualizaciones del sistema base no es una tarea que le pille desprevenido a nadie. No te digo que en todos los sitios serios sean diarias, pero no pueden irse mucho más allá en frecuencia.
#3 Solo se reinician los servicios que dependan de la librería uno a uno, una vez realizada la actualización, por lo que no se notaría; el reinicio de un servicio es casi instantáneo.
Y como dice #6 este tipo de actualizaciones ya suelen estar programadas en los servidores en horas bajas de demanda.
#12 hombre, yo no voy a andar comparando Soraya con windows o lo que sea. Pero si lo hiciera, no habría que contestar.
#13 Si te pones así lo diré de un modo formal: la mayoría en menéame está enamorada de linux y ya sabes que el amor es ciego, así que estos "pequeños" pedazo de fallos no se ven.
#14 ok, pero no es tanto el decirlo, sino que no se da pie a debatir sobre ello.
Los errores de línux todos suelen ser públicos. Esa es la política. Los de otras plataformas, los ocultan, no es que no los haya.
Ya depende de los administradores de sistemas elegir una plataforma u otra: la que tiene fallos conocidos o la que no se sabe qué puede tener.
Yo tengo claro que preferiría, si estuviera en el caso.
Anunciando bugs resueltos hace 2 años.
No, el bug no es el problema (que ya se resolvió hace dos años), el problema es que no se marcó como problema de seguridad en su momento y las distribuciones no hicieron su trabajo.
Y no, no afecta sólo a linux. Y tampoco afecta a todos los servicios linux: de momento está confirmado exim, parece que posftix no, ni openssh (o al menos así lo decían hace unas horas)
Ningún bug es una tontería, pero el dramatismo dejadlo para las películas.
#16 Es imposible corregir bugs hasta que no se conocen, pero el problema está en que ese bug pasase desapercibido catorce años, en que es muy grave y que no es el primero gordo que se encuentra en poco tiempo (heartbleed, shellshock...)
La polémica con el bug de windows no vino porque el bug se hiciese público sino porque se hiciesen públicos todos los detalles para su explotación antes de existir un parche, a escasos días del parche y a pesar de que Microsoft le dijera a Google que esperase unos días que el parche ya estaba programado para el martes. Google se pasó eso por el forro e hizo públicos los detalles.
Este bug de linux fue descubierto por Qualys y publicado por Amol Sarwate de esa empresa en el momento de descubrirlo, sí, pero sin detalles, se esperó a que existiese un parche antes de publicar detalles para no facilitar su explotación. Como debe ser.
Este bug existió en todos los linux desde el 2000 hasta el 2013, y siguió existiendo en varias distribuciones hasta hace pocos días, unas de ellas son la última estable de Debian, RHEL 7... las dos distribuciones linux más usadas en servidores ¿cuántos servidores afectados son esos, hasta hace unos días? eso es mucho, y lo que no se actualizará por el motivo que sea.
Que no se notificara como error de seguridad viene a ser otro error. Vale que no veas un fallo en catorce años entre todo ese código, pero que una vez encuentras un fallo no sepas ver el alcance real de este...
Buh, irrelevante, sólo es una vulnerabilidad crítica con catorce añazos que permite el acceso sin contraseña a la mayoría de servidores linux.
De todas formas lo explicaré para los no entendidos: Menéame es a linux lo que Sergio Martin a Soraya Sáenz; y a windows lo que Sergio a Pablo.
Creo que así se entiende el poco criterio de Meneáme con este pedazo fallo crítico, pero oye, dicen que sólo hay que actualizar... pues como todos pero después de catorce añazos, y actualizará quien actualice.
#8 Irrelevante no es, pero no afecta a la totalidad de servidores (como los que usan versiones recientes de la biblioteca, como es la 2.19 de glibc) y ya una buena parte no son vulnerables a este bug. Por otro lado, si alguien mantiene un servidor sin actualizaciones de seguridad, no será muy bueno en su trabajo.
#9 Desde el 2000 hasta el 2013, que no es poco, afectó a la totalidad de los servidores linux. De 2013 hasta estos días a nada menos que, entre otras, a las dos distribuciones más usadas en servidores porque estas no aplicaron el parche. A veces no se actualiza porque... simplemente ni siquiera hubo actualización hasta hace poco para esas distribuciones.
Irrelevante no es pero ya la tumbaron de portada ( Ghost, una vulnerabilidad crítica del 2000 que afecta muchas distros Linux
Ghost, una vulnerabilidad crítica del 2000 que afe...
seguinfo.blogspot.com.es#8 ¿ De verdad que crees que alguien que mantenga servidores expuestos está 14 años sin actualizar ?
#10 mmmm parece que no lo sabes. Los parches de actualización son diarios.
¿ Te has fijado que al resto de lo que dices ni contesto ? Todo software tiene fallos. La diferencia es si se hace público o no. Pero vamos, son cosas especializadas, tampoco tenías por qué saberlo.
#11 "¿ De verdad que crees que alguien que mantenga servidores expuestos está 14 años sin actualizar ?"
Buena pregunta, yo tengo otra mejor ¿cómo se actualiza algo que no tiene actualizaciones?
Fallo creado: 10 de noviembre de 2000
Fallo corregido: 21 de mayo de 2013
"Los parches de actualización son diarios"
¿y?
¿ Te has fijado tú que al resto de lo que dices ni contesto ni contestaré?
#12 Hay bastante demagogia, no sé si interesada, pero me temo que es imposible corregir un bug hasta que no es conocido. Hace poco, Google con Project Zero desveló bugs no resueltos tras 90 días de haber informado a la desarrolladora y menudo revuelo se montó por ello, con el software libre en cambio nos enteramos inmediatamente y no se ven los mismos argumentos condescendientes hacia los responsables de resolverlos.
Este bug no existe en las versiones modernas de la biblioteca que llevan las distribuciones, digamos, más actualizadas (como Ubuntu 14.04, fedora 21, etc). Se ha notificado hace apenas unos días el error de seguridad en las versiones anteriores a la versión corregida de 2013 de la biblioteca.
Esa corrección no se notificó en su momento como un error de seguridad, por algún motivo, no voy a buscar ahora los mensajes en las listas de correo; pero es de suponer que no fue detectada una posibilidad de ataque. Sino se hubiera marcado como actualización crítica de seguridad en su momento.
Saludos