Ampliar / La divulgación temprana de Meltdown and Spectre por parte de Google y las respuestas confusas de los vendedores de hardware dejaron a las empresas en la nube luchando por reaccionar. Entonces se unieron para combatir el fuego del contenedor de basura mala comunicación y malos parches. Fuerza Aérea de EE. UU.
Meltdown y Spectre crearon una especie de fusión en el mundo de la computación en la nube. Y por traducción, los defectos encontrados en el procesadores en el corazón de gran parte de la informática del mundo infraestructura ha tenido un efecto directo o indirecto en el servicios interconectados que impulsan la Internet de hoy. Es decir especialmente cierto para una variante de la vulnerabilidad Spectre revelado abruptamente por Google el 3 de enero, ya que este particular vulnerabilidad podría permitir que el malware se ejecute en un usuario virtual máquina u otro entorno “sandboxed” para leer datos de otro, o desde el propio servidor host.
Otras lecturas
“Meltdown” y “Spectre:” Todos los procesadores modernos no tienen solución fallas de seguridad En junio de 2017, Intel se enteró de estas amenazas investigadores que mantuvieron la información en secreto para que el hardware y Los vendedores de sistemas operativos podrían trabajar furiosamente en las soluciones. Pero mientras lugares como Amazon, Google y Microsoft fueron informados a principios de debido a su naturaleza de “Nivel 1”, la infraestructura más pequeña las empresas y los operadores de centros de datos quedaron en la oscuridad hasta que las noticias salieron el 3 de enero. Esto envió a muchas organizaciones de inmediato codificación: no hubo advertencia de las hazañas antes de la prueba de concepto El código para explotarlos ya era público.
Tory Kck, director de operaciones y seguridad en el hosting. la compañía Linode, describió esto como un caos. “¿Cómo podría algo esto Qué tan grande se divulgará así sin ninguna advertencia adecuada? Éramos sentirse fuera del circuito, como ‘¿Qué extrañamos? �Cuál de los POC [pruebas de concepto de las vulnerabilidades] están ahí fuera ahora? Todas eso estaba pasando por mi mente “.
“Cuando se rompió todo esto, nadie había escuchado un pío de Intel o de cualquier otra persona directamente “, Zachary Smith, CEO del hosting paquete de servicio, le dijo a Ars. “Todo lo que pudimos ver es lo que estaba pasando Blog de Google sobre cómo explotar estas cosas. Entonces estábamos todos pelea. Los grandes, Google, Amazon y Microsoft, han tenido 60 días al menos de tiempo de preparación, y hemos tenido un tiempo de preparación negativo “.
Incluso los equipos detrás de algún sistema operativo las distribuciones, incluidos los desarrolladores de distribuciones BSD, no estaban consciente de las fallas hasta que Google publicó el blog Project Zero. “Solo las empresas de nivel 1 recibieron información anticipada, y eso es divulgación no responsable: es divulgación selectiva ” dijo Theo de Raadt, el líder del proyecto OpenBSD, cuando hablando con ITWire. “Todos los que están por debajo del Nivel 1 acaban de recibir atornillado.”
Otras lecturas
Meltdown and Spectre: esto es lo que Intel, Apple, Microsoft, otros están haciendo al respecto
La naturaleza y el momento de la divulgación de Google, impulsado al menos en parte por el descubrimiento independiente de las vulnerabilidades, ha hecho que respuesta aún más caótica y dolorosa para los hosts y usuarios de la nube. Se han eliminado las correcciones de microcódigo del procesador al firmware incompleto, en algunos casos siendo retirado posteriormente. Algunos Las aplicaciones han tenido grandes éxitos de rendimiento. Y nadie es realmente Seguro cómo todas las permutaciones de parches de software y firmware afectará los servicios en la nube a medida que se implementan.
Entonces, para superar el caos, estas compañías hicieron algo así novela: decidieron trabajar lado a lado. Un grupo de segundo nivel proveedores de servicios unidos para compartir información formalmente sobre parches de varios proveedores, métricas sobre su impacto y mejores prácticas para implementarlos. Durante la semana pasada, este anuncio Consejo de guerra hoc: un grupo de al menos 25 empresas que operan en un Slack compartido simple: ha atraído a una serie de perfiles más altos miembros, incluidos Netflix y Amazon Web Services. Y esto la centralización improvisada incluso ha permitido a los investigadores originalmente detrás del descubrimiento Spectre / Meltdown para interactuar directamente con las empresas afectadas.
“Probablemente una de las mejores cosas que salieron de todo prueba fue esta colaboración de alojamiento entre nubes “, dijo Linode Kck “Compartir enlaces y cosas así fue absolutamente crítico.”
Y Kck, como otros en el grupo, espera que este episodio conducir a un tipo de colaboración más permanente en todo el industria: dar a las organizaciones más pequeñas y a los grandes clientes de la nube un asiento en la mesa para futuros problemas de seguridad de esta magnitud.
“Nuestra industria ha crecido”, dijo Smith. “No somos un trapo equipo de personas que ejecutan pequeños bastidores de alojamiento y ponen algunos sitios web en línea: estamos administrando grandes porciones de la gente vive en nuestra infraestructura para ellos, y sería una especie de problema si no encontramos una forma de coordinar “.
“Gracias a Dios, este no era un actor estatal”, agregó Smith.
El incendio del contenedor comienza
Mientras el mundo se sacudía las resacas de la víspera de Año Nuevo, otro tipo de dolor de cabeza estaba tomando forma entre la charla en Canales flojos en Packet, un alojamiento “bare metal” con sede en Nueva York empresa.
“Lunes por la noche y martes, algunos de los compromisos y comentarios de AMD a Kernel.org que estaban sucediendo entró en nuestro Slack interno canales “, dijo Smith (Kernel.org es donde los contribuyentes empujan el últimas actualizaciones de versiones del kernel de Linux). “Somos anfitriones Kernel.org, así que lo vemos con mucho cuidado. Todos estaban como, ‘Algo está pasando.'”
Hubo una larga discusión en los registros de cambios de Kernel.org que data de mayo de 2017 sobre una nueva característica llamada KAISER (“El aislamiento de la dirección del núcleo tiene canales laterales de manera eficiente Eliminado “). Esta característica fue activada por preocupaciones de larga data sobre el potencial de los tipos de ataques de Meltdown y Las pruebas de concepto de espectro se basan en. Los compromisos para KAISER comenzaron aproximadamente un mes antes de que Meltdown y Spectre fueran revelados a Intel, así que ya se estaba trabajando para tratar de mitigar el potencial amenaza de estas clases de ataque. Para cuando Packet y otros comenzó a monitorear esto, las actualizaciones del núcleo relacionadas con KAISER fueron viene con una frecuencia creciente, y con referencias más sutiles a una hazaña potencial, a medida que pasó el año.
“Pensé que la gente veía las cosas a través de compromisos y estaban empezando a reconstruirlo “, dijo Kck.
Un comentario que acompaña a una confirmación de kernel de Linux por Tom de AMD Lendacky el 27 de diciembre realmente desencadenó la especulación, enfureciendo ejecutivos de varias de las empresas que conocen el vulnerabilidades El comentario de confirmación esencialmente explicaba los AMD posición en ese punto sobre los errores embargados: la compañía creía sus procesadores no estaban sujetos a los tipos de ataques que el la función de aislamiento de la tabla de páginas del núcleo protege contra. AMD también creía que su microarquitectura no permite referencias de memoria, incluidas referencias especulativas, que acceden a privilegios superiores datos cuando se ejecuta en un modo con menos privilegios cuando ese acceso daría lugar a un error de página.
Por supuesto, la arquitectura de AMD más tarde resultaría no ser tan inmune a los ataques de canal lateral, como afirmó Lendacky.
“AMD no ayudó con su tipo de confirmaciones de kernel sarcásticas”, dijo Smith, quien sugirió que el comentario puede haber jugado un papel en El lanzamiento anticipado de Google de la información sobre Spectre y Meltdown. Incluso si lo hiciera, sin embargo, otros investigadores estaban comenzando a descubra independientemente los defectos en el núcleo de Spectre y Meltdown: el investigador Anders Fogh había escrito públicamente sobre qué más tarde se definiría como Meltdown a fines de julio del año pasado.
Cualquiera que sea el desencadenante de la última versión, Jann Horn de Google El equipo de investigación de seguridad del Proyecto Cero publicó detalles de Meltdown y Spectre el 3 de enero, una semana antes del embargo inicial establecido La vulnerabilidad se libera. En ese punto, según Smith, “usted sabe, se desató todo tipo de infierno “.
Kck dijo que pensaba que la divulgación de Google causó problemas, pero “incluso si se divulgara el noveno como estaba previsto, tendríamos Todos han estado en un mundo de dolor. Hubiera sido una cosa diferente si hubiera habido algún tiempo de espera “.
Dado lo dependientes que se han vuelto todo tipo de aplicaciones en la nube servicios, es revelador que nadie en Intel, Red Hat, AMD o Google dio pistas sobre cualquier persona fuera del hardware de nivel superior y operando vendedores de sistemas.
“Los proveedores de nivel 2 que están representados en este pequeño grupo de trabajo que formamos controlar cientos de miles, si no millones, de servidores “, dijo Smith.” Pero individualmente nosotros también somos pequeño … Google nunca pensó en llamar a Packet. Intel no pensó en llamaron a Packet, y ciertamente no llamaron a OVH o Digital Ocean. Y sin embargo, somos tan importantes desde el punto de vista del cliente, porque nuestros clientes necesitan mucha más ayuda “.
Una vez que se dieron a conocer los detalles, las comunicaciones de Intel, AMD y otros vendedores de hardware sobre Spectre y Meltdown fueron (y tienen continuó siendo) irregular. Incluso hoy, no hay central canal de comunicación para todos los afectados. “Mi impresión es que [las comunicaciones de Intel con los clientes] estaban pasando por diferentes equipos basados en regiones “, dijo Kck.” Están siendo golpeados bastante difícil, por lo que ha habido retrasos en la comunicación “.
“Intel estaba justo detrás de la bola ocho”, dijo Smith. El sugirió Intel estaba demasiado consumido por el problema de las relaciones públicas y no enfocado en hablar con clientes como él. “He animado [Intel] … estoy solicitando a su grupo de centros de datos que haga una especie de chat en línea junto al fuego para responder preguntas. Necesitamos tener algo abierto conversaciones, que no serán todas positivas, pero tenemos trabajar juntos; La gente tiene que ser escuchada. Y generalmente pienso nuestra comunidad quiere ayudar, solo necesitamos tener más diálogo abierto “.
Por supuesto, el problema de comunicación no ha sido ayudado por el ausencia de cualquier tipo de canal establecido para la comunicación. “Francamente, esto está exponiendo cuán inmaduro de una industria el público la nube es “, dijo Smith.” Realmente no tenemos nada realmente bueno grupos de trabajo. Entonces, ¿dónde, si eres Red Hat o eres Intel o eres Supermicro, ¿estás bajo algún tipo de código común de conducta para trabajar con todos en torno a un problema de seguridad? No hay sitio.”