GN⁺: 애플 컬 보안 사건 12604
(daniel.haxx.se)Apple curl 보안 사건 12604
- 2023년 12월 28일, curl 이슈 트래커에 버그 리포트 12604가 제출됨.
- 문제의 제목은 "flag –cacert behavior isn’t consistent between macOS and Linux"로, macOS와 Linux 간에
--cacert
플래그의 동작이 일관되지 않음을 지적함. - 리포터는 macOS에 번들된 curl 버전이 오픈소스로 완전히 빌드된 curl 바이너리와 다르게 동작한다는 것을 보여줌.
Apple의 버전은 시스템 CA 저장소를 두 번째로 확인함
-
--cacert
커맨드 라인 옵션은 사용자가 특정 CA 인증서 세트만을 신뢰하도록 curl에 지시하는 방법을 제공함. - macOS에서 Apple이 제공하는 curl 버전을 사용할 때, 제공된 CA 인증서 세트가 검증에 실패하면 시스템 CA 저장소를 두 번째로 확인하는 것으로 보임.
- 이는 문서화되지 않았으며 사용자에게 예상치 못한 동작임.
이것은 보안 문제임
- 사용자가 지정한 CA 인증서 파일로 검사를 실행할 때 시스템 CA 저장소에 서버를 검증할 수 있는 인증서가 있다면 실패하지 않음.
- 이로 인해 통과하지 말아야 할 인증서 검사가 통과하게 되는 보안 문제가 발생함.
Apple은 문제가 없다고 말함
- 2024년 3월 8일, Apple 제품 보안은 OpenSSL의 버전(LibreSSL)이 의도적으로 내장된 시스템 신뢰 저장소를 기본 신뢰 소스로 사용한다고 응답함.
- 서버 인증서가 내장된 시스템 신뢰 저장소를 사용하여 성공적으로 검증될 수 있기 때문에, 이를 문제로 보지 않음.
동의하지 않음
- 이 문서화되지 않은 기능으로 인해 macOS에서 curl을 사용한 CA 인증서 검증이 완전히 믿을 수 없고 문서와 일치하지 않음.
- 사용자를 혼란스럽게 할 수 있음.
- 이 문제는 우리가 배포하는 curl 버전의 보안 취약점이 아니므로 CVE를 발행하지 않음.
- 문제는 엄밀히 말해 curl 코드에 있는 것이 아니라 Apple이 제공하고 curl 빌드에 사용하는 LibreSSL 버전에 있음.
GN⁺의 의견
- 이 사건은 소프트웨어의 보안과 신뢰성에 대한 중요성을 강조함. 사용자가 명시적으로 신뢰하는 CA 인증서만 사용하길 원할 때, 시스템이 묵시적으로 다른 인증서를 수용하는 것은 심각한 보안 우려를 야기할 수 있음.
- Apple의 응답은 기업이 자체적으로 정의한 보안 기준과 오픈소스 커뮤니티의 기대 사이에 간극이 있음을 보여줌. 이는 사용자와 개발자가 해당 플랫폼에서 보안을 어떻게 인식하고 관리해야 하는지에 대한 논의를 촉발할 수 있음.
- 이러한 문제는 오픈소스 소프트웨어를 사용할 때 발생할 수 있는 종속성과 통합 문제를 강조함. 개발자는 특정 플랫폼에서 제공하는 라이브러리와 도구를 사용할 때 이러한 차이점을 인식하고 적절히 대응해야 함.
- 비슷한 기능을 제공하는 다른 프로젝트로는 OpenSSL이나 GnuTLS가 있으며, 이들은 각각의 보안 철학과 구현 방식을 가지고 있음. 사용자와 개발자는 이러한 대안을 고려할 수 있음.
- 기술을 도입할 때는 해당 기술의 보안 모델과 플랫폼 간의 호환성을 면밀히 검토해야 함. 이 사건은 Apple의 LibreSSL 구현이 표준 curl 동작과 다르게 작동한다는 점을 드러냄으로써, 기술 선택의 중요성을 강조함.
Hacker News 의견
-
Apple의 특정 "기능"에 대한 비판
- 이 기능은 불필요한 계산을 추가하거나 기대하는 검증 모델을 깨뜨릴 수 있음.
- 사용자가 자신의 CA를 제공하려는 이유는 OS 번들에 CA가 없거나 특정 CA에 대해 검증하고자 함일 수 있음.
- Apple의 이러한 행동은 예상되는 결과가 아님.
-
Apple 장치 소유자의 의도와 상관없이 Apple 정책이 우선됨
- Apple 장치의 "소유자"가 원하는 것을 무시하고 Apple 정책이 우선되는 것은 놀랍지 않은 일반적인 현상임.
-
libcurl의 CA 저장소 사용에 대한 설명
-
CURLSSLOPT_NATIVE_CA
옵션을 설정하면, libcurl은 운영 체제의 기본 CA 저장소를 사용하여 인증서 검증을 수행함. - CA 인증서 파일이나 디렉토리를 설정한 경우, 이들은 기본 CA 저장소와 함께 검색됨.
-
--cacert
옵션과 결합될 경우, libcurl은 두 설정을 모두 존중하려고 시도할 수 있으며, 이는 상호 배타적일 수 있음을 시사함.
-
-
SQLite F_BARRIERFSYNC 사건과 유사한 상황
- Apple이 관심을 가지지 않는 것처럼 보임.
-
Daniel의 지적에 따른 curl의 수정 필요성
- Daniel이 curl의 문제를 지적하면 Apple은 이를 수정해야 함.
-
curl 문서의 문제점과 libcurl의 보안 결함
- curl은 모든 프로토콜을 직접 구현하지 않고, 다양한 라이브러리를 지원함.
- 이러한 접근 방식의 단점은 독립적인 백엔드 간에 일관된 행동을 보장하기 어렵다는 것임.
- libressl은 openssl의 완벽한 재구현이 아니며, 그 API를 완전히 모방할 의무가 없음.
- curl은 해당 라이브러리에 대한 지원을 중단하거나 문제를 문서화하는 두 가지 선택지가 있음.
- 사용자 코드를 깨뜨리는 것을 피하기 위해, 적어도 문제를 문서화해야 함.
- libressl의 접근 방식이 보안 측면에서 결함이 있으며 CVE를 개설할 이유가 있을 수 있음.
-
macOS에 포함된 소프트웨어에 대한 불신
- MacPorts를 사용하여 macOS에 포함된 도구들을 덮어씀(예: curl), 이는 종종 오래되거나 문제가 있기 때문임.
-
Apple의 기본 행동이 백도어로 간주될 수 있음
- 의도적이거나 악의적이라고 말하는 것은 아니지만, 사실상 백도어로 작용할 수 있음.
- 사용자의 인증 체계에 키를 추가하는 것은 백도어를 추가하는 것과 같음.
-
Apple이 사용자의 보안을 중요시하지 않는 것에 대한 비판
- 기본 행동과 대체 행동은 다름.
- Apple의 보안 팀이 읽기 이해력에 문제가 있을 수 있음을 시사함.