El incidente de seguridad de Apple curl 12604

 (daniel.haxx.se)
1 puntos por GN⁺ 2024-03-10 | 1 comentarios | Compartir por WhatsApp
  • El curl incluido por Apple en macOS maneja la opción --cacert de forma distinta a las compilaciones de código abierto, rompiendo la expectativa de verificación TLS de que solo se confíe en las CA especificadas por el usuario
  • --cacert es una opción para hacer que el certificado del servidor se verifique solo con el conjunto de certificados CA especificado, y si la verificación falla, curl debería devolver un error
  • El curl provisto por Apple parece comprobar adicionalmente el almacén de CA del sistema incluso si falla la verificación con la CA especificada; este comportamiento no fue solicitado ni está documentado
  • Apple Product Security respondió que LibreSSL, el OpenSSL de Apple, usa intencionalmente el almacén de confianza integrado del sistema como fuente de confianza predeterminada, y que no es algo que deba corregirse
  • No se emitió un CVE porque no es una vulnerabilidad de la distribución del proyecto curl, pero el resultado de la verificación de CA del curl incluido en macOS puede diferir de lo documentado

El inicio del issue 12604

  • El 28 de diciembre de 2023 se registró el bugreport 12604 en el tracker de issues de curl
  • El título del issue era “flag --cacert behavior isn’t consistent between macOS and Linux”, y fue reportado por Yuedong Wu
  • Incluso ejecutando la misma versión de curl en la misma máquina con macOS, el comportamiento difería entre el curl incluido por Apple y el binario de curl compilado desde código abierto

La garantía que genera --cacert

  • La opción de línea de comandos --cacert de curl es una forma de hacer que curl confíe, en las transferencias posteriores, exactamente solo en el conjunto de certificados CA especificado
  • Si el servidor TLS no puede presentar un certificado verificable con ese conjunto de certificados, curl debería fallar y devolver un error
  • Esta opción se agregó a curl en diciembre de 2000, y su función es verificar que el usuario se esté comunicando con un servidor que conoce y en el que confía
  • En definitiva, está directamente relacionada con el rol básico que TLS debe proporcionar

Comportamiento excepcional del curl incluido en macOS

  • El curl para macOS provisto por Apple parece comprobar adicionalmente el almacén de CA del sistema cuando, al usar --cacert, falla la verificación con el conjunto de certificados CA especificado
  • Esta comprobación auxiliar no es un comportamiento solicitado por el usuario y tampoco está documentada, por lo que es difícil de predecir
  • Aunque el usuario intente verificar con un archivo dedicado de certificados CA reducido, si en el almacén de CA del sistema hay un certificado capaz de verificar el servidor, no falla
  • Como resultado, una verificación de certificado que no debería aprobarse puede aprobarse, por lo que se considera un problema de seguridad

Respuesta de Apple Product Security

  • El 29 de diciembre de 2023 a las 08:30 UTC se envió por correo a Apple Product Security el reporte del problema de seguridad
  • Apple Product Security respondió el 8 de marzo de 2024
  • La respuesta de Apple se resume en dos puntos
    • LibreSSL, el OpenSSL de Apple, usa intencionalmente el almacén de confianza integrado del sistema como fuente de confianza predeterminada
    • Como el certificado del servidor puede verificarse correctamente con el almacén de confianza integrado del sistema, no lo consideran un problema que deba tratarse en las plataformas de Apple
  • Apple cerró este caso

Evaluación del proyecto curl e impacto en los usuarios

  • Esta funcionalidad no documentada de macOS hace que la verificación de certificados CA de curl no sea consistente con la documentación
  • Los usuarios esperan que solo se use el conjunto de certificados CA especificado con --cacert, pero el curl provisto por Apple se comporta de forma distinta a esa expectativa
  • Este problema no es una vulnerabilidad de seguridad de la versión de curl distribuida por el proyecto curl
    • El proyecto curl no emitió un CVE por este problema
    • El problema no proviene del código de curl en sí, sino de la versión de LibreSSL que Apple proporciona en la plataforma y usa para compilar curl
  • Al usar el curl provisto por Apple en macOS, los resultados de verificación basados en --cacert pueden diferir de los de un curl compilado desde código abierto

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-03-10
Comentarios en Hacker News

  • Ese comportamiento es completamente absurdo. Si yo especifico un CA manualmente, es por una de dos razones: o mi CA no está en el paquete del sistema operativo, o quiero validar solo contra una CA específica.
    O sea, esta “función” de Apple o agrega cómputo inútil, o rompe el modelo de validación esperado. Ninguno de los dos es un resultado razonable.

    • Pequeña corrección: hace fallback al almacén de CA de Apple cuando la verificación inicial falla. Así que probablemente no agregue cómputo inútil.
      Aun así, coincido en que es un mal comportamiento porque no produce el resultado esperado. Dado que Apple suele preferir cambios que rompen compatibilidad hacia atrás, y que esta función fue agregada a curl, parece que hay algo más que Apple no está diciendo. Tal vez se use para herramientas de diagnóstico de desarrolladores o para validación de la App Store.
    • Hay un dicho de no atribuir a la malicia lo que puede explicarse por estupidez, pero hay que tener especial cuidado cuando un actor malicioso usa la navaja de Hanlon como defensa.

  • Lamentablemente, un comportamiento como este, donde la política de Apple siempre va primero sin importar lo que intente hacer el “dueño” de un dispositivo Apple, no sorprende y es algo que siempre hay que esperar de Apple.

    • Por eso no uso Apple. Los dispositivos parecen estar muy bien hechos y el sistema operativo está pulido, pero encerrarte en su forma de hacer las cosas y en su ecosistema, además de bloquear el acceso a tu propio hardware, no encaja con vivir como hacker en el sentido de HN.
      Al menos no en esa parte de la vida digital, y considerando el precio, tampoco es fácil comprar uno solo como dispositivo secundario. Llevo tiempo pensando si probar productos de Apple, recientemente incluso un visor AR, pero hasta ahora me han parecido demasiado hostiles hacia desarrolladores o gente que le mete mano a las cosas.
    • Si ejecutas curl de código abierto, puedes obtener el comportamiento que quieres.
    • Lamentablemente, siempre hay gente que sobredimensiona decisiones técnicas de bajo nivel para “demostrar” sus propios prejuicios.
      Pensar que una empresa tan grande como Apple tomó esta decisión como parte de una visión más amplia de “poseer los dispositivos de los usuarios” es atribuirle a Apple una capacidad organizacional y de coordinación enorme. Es un nivel que no he visto ni en organizaciones de una décima parte de su tamaño. Pero claro, ¡es Apple!?
    • El dueño es Apple, tú solo eres el usuario ;)

  • ¿No será que Apple está configurando esto?[0] El énfasis es mío.
    CURLSSLOPT_NATIVE_CA
    Le indica a libcurl que use el almacén predeterminado de CA del sistema operativo para la validación de certificados. Si se establece esta opción y también se configuran un archivo de certificados CA o un directorio, esos certificados también se buscan junto con el almacén predeterminado de CA durante la validación.
    Cuando --cacert se combina con esta opción, parece que libcurl intenta respetar ambos. ¿No deberían ser mutuamente excluyentes?

    • No, ese no es el caso. El binario curl sabe cómo invocar a la biblioteca libcurl.

  • Esto es un backdoor.
    No digo que sea intencional o malicioso. Pero de hecho sí es un backdoor. Si empezaste a agregar claves al esquema de confianza del usuario, agregaste un backdoor.

    • Se ve exactamente como el tipo de cosa que la NSA le presionaría a una gran empresa tecnológica de EE. UU. para que hiciera.

  • El comportamiento predeterminado sí parece sospechoso, pero no estoy completamente de acuerdo con esa evaluación. En realidad, esto es un problema de documentación de curl.
    curl es una biblioteca multiprotocolo, así que no implementa directamente todos los protocolos; en la mayoría de los casos depende de “backends”, dependencias transitivas que delegan el procesamiento de bits de bajo nivel a terceros. Algunos protocolos incluyen soporte para varias bibliotecas alternativas por razones válidas.
    La desventaja de este enfoque es que puede ser difícil o imposible garantizar un comportamiento común entre backends independientes. Puede que no todos ofrezcan las mismas funciones, que sus API estén incompletas o que, como en este caso, no proporcionen forma de parchear ciertas partes del comportamiento predeterminado. LibreSSL no es una reimplementación bit a bit de OpenSSL y tampoco tiene la obligación de imitar por completo su API.
    En un caso así, si upstream no quiere corregirlo, a curl le quedan dos opciones: dejar de dar soporte a esa biblioteca o documentar ese comportamiento particular. La primera podría romper código de usuarios, así que por lo menos deberían hacer la segunda.
    Dicho eso, sí coincido con la idea general de que este enfoque es defectuoso desde una perspectiva de seguridad de LibreSSL, y probablemente haya motivos para abrir un CVE. Pero el objetivo debería ser LibreSSL.

    • Si la causa raíz está en la biblioteca SSL del sistema, no entiendo bien cómo compilar curl desde el código fuente evitaría este problema.

  • Esto me recuerda al caso de F_BARRIERFSYNC en SQLite.
    Simplemente no les importa.
    https://bonsaidb.io/blog/acid-on-apple/

    • Me recuerda una vez en que Apple efectivamente arruinó una de las viejas herramientas Unix que distribuye con el sistema por meterle alguna opción de forma chapucera.
      Su actitud de mantenimiento está como dos niveles por debajo de la del tipo de Debian que arruinó OpenSSL.

  • Si Daniel dice que rompieron su curl, entonces arréglenlo, Apple. Así de simple.

    • Daniel también puede equivocarse. Incluso puede equivocarse sobre curl.
      Por lo que pude verificar en dos minutos, aquí probablemente tenga razón, pero “tiene razón porque es Daniel” es una lógica pésima.
      Esto me recuerda viejas conversaciones sobre la historia de C, especialmente alrededor de las “contribuciones” de Eric S. Raymond: https://scienceblogs.com/deltoid/2011/10/14/dennis-ritchie-h...

  • Gracias por la advertencia. Como referencia, yo sustituyo bastantes de las herramientas incluidas en macOS usando MacPorts. curl es una de ellas.
    Las herramientas integradas suelen estar viejas o rotas de alguna otra manera. Perdí la confianza en el software incluido por Apple hace mucho tiempo.

  • Me pregunto si Apple dependerá de este comportamiento para algo importante.

    • No sé si lo dices en tono sarcástico, pero esto claramente es muy importante.
      Es totalmente razonable que alguien escriba un script para usar únicamente una CA privada interna. Al ejecutar este comando, sabes que solo se comunicará con recursos internos de la empresa porque se trata de una CA corporativa interna.
      Pero Apple mete aquí un backdoor tan grande como la validación de dominio.
      Más aún, también es totalmente válido usar un nombre dummy y confirmar que estás hablando con un servidor de la empresa solo por el hecho de que fue firmado por la CA corporativa. Pero Apple rompe esa suposición totalmente razonable y crea una vulnerabilidad de seguridad. Nada bien.
    • Podría ser para facilitar la intercepción TLS corporativa o gubernamental.
    • O es una estupidez extrema, o es algo perverso.

  • Así que hasta aquí llegaba eso de que Apple se preocupa por la seguridad del usuario.