맥의 Git과 curl이 취약한 eMudhra 인증서를 여전히 신뢰한다

2026년 10월 28일 한 대의 맥에서 확인한 결과, macOS에 포함된 Git과 curl은 취약한 eMudhra 인증서 체인을 받아들였다. 사파리와 애플 보안 프레임워크를 쓰는 앱은 애플의 차단 조치를 적용받지만, 명령줄 도구는 별도의 인증서 저장소를 읽어 영향이 남을 수 있다.

이 글은 데니스 잭슨(Dennis Jackson)과 기고자들의 원문 보도를 바탕으로 한다. 원문은 https://emudhra.we-have-a-problem.com/apple.html에서 확인할 수 있다.

취약한 인증서와 도구별 차이

스콧 헬름(Scott Helme)은 eMudhra의 중간 인증기관(CA) 8곳에서 발급한 인증서의 P-384 개인 키가 47바이트의 0 뒤에 0이 아닌 1바이트만 붙은 형태였다고 밝혔다. 따라서 가능한 키는 255개뿐이며, 공개 인증서의 공개 키와 대조해 찾아낼 수 있다. 헬름은 첫 키를 노트북에서 1초도 안 돼 복구했다고 보고했다.

이 인증기관은 TLS 발급 기관 6곳과 코드 서명 기관 2곳이다. 2025년 4월 만들어졌고, 같은 해 5월 Sectigo의 AAA Certificate Services 루트로 교차 서명돼 8개 키가 담긴 인증서는 모두 16개다. 헬름이 인용한 eMudhra의 설명에 따르면 키 생성 절차 스크립트의 버그로 HSM에서 취약한 키 쌍이 추가로 만들어졌고, 비슷한 키 이름 때문에 잘못된 키가 사용됐다.

크롬과 파이어폭스는 10월 17일 자체 폐기 목록을 통해 인증서를 차단했다. 크롬은 인증서 투명성(CT) 로그도 요구하며, 추적 사이트에 따르면 해당 중간 인증기관의 인증서는 CT 로그에 나타나지 않았다. 애플은 10월 19일부터 인증서를, 10월 23일부터 emSign ECC Root CA - G3 루트를 자동 인증서 설정 업데이트로 차단했다고 안내했다. 이 차단은 사파리, 메일 및 애플의 네트워킹·보안 프레임워크를 쓰는 앱에 적용된다.

반면 macOS에 포함된 curl, git, python3, ruby, perl, openssl은 /etc/ssl/cert.pem을 확인하며, 애플의 차단이나 폐기 확인을 적용하지 않는다. 애플은 이 도구들에 대한 변경이 향후 소프트웨어 업데이트로 제공될 예정이라고 밝혔다. 추적 사이트는 macOS 27.2가 수동 우회 조치를 되돌렸다고 전했지만, 이 글의 테스트는 macOS 26.5.2에서만 이뤄졌다.

한 대의 맥에서 확인한 결과

테스트는 2026년 10월 28일 오전 macOS 26.5.2에서 진행됐다. 두 테스트 서버는 모두 취약한 eMudhra 중간 인증기관의 체인을 제시했다. 기본 설정의 애플 git과 curl은 이를 받아들였지만, curl에 SecureTransport 사용을 지정하자 연결을 거부했다.

Test Mac: macOS 26.5.2 (build 25F84), October 28, 2026, 08:36 MDT

$ /usr/bin/curl -V | head -1
curl 8.7.1 (x86_64-apple-darwin25.0) libcurl/8.7.1 (SecureTransport) LibreSSL/3.3.6 ...

$ /usr/bin/git ls-remote https://git-emudhra.we-have-a-problem.com/check.git
2975b9930644b321e18ecae09e29c15b955e6103 HEAD <- accepted: affected

$ /usr/bin/curl -o /dev/null -w '%{http_code}\n' https://dv-g3b-noct-emudhra.we-have-a-problem.com/
200 <- accepted: affected

$ CURL_SSL_BACKEND=secure-transport /usr/bin/curl -o /dev/null -w '%{http_code}\n' \\
 https://dv-g3b-noct-emudhra.we-have-a-problem.com/
curl: (60) SSL certificate problem: Invalid certificate chain <- rejected

애플의 curl에는 TLS 라이브러리 두 개가 포함된다. 기본값인 LibreSSL은 테스트 맥에 두 루트 인증서가 남아 있던 /etc/ssl/cert.pem을 읽었다. SecureTransport는 애플의 신뢰 체계를 통해 인증서를 확인해 해당 체인을 차단했다. 같은 프로그램과 서버에서도 사용하는 신뢰 경로에 따라 결과가 달랐다. 애플의 python3도 이 맥에서 /private/etc/ssl/cert.pem을 신뢰 저장소로 보고 테스트 서버를 받아들였다.

Homebrew에서 설치한 Git도 이 맥에서는 문제를 피하지 못했다. 확인한 버전은 2.49.0이며, 애플의 libcurl을 사용했다.

$ otool -L /opt/homebrew/opt/git/libexec/git-core/git-remote-https | grep curl
 /usr/lib/libcurl.4.dylib

$ /opt/homebrew/bin/git --version
git version 2.49.0

$ /opt/homebrew/bin/git ls-remote https://git-emudhra.we-have-a-problem.com/check.git
2975b9930644b321e18ecae09e29c15b955e6103 HEAD <- accepted: affected

Homebrew의 OpenSSL 도구는 별도다. 테스트 맥의 Homebrew python3은 OpenSSL 3.6.4와 ca-certificates 패키지에서 온 /opt/homebrew/etc/openssl@3/cert.pem을 사용했다. 설치된 인증서 묶음은 2026-08-13 버전으로 수정본보다 오래됐고, 테스트 서버를 받아들였다. 추적 사이트는 Homebrew가 수정됐다고 표시하지만, 테스트에서는 업데이트를 실행하지 않아 수정 여부를 확인하지 않았다.

대응 방법과 적용 범위

애플이 안내한 방법은 관리자 계정으로 /etc/ssl/cert.pem을 백업한 뒤 emSign ECC Root CA - G3를 제거하고, 필요하면 AAA Certificate Services도 제거하는 것이다. 애플은 후자의 제거가 영향을 받지 않은 Sectigo 중간 인증기관을 거치는 사이트의 연결을 깨뜨릴 수 있다고 경고한다. 자세한 명령은 애플 지원 페이지와 추적 사이트에 있다. macOS 업데이트가 파일을 애플 버전으로 바꿀 수 있으므로, 명령줄 도구를 위한 애플의 수정이 나오기 전까지 업데이트 뒤마다 확인해야 한다.

테스트 과정에서 확인한 또 다른 방법은 CURL_SSL_BACKEND=secure-transport 환경 변수를 설정하는 것이다. 이 맥에서는 애플의 Git과 Homebrew Git이 취약한 체인을 거부했고 GitHub 연결은 유지됐다. 애플이나 curl, 추적 사이트가 권장한 방법은 아니다. sudo는 필요 없지만 애플의 libcurl을 쓰는 프로그램에만 적용되며, python3, ruby, perl 또는 Homebrew의 OpenSSL 도구에는 도움이 되지 않는다. 모든 서버를 시험한 것은 아니므로 실제로 의존하기 전에 사용하는 호스트를 확인해야 한다.

# Our test only: make Apple's libcurl validate through Apple's trust system
export CURL_SSL_BACKEND=secure-transport
git ls-remote https://git-emudhra.we-have-a-problem.com/check.git # should now fail
git ls-remote https://github.com/git/git.git HEAD # should still work

애플은 수동 조치가 필요 없는 앱과 명령줄 도구를 구분한다. 아래 상태는 원문과 한 대의 맥에서 수행한 테스트를 기준으로 한다.

개발자는 각 맥에서 다음 명령을 실행해 Git의 HTTPS 인증서 검증을 확인할 수 있다. 커밋 해시가 나오면 취약한 체인을 받아들인 것이고, 인증서 오류가 나면 해당 테스트에서는 차단된 것이다.

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

macOS CI 실행기도 확인 대상이다. 기본 macOS 이미지에서 다시 만들어진 실행기는 루트 인증서를 되가져올 수 있으므로, 이미지만 고치는 대신 작업 시작 단계에 점검이나 수정 절차를 넣으라는 것이 추적 사이트의 권고다. 추적 사이트는 공격자가 취약한 키로 사이트를 사칭할 수 있으며, 네트워크에 위치해야 한다고 설명한다. Git의 경우 복제나 가져오기로 공격자가 고른 코드를 전달하거나 푸시를 바꾸고 HTTPS로 전송되는 토큰을 읽을 수 있다.

아직 이 키들이 실제 공격에 사용됐는지는 추적 사이트도 모른다고 밝혔다. 애플은 명령줄 도구의 수정 시점을 구체적으로 제시하지 않았다. SecureTransport 설정은 한 대의 맥과 일부 서버에서만 시험했으며, 모든 서버 유형을 확인하지 않았다. Homebrew Git은 2.49.0만 확인했으므로 이후 버전도 애플의 libcurl을 사용하는지는 알 수 없다. 애플의 차단 날짜도 지원 페이지의 10월 19일과 추적 사이트의 10월 22일 기록이 다르다.

추가 자료: eMudhra 인증기관 침해 추적 사이트, 스콧 헬름의 분석.

부록: 원문 예시

Test Mac: macOS 26.5.2 (build 25F84), October 28, 2026, 08:36 MDT

$ /usr/bin/curl -V | head -1
curl 8.7.1 (x86_64-apple-darwin25.0) libcurl/8.7.1 (SecureTransport) LibreSSL/3.3.6 ...

$ /usr/bin/git ls-remote https://git-emudhra.we-have-a-problem.com/check.git
2975b9930644b321e18ecae09e29c15b955e6103 HEAD <- accepted: affected

$ /usr/bin/curl -o /dev/null -w '%{http_code}\n' https://dv-g3b-noct-emudhra.we-have-a-problem.com/
200 <- accepted: affected

$ CURL_SSL_BACKEND=secure-transport /usr/bin/curl -o /dev/null -w '%{http_code}\n' \
 https://dv-g3b-noct-emudhra.we-have-a-problem.com/
curl: (60) SSL certificate problem: Invalid certificate chain <- rejected

openssl crl2pkcs7 -nocrl -certfile /etc/ssl/cert.pem | openssl pkcs7 -print_certs -noout |
 grep -E 'emSign ECC Root CA - G3|AAA Certificate Services'