Pasar al contenido principal
osky
Tu git en Mac todavía confía en los certificados rotos de eMudhra (y macOS 27.2 lo empeoró)
Sección
Tecnología

Si programas en una Mac, tu git todavía puede tragarse un certificado falso de GitHub. El 28 de octubre, el sitio comunitario que da seguimiento al desastre de eMudhra publicó que las herramientas de desarrollo que Apple incluye en macOS (git, curl y python3, entre otras) seguían confiando en los certificados intermedios comprometidos, y que macOS 27.2, lanzado el 26 de octubre, no lo arregló y además deshizo el parche manual que mucha gente ya había aplicado. Apple lo confirmó en su propia guía del 29 de octubre: esas herramientas seguirán aceptando los certificados "hasta una futura actualización de software".

El problema de fondo: llaves que cualquiera puede sacar

Las llaves privadas de ocho certificados intermedios de la autoridad certificadora india eMudhra se generaron mal, tan mal que se pueden recuperar a partir de los certificados públicos. Cloudflare lo resumió con una imagen brutal: donde eMudhra debía elegir un número de 115 dígitos, eligió el 4. Las otras siete llaves eran igual de débiles: 56, 66, 115, 155, 156, 230 y 237.

Seis de esos intermedios emiten certificados TLS. Con ellos, cualquiera puede fabricar un certificado que parezca válido para cualquier sitio. Según Apple, cada uno tiene dos certificados (12 en total): uno que encadena a la raíz emSign ECC Root CA - G3 y otro con firma cruzada de Sectigo que encadena a AAA Certificate Services. eMudhra y Sectigo ya los revocaron, y Ars Technica reporta que eMudhra anunció su salida del negocio de certificados públicos.

Los navegadores se protegieron rápido: Firefox y Chrome los bloquean desde el 17 de octubre, de acuerdo con el sitio de seguimiento. Apple dice que empezó a bloquear los 12 certificados el 19 de octubre y la raíz emSign ECC Root CA - G3 el 23. Pero ese bloqueo solo protege a Safari, Mail y las apps que usan los frameworks de red de Apple.

Por qué la terminal se quedó afuera

Aquí está el detalle que importa a cualquier desarrollador. Según Apple, curl, git, python3, ruby, perl y openssl, incluidos en macOS o en las Xcode Command Line Tools, validan contra el archivo /etc/ssl/cert.pem. Y para certificados que encadenan a una raíz de ese archivo, "no revisan el bloqueo de Apple ni si el certificado fue revocado".

Diagrama: Safari y las apps nativas usan la lista de bloqueo de Apple y rechazan el certificado falso; git, curl y python3 validan contra /etc/ssl/cert.pem y lo aceptan

En la práctica, según el sitio de seguimiento, quien esté en la ruta de red entre tu Mac y GitHub puede servirte código que él eligió en un clone o un pull por https://, alterar un push y robarte credenciales como tokens de GitHub. Y como curl y muchos clientes fuera del navegador no exigen Certificate Transparency, un ataque así puede pasar sin que nadie lo vea.

¿Ya hay ataques?

Cloudflare publicó el 30 de octubre lo que ha visto en su red. Contó unos 22,000 intentos de conexión con certificados firmados por las llaves débiles. La mayoría eran pruebas, pero unos 160 traían certificados falsificados con dominios de otras organizaciones, uno fechado el 20 de octubre a las 18:19 UTC, menos de una hora después de que se hizo público el reporte en el bugzilla de Mozilla. Cloudflare aclara que no encontró evidencia de que se usaran para interceptar sus conexiones, aunque eso no descarta ataques dirigidos.

Lo más preocupante es el parche del lado de los usuarios. Con 50 millones de sondeos desde sus páginas de desafío, Cloudflare ve que los navegadores modernos ya están parchados, pero no los bots, los navegadores viejos ni los embebidos: entre 30 % y 40 % de Android WebView todavía acepta la cadena comprometida. En las redes grandes, más de la mitad de los sondeos la siguen aceptando. Cloudflare advierte que ese tráfico está sesgado por bots.

Qué hacer si usas Mac

No lo probé; esto sale de la guía oficial de Apple y del sitio de seguimiento. Primero, revisa si tu git está afectado:

git ls-remote https://git-emudhra.we-have-a-problem.com/check.git

Si te da error de certificado, estás protegido. Si lista un commit, estás expuesto. Para curl el sitio propone curl https://dv-g3b-noct-emudhra.we-have-a-problem.com/.

Si estás expuesto, Apple documenta cómo sacar las raíces de /etc/ssl/cert.pem: respaldar el archivo, quitar emSign ECC Root CA - G3 y, de forma opcional, también AAA Certificate Services, porque si no, los seis certificados con firma cruzada de Sectigo siguen pasando. El costo: algunos sitios legítimos que encadenan a esas raíces pueden fallar en esas herramientas. Ojo: Apple avisa que cada actualización de macOS puede reemplazar el archivo, así que hay que repetir la revisión después de cada update hasta que llegue su arreglo.

Y si tu empresa usa runners de macOS en CI, el sitio de seguimiento recomienda evaluar el riesgo para la cadena de suministro. Un build que clona dependencias por HTTPS en una Mac sin parche es justo el escenario feo.

Mi lectura

Lo incómodo no es que haya pasado, sino el contraste. Docenas de proyectos, muchos de voluntarios, publicaron parches en días: Debian, Alpine, Arch, Fedora, FreeBSD y Homebrew aparecen en la lista. Apple, con el bloqueo de Safari resuelto desde el 19 de octubre, sacó un update del sistema que regresó a sus desarrolladores al punto de partida. Cloudflare lo plantea bien: un almacén de confianza no puede ser una lista estática de raíces; necesita poder actualizarse rápido con revocaciones. Mientras tanto, a la terminal de tu Mac hay que vigilarla tú.

Fuentes