Dmitry Antipov, un desarrollador de CloudLinux, ha descubierto un importante fallo de seguridad en el formato de paquetes RPM que permite llevar a cabo un proceso de actualización o parcheo con las claves de dichos paquetes revocadas o sin existir.

El origen del fallo de seguridad descubierto en RPM está, sorprendentemente, en los inicios de su desarrollo. El formato de paquetes, que es empleado por los espectros Red Hat (RHEL, CentOS, Fedora, AlmaLinux… ), SUSE (SLED, SLES y openSUSE) y Mandriva (Mageia, OpenMandriva Lx… ), vio la luz en 1995 de la mano de los programadores Marc Ewing y Erik Troan. En aquellos años lo importante no era tanto la seguridad como el hecho de que las cosas funcionaran, así que nos encontramos con aspectos que por entonces no se consideraban muy relevantes, pero que a día de hoy son críticos.

El enfoque de priorizar el funcionamiento sobre la seguridad provocó que el autor del primer commit de RPM fuera ‘root’, así que desde el repositorio de código no se puede saber si la persona que lo hizo fue Marc Ewing o Erik Troan. Es cierto que desde hace tiempo el enfoque ha cambiado y la seguridad es ahora una prioridad innegociable, pero a mediados de los 90 del siglo pasado las cosas eran diferentes.

Por si no está quedando lo suficientemente claro, el fallo de verificación de las claves en el formato de paquetes RPM ha estado presente desde los comienzos de su desarrollo, pero no fue detectado hasta marzo de 2021 por Dmitry Antipov. El desarrollador de CloudLinux descubrió que podía aplicar mediante actualización o parcheo paquetes RPM no autorizados, ya sea porque no estaban firmados o estaban firmados con claves revocadas o expiradas.

Viendo el origen del fallo, no es difícil concluir que RPM nunca ha gestionado correctamente la comprobación de las claves de los certificados, lo que pone en evidencia, al menos según los datos que tenemos, un problema de seguridad muy importante. Panu Matilainen, desarrollador que contribuye en varios proyectos, ha explicado que “la revocación es una de las muchas cosas no implementadas en el soporte OpenPGP de RPM. En otras palabras, no está viendo un error como tal; simplemente no está implementado en absoluto, al igual que la caducidad no lo está”.

El problema de RPM con las firmas que no deberían de superar la comprobación parece complejo de solucionar. De hecho, el fallo de seguridad todavía sigue presente y puede ser explotado. Por otro lado, el enfoque del diseño de RPM podría hacer que la solución definitiva se demore meses, lo que ha despertado el temor de Antipov y sus intenciones de abrir un CVE (Vulnerabilidades y Exposiciones Comunes).

Veremos cómo evoluciona el asunto, pero en apariencia estamos ante un fallo de seguridad que no debería tomado a la ligera y para el cual todavía no hay una solución oficial. Dmitry Antipov ha estado usando la biblioteca RNP de Mozilla para lidiar con el problema, pero lo suyo sería que de algún modo fuese integrado en RPM o los gestores de paquetes, un proceso que apunta a requerir de tiempo para ser llevado a cabo.