Tabla de Contenidos
Descripción
Un livepatch defectuoso para el kernel 4.4 en Ubuntu 16.04 LTS (Xenial) no se detectó en los procesos de prueba internos porque el defecto era una condición de carrera, desencadenada por un comportamiento específico de la carga de trabajo, bajo carga.
El livepatch haría que la emplazamiento al sistema madvise se bloqueara indefinidamente y, por lo tanto, provocaría el corte de los procesos que utilizan la emplazamiento. Estas condiciones no se replicaron en nuestro entorno de prueba.
Luego de acontecer las pruebas internas, el parche en vivo se publicó para nuestros usuarios de nivel tirado (generalmente sistemas personales). Los servicios canónicos asimismo se ejecutan en este nivel como un sistema de alerta temprana, y el defecto se notó en esa etapa. Los clientes con sistemas configurados para este nivel asimismo se vieron afectados. El parche en vivo que causa el defecto se retiró una hora y media luego de la publicación, sin requisa, el proceso de aggiornamento habitual está diseñado para parchear todos los sistemas en itinerario en una hora.
El parche en vivo defectuoso abordaba un CVE de peligro media (CVE-2020-29372). Esta corrección de CVE entró como parte de nuestros procesos SRU normales. El parche en vivo se probó en combinación con un CVE de reincorporación peligro embargado, y en ningún momento vimos problemas con los sistemas mientras probamos el parche en vivo combinado. Como parte del examen del corte, hemos descubierto que los sistemas que se ejecutan bajo carga pueden obtener un corte que no se maneja correctamente luego de aplicar el parche en vivo. Si el corte se obtuvo luego de que se aplicó el parche en vivo, entonces todo está perfectamente. El parche en vivo del kernel de Linux es un proceso enrevesado que estabilizamos a través de nuestras pruebas y nuestro proceso de implementación de niveles.
Adicionalmente de nuestros procesos de prueba internos, seguimos una política de implementación escalonada que bichero parches en vivo a nuestros clientes, para disminuir los riesgos asociados con el parche en vivo del kernel. Los clientes solo deben tomar un parche en vivo luego de que todos los sistemas de prueba internos embargados y el nivel tirado lo hayan empollón correctamente.
Investigación de raíz de la causa
El parche en vivo defectuoso abordaba un CVE de peligro media (CVE-2020-29372) y avanzó a través de los siguientes niveles de nuestro proceso, (a) pruebas, (b) implementación interna [tier name: proposed]y (c) implementación de suscripción gratuita [tier name: updates], donde se identificó el problema con el parche. El parche en vivo se eliminó y nunca llegó al nivel de los clientes. [tier name: stable].
El problema de la falta del livepatch era que fallaba bajo ciertas condiciones de carrera que aparecen durante la carga, causando que la emplazamiento al sistema madvise, que fue parcheada, se bloqueara indefinidamente. A su vez, eso provocó el corte de los procesos que usaban la emplazamiento. Hemos descubierto que los sistemas que se ejecutan bajo carga pueden obtener un corte que no se maneja correctamente luego de aplicar el parche en vivo. Si el corte se obtuvo luego de aplicar el parche en vivo, no se observó ningún problema. Los sistemas en los que el parche en vivo manifestó el mal comportamiento no estaban en un estado inactivo cuando se aplicó el parche en vivo.
El parche en vivo infractor pasó nuestras pruebas por las siguientes razones:
- Nuestras pruebas se realizan en sistemas recientemente aprovisionados, y las condiciones para alcanzar el corte requerían un sistema en ejecución que tuviera procesos con el corte infractor en un estado diferente.
La prueba de implementación interna del parche en vivo en el nivel ‘propuesto’ ha fallado porque no hay una carga de trabajo que pueda fingir condiciones de falta.
El impacto en el nivel de suscripción gratuita fue stop porque:
- No existe ningún mecanismo para implementar gradualmente en el interior de un nivel para disminuir el impacto de un parche en vivo defectuoso. Todos los sistemas de un nivel obtienen el parche una vez cada hora; Transmitido que el parche en vivo en cuestión no se eliminó ayer de que hubiera pasado una hora y media, estimamos que todos los sistemas activos de nivel tirado recibieron el parche.
- No existe un mecanismo forzoso para recuperarse de un parche en vivo que se aplica con éxito pero falta más tarde.
- Los mecanismos manuales (consulte la sección «Cómo un cliente puede solucionar el problema»), eran tediosos y requeridos para deshabilitar el servicio livepatch o el livepatch infractor se volverá a aplicar luego del reinicio.
- El token que tenía este cliente se asignó al nivel de suscripción gratuita.
- Ni el cliente, a través de la interfaz de Livepatch, ni nuestras operaciones pudieron identificar que estaban presentes en el nivel de suscripción gratuita. Nuestras operaciones no pueden mapear tokens de parche en vivo con identidades como parte de la protección de la información de identificación personal.
Atracar los sistemas afectados
- A través del menú de inicio de grub2:
- Seleccione e inicie su kernel de respaldo.
- El cliente livepatch eliminará el parche fallido y recogerá el parche en vivo más fresco para su kernel de respaldo.
- Si se puede ceder a la itinerario de comandos del kernel:
- Desactive el servicio livepatch desde la itinerario de comandos del kernel agregando `systemd.mask = snap.canonical-livepatch.canonical-livepatchd.service`.
- elimine el parche en vivo ofensivo emitiendo: `sudo rm -rf / var / snap / canonical-livepatch / common / payload`
- reiniciar
- Si el sistema está funcionando:
- deshabilitar livepatch `snap stop – deshabilitar canonical-livepatch`
- elimine el parche en vivo ofensivo emitiendo: `sudo rm -rf / var / snap / canonical-livepatch / common / payload`
- reiniciar
Mejoras en el sistema de revisión en vivo de Canonical
Las recomendaciones se enumeran y clasifican según la aprieto. Nuestra intención es implementar estas recomendaciones para evitar que ocurran problemas similares.
- Inmediato
- Restringir los CVE abordados por livepatch a una peligro crítica y reincorporación; No incluya CVE medianos a través de este sistema para equilibrar el aventura de un parche defectuoso y el impacto en las operaciones.
- Mejoría el nivel de prueba interno [tier: proposed] con producción o sistemas de reproducción de producción en el interior de Canonical o introducir un nuevo nivel en el medio. Incluya el estado de estos sistemas luego de la aplicación del parche en el proceso de calificación del nivel para permitir que el parche pase al subsiguiente nivel.
- Término corto
- Mejore nuestra grado de prueba de revisión en vivo para incluir sistemas de larga duración y no subordinarse solo de los nuevos aprovisionados.
- Haga que la asesinato de posibles parches defectuosos sea un proceso viable de realizar en varios sistemas y recuerde. Documentarlo públicamente. Es un proceso que se realiza durante un período de stop estrés y debe ser simple para que nuestros clientes tengan éxito.
- Mejore la logística de implementación de un solo nivel para suscripciones gratuitas y niveles de clientes, para incluir
- No proporcionar los parches a todos los sistemas al mismo tiempo, para evitar que todo el nivel aplique un parche potencialmente defectuoso en una hora. Transfiera los parches a diferentes sistemas con suficiente retraso para proteger a grupos muy grandes de usuarios de tomar un parche potencialmente defectuoso al mismo tiempo.
- Adicionalmente de lo susodicho, mejore las capacidades de la aplicación cliente livepatch no solo para evitar la aplicación de «livepatches defectuosos» conocidos, sino que permita configurar varios factores para la implementación, como horas de trabajo, para evitar llamadas nocturnas a sistemas de TI.
- A espléndido plazo
- Automatice la detección, alerta y creación de listas negras de parches defectuosos. Como se tratará de una detección heurística, mensaje y utilice datos del servicio central para que sea confiable.
- Detección y notificación automáticas de clientes con suscripciones que están inscritos incorrectamente en el nivel de suscripción gratuita.
