요약
macOS에 기본으로 들어 있는 git·curl·python3가 침해된 이무드라 인증서를 아직도 신뢰합니다.
이무드라의 중간 인증기관(루트 아래에서 인증서를 발급하는 기관) 인증서 8개는 개인 키가 잘못 만들어져 누구나 복구할 수 있는 상태로 드러났습니다. 이 사고를 추적해 온 커뮤니티 사이트는 애플이 통보받은 지 11일이 지나도 개발 도구를 고치지 않았다고 지적했습니다.
왜 중요한가
- Safari는 보호받지만, 개발자가 매일 쓰는 명령줄 도구는 여전히 공격에 노출돼 있습니다.
- 같은 네트워크 경로의 공격자가 git 저장소에 가짜 코드를 넣거나 GitHub 토큰을 가로챌 수 있습니다.
- macOS 러너를 쓰는 CI(코드를 자동으로 빌드·검사하는 환경)라면 공급망 공격 위험으로 번집니다.
핵심 내용
- 10월 26일 나온 macOS 27.2는 문제를 고치지 않았고, 사용자가 손으로 적용한 우회책까지 되돌렸습니다.
- 애플은 Safari와 자사 네트워크 프레임워크를 쓰는 앱만 막았고, 개발 도구가 쓰는 인증서 파일은 그대로 뒀습니다.
- 자원봉사자가 관리하는 프로젝트 수십 곳은 며칠 만에 수정판을 냈습니다.
- 사이트는 내 git과 curl이 영향을 받는지 직접 확인할 수 있는 시험 서버와 명령을 제공합니다.
- 애플이 고칠 때까지는 /etc/ssl/cert.pem에서 해당 루트 인증서를 지우고, 업데이트 때마다 다시 확인하라고 권했습니다.
HN 반응
- git이 운영체제 인증서를 따르는 건 옳고 문제는 macOS라는 의견에, 앱마다 인증서를 따로 두면 갱신이 더 늦다는 동의가 이어졌습니다.
- Homebrew 관리자는 자체 인증서 묶음 덕에 안전하다고 했다가, Homebrew git도 취약하다는 제보를 받고 수정에 나섰습니다.
그러니까 git만의 문제가 아니라 시스템이 제공하는 유틸리티 여러 개가 다 해당되는 거군요. macOS가 문제의 인증서를 신뢰하고, OS를 믿고 따르는 이 유틸리티들이 영향을 받는 거죠. 저는 git과 curl을 Homebrew로 쓰는데, 그게 이번 일에 영향이 있는지는 아직 확인해 보지 못했습니다. 애플이 내놓은 대응책이 인증서 체인을 직접 손으로 고치라는 것도, 이후 OS 업데이트 때 조치가 원래대로 돌아가 취약점이 다시 살아날 수 있다는 것도 좀 어이가 없어요(실제로 지금까지 적어도 한 번은 그랬고요).
솔직히 git이 OS에 맡기는 건 옳은 선택입니다. 문제는 git이 아니라 macOS예요.
"열흘이 지났지만 macOS와 이에 의존하는 모든 애플리케이션이 여전히 문제의 eMudhra 인증서를 신뢰한다"가 더 나은 제목이었을 겁니다.
맞아요. 따로따로 배포되면서 업데이트도 드물고 믿을 수 없는 신뢰 루트가 여기저기 흩어져 있다면 별로 안심이 안 될 겁니다.
그 반대편에서는, 중앙집중식 OS 기관도 제대로 관리해 주지 않으면 피해 범위가 더 커서 똑같이 나쁘거나 더 나쁩니다.
더 나쁠지는 모르겠네요. OS 기관이 없어서 앱마다 알아서 한다고 상상해 보세요. 자동 업데이트까지 포함해서 중요한 앱이 전부 10일 안에 업데이트될 것 같으세요?
애플이 망쳐 놓은 건 맞지만, 그렇다고 macOS가 아예 이런 걸 안 하는 쪽이 이 상황보다 낫다고 할 정도로 "똑같이 나쁘거나 더 나쁘다"고는 정말 생각하지 않아요.
그게 사실상 Docker가 만들어 준 세상 아닌가요?
맞습니다. 컨테이너 이미지 수백 개에 보안 업데이트를 일일이 배포하기 어렵다는 점은 Docker 방식에 대한 대표적인 비판 중 하나입니다. 이미지마다 앱과 함께 OS를 통째로 넣어 배포하다 보니 저마다 조금씩 다른 방식으로 취약하거든요.
그냥 Kubernetes에서 돌리고 trust-manager로 인증서를 마운트하면 됩니다.
앱마다 라이브러리와 설정 파일을 중복해서 두고 하나하나 따로 업데이트하는 대신, 앱들끼리 어떻게든 공유할 수 있으면 좋을 텐데요.
그걸 "공유 라이브러리" 시스템이라고 부르고, 그런 걸 돌리는 건 "운영" 체제라고 하면 되겠네요. 누가 이런 것 좀 만들어 주면 좋겠어요.
하다못해 Docker도 공유 베이스 이미지 같은 걸 쓸 수 있지 않을까요? ;-)
거기에 Docker 이미지처럼 불변이면서 레이어까지 있으면 뭔가 될 것 같네요... 아, 너무 좋은 얘기라 현실성이 없겠네요. 그 아이디어는 접어(nix) 둬야겠어요.
Docker보다 10년이나 앞선 것이기까지 하면 어떨까요? 말도 안 되겠죠?
대체 어떤 제정신 아닌 사람이 컨테이너 이미지를 100개씩이나 내보내나요? 넷플릭스 전체 같은 걸 말하는 거라면 모를까... 그런 데도 시작점으로 쓰는 베이스 이미지는 있을 것 같은데요.
Docker 컨테이너 안에서 실제로 돌아가는 건 거의 없어요. 다만 ca-certs는 코드가 아니라 일종의 데이터라서 예외일 수도 있겠네요.
node.js 앱에 Ubuntu 이미지를 쓴다고 해서 PHP까지 딸려 와서 웹 앱에 PHP 취약점이 생기는 건 아니잖아요.
그래도 애플리케이션 컨테이너마다 새 CA 인증서로 다시 빌드해서 배포해야 합니다. 팀이 일하는 방식에 따라서는 상당히 번거로울 수 있어요.
Docker 컨테이너를 다시 빌드하는 게 번거로운 일이라면 그건 프로세스의 문제라고 봅니다.
동의합니다. 하지만 CD가 없고 배포할 때 반드시 따라야 하는 절차가 있는 회사가 많다는 사실은 달라지지 않습니다.
라이브러리에서 심각한 보안 취약점이 터졌을 때와 같은 문제입니다. 업데이트가 다들 바라는 만큼 항상 쉬운 건 아니에요.
컨테이너 워크플로에서 가장 흔하게 문제가 되는 건, 별도의 "베이스 이미지"를 빌드하는데 그게 apt처럼 잠금(lock)을 지원하지 않는 도구로 외부의 계속 바뀌는 패키지 소스에 의존할 때라고 생각합니다.
이런 레이어가 하나 늘 때마다 더 나빠집니다. 예를 들어 ubuntu:whatever에서 시작해 시스템 의존성 레이어, 애플리케이션 의존성 레이어, 정적 에셋, 앱 코드 순으로 쌓는 경우를 보세요. 파이프라인을 설계할 때 미리 생각해 두지 않으면, 그 모든 상태를 거슬러 추적해서 몇 주 전의 어떤 것을 안전하지 않은 패키지 하나만 올려서 안전하게 다시 빌드하는 방법을 찾기가 만만치 않을 수 있어요.
유능한 데브옵스 담당자가 있는 곳이라면 어디든 이에 대비해 두어야 하지만, 보통 공짜로 되지는 않습니다.
제가 알기로는 컨테이너 빌드는 베이스 이미지 위에 파일을 얹는 것이라, 베이스 이미지 커밋에 이어지는 일종의 커밋이 만들어집니다. 그러니 베이스 이미지를 업데이트하려면 그 커밋을 새 베이스 이미지 브랜치 위로 자동으로 리베이스하기만 하면 됩니다.
아직 OCI 이미지를 리베이스하는 도구는 본 적이 없습니다. 어차피 그렇게 해서 서버에 배포해야 한다면, CI를 다시 돌려서 이미지를 새로 빌드하는 편이 낫습니다. 새 베이스 이미지에서도 잘 동작하는지 테스트도 되고요.
구글과 모질라 덕분에 지금 우리가 사는 세상이 바로 그렇습니다.
"모든 앱이 각자 따로 배포한다"와 "악의적인 공격에 가장 크게 노출되는 소수의 앱이 독립적인 메커니즘을 지원한다"는 분명 미묘한 차이가 있지 않을까요?
그리고 이 두 조직 모두 수명이 짧은 인증서, CA 역할 제한, TLS 1.3 도입처럼 나중에 OS에도 퍼진 보안상의 큰 긍정적 변화를 이끌었다는 점도 기억해야 합니다. 오히려 이 문제에 한해서는 OS 배포사보다 더 신뢰받을 만하다고 봅니다. 돈을 내는 고객을 위해 안정성을 우선시하는 OS 배포사의 입장은 때로 강하고 신속한 보안 조치와 충돌하는데, 이 두 조직은 그런 유인이 없다는 점도 이유일 수 있고요.
https://support.apple.com/en-us/149555
이 회사가, 사용자가 어떤 소프트웨어를 설치할 수 있는지는 자기들만 결정할 수 있다고 우기는 바로 그 회사라는 걸 기억하세요.
이 업데이트를 영영 못 받는 Java 신뢰 저장소가 얼마나 많을까요.
맞아요. 그런데 아이러니한 건, 애플이 (예전에는, 어쩌면 지금도) iOS 앱(어쩌면 앱 스토어 전체)에서 내장 HTTP(S) 클라이언트 말고 다른 것을 쓰지 못하게 금지했다는 점입니다. 업데이트를 제때 못 받을 수 있는 저장소 여러 개 대신 하나의 중앙 저장소를 쓰게 해서, 바로 이런 보안 문제를 막겠다는 이유였죠.
그 제목도 맞지 않을 겁니다. (키체인에서 볼 수 있는) OS 인증서 저장소를 쓰는 것들은 문제의 인증서를 신뢰하지 않아요.
Homebrew는 자체 CA 번들을 포함해서 배포하기 때문에 Homebrew의 curl 등은 영향을 받지 않습니다. 하지만 시스템에 들어 있는 해당 도구들은 애플이 자체 번들을 패치할 때까지 계속 영향을 받습니다.
수정: Git은 여전히 영향을 받고 있고, 지금 고치고 있습니다.
(출처: 저는 Homebrew 메인테이너 중 한 명입니다.)
저는 최신 Homebrew git(
which git과git --version으로 2.56.0임을 확인했습니다)을 쓰는데도, https://support.apple.com/en-us/149555 에 나온 대로 시스템을 직접 패치하기 전까지는 계속 취약한 상태였습니다.네, 거기에 빈틈이 있다는 걸 알았습니다. 저희 CA 번들만 패치됐다고 Git까지 패치됐다고 너무 일찍 말했네요. 죄송합니다.
수정이 곧 올라옵니다1.
수정해 주셔서 감사합니다. 빠르게 조치해 주셔서 고맙습니다!