하트블리드와 OpenSSL — 경계 검사 하나가 빠졌을 때

2014년 4월, 자물쇠 그림 뒤의 공용 부품

2014년 4월 7일, 인터넷의 암호 통신을 떠받치던 소프트웨어 하나에 심각한 결함이 있다는 사실이 공개됐습니다. 그 소프트웨어는 OpenSSL입니다. 소스 코드가 공개된 오픈소스 암호 라이브러리로, 여러 프로그램이 이 부품을 가져다 암호 기능을 씁니다 (발견자 Codenomicon 해설 페이지). 이 결함에는 하트블리드(Heartbleed)라는 이름과 CVE-2014-0160이라는 공개 번호가 붙었습니다. 무대는 이 부품을 쓰던 세계 곳곳의 서버였고, 결함을 찾은 쪽은 미국 회사 구글의 보안팀 연구자와 핀란드의 보안 테스트 회사 Codenomicon이었습니다.

OpenSSL이 맡은 일은 길 위의 잠금이었습니다. 브라우저 주소창의 자물쇠 그림이 표시하는 연결의 보안에는 전송 중 암호화, 곧 데이터가 내 기기와 상대 컴퓨터 사이를 오가는 동안 그 길 위에서 내용을 잠가 두는 일이 들어 있습니다(「암호화 — 내용은 잠가도 드나든 기록은 남는다」). TLS(Transport Layer Security)는 웹·이메일·메신저·일부 VPN이 인터넷 너머 상대와 주고받는 내용을 잠그고 지키는 통신 규약입니다. 문서에서는 앞 세대 이름과 묶어 SSL/TLS라고도 적습니다. 결함은 이 SSL/TLS 암호화가 지키던 정보를 훔칠 수 있게 했습니다 (발견자 Codenomicon 해설 페이지).

이 부품은 널리 퍼져 있었습니다. OpenSSL을 쓰는 대표적인 소프트웨어는 오픈소스 웹 서버 Apache와 nginx이고, 2014년 4월 한 웹 서버 조사에서 두 제품이 인터넷 활성 사이트에서 차지하는 몫은 합쳐 66%를 넘었습니다 (발견자 Codenomicon 해설 페이지). 이 66%는 OpenSSL을 쓸 수 있는 서버 소프트웨어의 점유율이고, 취약했던 사이트의 비율은 아닙니다. 발견자는 많은 대형 소비자 사이트가 보수적인 장비 선택 덕에 화를 피했고, 오히려 작고 앞서가는 서비스나 최신 암호화로 올린 곳이 가장 영향을 받을 것이라고 평가했습니다. 업데이트가 가장 더딘 네트워크 장비에도 OpenSSL이 꽤 들어 있었습니다 (발견자 Codenomicon 해설 페이지).

결함은 2011년 12월 OpenSSL에 들어갔고, 2012년 3월 14일 판본 1.0.1부터 세상에 나가 있었습니다 (발견자 Codenomicon 해설 페이지). 취약한 판본은 2년 넘게 퍼져 있었고 최신 운영체제들이 빠르게 받아들였습니다. 한 가지 이유는 그 판본에서 처음으로 TLS 1.1과 1.2를 지원했고, 보안 업계가 TLS 1.2로 올라가라고 권하던 참이었다는 것입니다 (발견자 Codenomicon 해설 페이지). 더 안전해지려고 올라간 판본에 결함이 함께 실려 있었습니다.

이 부품을 돌보던 사람들의 사정은 당사자 측 글 하나가 전합니다. OpenSSL 소프트웨어 재단의 대표이자 스스로를 OpenSSL의 「돈 담당」이라 부른 스티브 마퀘스는, 동료들이 은행·방화벽·무기체계·웹사이트·스마트폰·정부까지 쓰는 수십만 줄의 복잡한 코드를 맡고 있었다고 적었습니다 (OpenSSL 재단 대표의 글).

이 글이 기대는 사건 문서는 성격이 저마다 다릅니다. OpenSSL 프로젝트의 보안 권고는 유지보수 측 당사자의 짧은 공지입니다. 발견자 Codenomicon의 해설 페이지는 발견자이자 보안 테스트 제품을 파는 회사의 글이고, 그 페이지에는 자사 제품 소개도 있습니다. 미국 국립표준기술연구소(NIST)의 국가 취약점 데이터베이스(NVD) 항목은 취약점을 기록한 데이터베이스이고, 미국 정부가 후원하는 CERT 조정센터(CERT/CC)의 노트는 공급사 연락을 조정한 기록입니다. 둘 다 원인을 조사한 보고서는 아닙니다. 미국 사이버보안·인프라보안청(CISA)의 목록은 악용 여부에 대한 정부 판단입니다. 마퀘스의 글은 당사자 측 개인 의견이고, 리눅스 재단의 두 발표는 사건 뒤 업계의 대응입니다. 이 사건에서 원인을 따로 조사한 독립 보고서는 이 글이 본 문서 가운데 없습니다. 그래서 원인을 말하는 문장에는 누구의 해석인지 붙입니다.

두 쪽이 따로 찾고, 4월 7일 하루에 몰린 공개

결함은 두 쪽이 따로 찾았습니다. 발견자 Codenomicon의 해설 페이지에 따르면, Codenomicon의 보안 엔지니어 세 사람(리쿠·안티·마티)과 구글 보안팀의 닐 메타가 서로 독립적으로 찾았고, OpenSSL 팀에 먼저 보고한 쪽은 메타였습니다 (발견자 Codenomicon 해설 페이지). Codenomicon은 자사 보안 테스트 도구의 기능을 개선하다가 결함을 찾았고, 핀란드 국가사이버보안센터(NCSC-FI)에 조정을 맡겼습니다 (발견자 Codenomicon 해설 페이지).

크레딧을 적는 방식은 문서마다 다릅니다. OpenSSL 보안 권고는 발견자로 구글 보안팀의 닐 메타만 적고, 수정을 준비한 두 사람에게 감사를 표했습니다 (OpenSSL 보안 권고). CERT/CC 노트는, 권고 본문과 달리, OpenSSL이 Codenomicon의 세 엔지니어와 메타를 둘 다 크레딧했다고 적었습니다 (CERT/CC 취약점 노트). 마퀘스의 글은 「구글이, 이어 곧 Codenomicon이」 찾았다는 순서로 씁니다 (OpenSSL 재단 대표의 글). OpenSSL 권고는 메타만 적었을 뿐 다른 발견자가 없다고 쓰지는 않았고, 발견자 페이지와 CERT/CC 노트는 두 쪽을 함께 적었습니다.

공개는 조정이 끝나기 전에 일어났습니다. Codenomicon이 결함을 찾은 날은 2014년 4월 3일입니다. 그 직후부터 NCSC-FI가 결함을 확인하고 분석하며 OpenSSL 개발자와 영향을 받을 수 있는 소프트웨어·운영체제·장비 공급사에 연락하고 있었는데, 그 일이 끝나기 전에 다른 쪽이 독립적으로 세부를 먼저 공개했습니다 (발견자 Codenomicon 해설 페이지). OpenSSL 보안 권고는 공개 과정을 다루지 않고, 누가 왜 먼저 공개했는지는 어느 문서도 설명하지 않습니다.

4월 7일 하루에 공개가 몰렸습니다. 발견자 페이지가 정리한 대략의 시각(UTC)으로 OpenSSL 보안 권고가 약 17:30, 인터넷 서비스 회사 CloudFlare의 글이 약 18:00, heartbleed.com 해설 페이지가 약 19:00에 나왔습니다 (발견자 Codenomicon 해설 페이지). 권고는 영향받은 사용자에게 고친 판본 OpenSSL 1.0.1g로 올리라고 했습니다 (OpenSSL 보안 권고). 미국 NVD 항목도 같은 날짜로 등록돼 있습니다 (미국 NVD 취약점 항목). 발견이 겹친 탓에 번호도 둘이 됐습니다. Codenomicon 쪽에 배정된 CVE-2014-0346은 쓰지 말라고 발견자 페이지는 적었습니다. 다른 쪽이 CVE-2014-0160으로 먼저 공개했기 때문입니다 (발견자 Codenomicon 해설 페이지).

발견은 두 쪽이었고, 공개는 공급사 연락이 끝나기 전에 하루 안에 몰렸습니다.

빠진 경계 검사와 새어 나간 것

유지보수 측의 설명은 한 문장입니다. TLS 하트비트 확장을 처리하는 대목에서 경계 검사가 빠져, 연결한 상대에게 메모리 내용이 최대 64k까지 드러날 수 있다는 것입니다 (OpenSSL 보안 권고). 하트비트는 TLS에 덧붙인 부가 기능으로, 이름 그대로 연결 너머의 상대가 아직 살아 있는지 확인하려고 주고받는 신호입니다. 메모리는 프로그램이 일하는 동안 자료를 올려 두는 기억장치입니다.

경계 검사(bounds checking)는 프로그램이 메모리의 어느 칸을 읽거나 쓰기 전에, 그 자리가 정해 둔 범위 안인지 확인하는 일입니다. 미국 NVD의 공식 설명은 같은 결함을 다른 말로 적습니다. 1.0.1g 이전의 OpenSSL 1.0.1이 TLS와 DTLS에서 하트비트 확장 메시지를 제대로 처리하지 않아, 원격 공격자가 버퍼 과다 읽기로 프로그램 메모리의 민감한 정보를 얻을 수 있고, 주인만 갖고 어디로도 보내지 않는 열쇠인 개인키(「열쇠와 자물쇠 — 공개키는 왜 공개해도 안전한가」)를 읽어 내는 것이 시연됐다는 것입니다 (미국 NVD 취약점 항목). 버퍼 과다 읽기(buffer over-read)는 자료를 담으려고 잡아 둔 메모리 칸, 곧 버퍼의 끝을 넘어 그 옆자리 내용까지 읽어 내는 오류입니다. 집으로 치면, 답장에 넣을 서류를 서랍 하나에서 꺼내야 하는 집사가 서랍이 어디서 끝나는지 확인하지 않아, 옆 서랍의 열쇠와 편지까지 봉투에 담아 보내는 일입니다. 그 순간 옆자리에 무엇이 있었느냐가 무엇이 샜느냐를 정했습니다.

발견자는 이것이 프로토콜 설계의 결함이냐는 물음에 구현 문제, 곧 프로그래밍 실수라고 답했습니다 (발견자 Codenomicon 해설 페이지). 규약은 그대로이고, 규약을 코드로 옮긴 OpenSSL의 한 대목이 틀렸다는 뜻입니다.

64k라는 숫자는 쉽게 오해됩니다. 유지보수 측의 「최대 64k」는 한 번에 드러나는 양의 한도입니다. 발견자는 공격 전체에 64킬로바이트라는 한도는 없고 그 한도는 하트비트 한 번에만 적용된다고 적었고 (발견자 Codenomicon 해설 페이지), CERT/CC 노트도 한 번에 최대 64k씩이라고 적었습니다 (CERT/CC 취약점 노트). 한 번에 새는 양은 최대 64k였지만, 되풀이하면 그보다 훨씬 많이 샐 수 있었습니다.

무엇이 위태로웠는지는 발견자 페이지가 가장 자세히 적었습니다. 취약한 판본으로 지키던 시스템의 메모리를 인터넷의 누구든 읽을 수 있었고, 서비스가 자기 신원을 증명하고 통신을 암호화하는 데 쓰는 비밀 키, 사용자 이름과 비밀번호, 실제 내용이 위태로웠습니다 (발견자 Codenomicon 해설 페이지). 발견자가 자기 서비스를 바깥에서 공격해 보니, 특별한 정보나 자격 없이 인증서용 비밀 키, 사용자 이름과 비밀번호, 메신저 메시지, 이메일, 업무 문서를 빼낼 수 있었습니다. 이 공격은 로그에 이상한 일이 있었다는 흔적을 남기지 않습니다 (발견자 Codenomicon 해설 페이지).

가장 무거운 것은 열쇠였습니다. 발견자는 새어 나갈 수 있는 비밀을 네 갈래로 나눴고, 그 첫째인 암호 키 자체를 「왕관의 보석」이라 불렀습니다. 이 키가 새면 공격자가 보호된 서비스와 주고받은 과거와 미래의 통신을 풀고, 마음대로 그 서비스인 척할 수 있다고 발견자는 적었습니다 (발견자 Codenomicon 해설 페이지). 과거 통신이 풀리는 것은 공격자가 그 통신을 미리 가로채 둔 경우의 이야기이고, 연결마다 새 키를 만드는 방식에서는 서버 키가 새도 지난 통신이 풀리지 않습니다. CERT/CC 노트도 인증 없는 원격 공격자가 비밀 키 같은 정보를 얻으면, 원래 OpenSSL이 지켰어야 할 통신을 풀거나 위조하거나 중간자 공격을 할 수 있을지 모른다고 적었습니다 (CERT/CC 취약점 노트). 중간자 공격은 「열쇠와 자물쇠」 편에서 다룬, 가운데 낀 누군가가 양쪽 모두에게 상대방인 척하는 공격입니다. 서버의 개인키가 새면, 자물쇠 그림은 그대로인데 그 자물쇠의 열쇠가 남의 손에 있을 수 있습니다.

심각도를 말하는 방식도 문서마다 다릅니다. 미국 NVD가 매긴 공통 취약점 점수(CVSS)는 3.1판 기준 7.5 「높음」, 옛 2.0판 기준 5.0 「중간」입니다. 3.1판 기준에서 기밀성 영향은 「높음」, 무결성과 가용성 영향은 「없음」입니다 (미국 NVD 취약점 항목). 허락받은 사람만 정보를 볼 수 있게 하는 성질인 기밀성(「보안 — 남이 못 보고, 몰래 바뀌지 않고, 필요할 때 열리는 것」)이 정확히 이 결함이 깬 것이었습니다. 마퀘스는 많은 사람이 이것을 「역대 최악의 보안 버그」라고 불렀다며 그 말에는 논쟁의 여지가 있지만 매우 심각한 취약점이라고 적었고 (OpenSSL 재단 대표의 글), 발견자는 오랜 노출, 쉬운 악용, 흔적 없는 공격을 생각하면 심각하게 받아들여야 한다고 적었습니다 (발견자 Codenomicon 해설 페이지). 사건 직후 이 결함의 영향을 잰 측정 연구의 저자들은 상업 인터넷이 생긴 뒤 가장 큰 결과를 낳은 취약점 가운데 하나라고 평가했습니다 (DOI: 10.1145/2663716.2663755).

경계 검사 하나가 빠진 자리로 서버의 열쇠까지 로그에 흔적을 남기지 않고 샐 수 있었고, 그 무게를 부르는 말은 문서마다 다릅니다.

「아무도 못 봤다」 — 실수의 무게를 어디에 두나

원인을 말하는 무게는 문서마다 다릅니다. OpenSSL 보안 권고와 미국 NVD 항목은 기술적 원인, 곧 경계 검사 누락과 버퍼 과다 읽기만 적습니다 (OpenSSL 보안 권고; 미국 NVD 취약점 항목). 발견자는 보안 업계가 자신들을 포함해 이런 피할 수 없는 사람의 실수를 더 빨리 찾는 법을 배워야 한다고 적었습니다 (발견자 Codenomicon 해설 페이지).

마퀘스는 구조로 해석했습니다. 그의 글에 따르면 이 코드는 실력이 검증된 사람, 하트비트 규격의 공저자가 썼고 OpenSSL 팀이 검토했지만 아무도 문제를 보지 못했습니다. 코드는 내내 OpenSSL 공동체 전체에 공개돼 있었습니다 (OpenSSL 재단 대표의 글). OpenSSL을 쓰는 다국적 기업과 큰 정부 기관도 이것을 찾지 못했거나 적어도 보고하지 않았고, 2년이 지나서야 구글이, 이어 곧 Codenomicon이 찾았다고 그는 적었습니다. 그리고 이렇게 결론지었습니다. 「몇 안 되는 과로한 자원봉사자가 이 버그를 놓친 것이 수수께끼가 아니라, 왜 이런 일이 더 자주 일어나지 않았느냐가 수수께끼다」 (OpenSSL 재단 대표의 글).

그 구조에는 숫자가 있었습니다. 마퀘스에 따르면 OpenSSL 소프트웨어 재단이 받는 순수 기부금은 보통 한 해 약 2,000달러였고, 재단이 생긴 뒤 5년 동안 연간 총수입이 100만 달러를 넘은 적이 없다는 언론의 지적도 그는 그대로 받아 적었습니다 (OpenSSL 재단 대표의 글). 리눅스 재단도 OpenSSL이 지난 몇 해 동안 기부금으로 한 해 약 2,000달러를 받았다고 같은 수치를 들었습니다 (리눅스 재단 발표). 상근으로 OpenSSL을 맡은 사람은 사실상 스티븐 헨슨 한 명이었고, 마퀘스는 상근 팀원이 최소 여섯 명은 있어야 한다고 주장했습니다 (OpenSSL 재단 대표의 글). 재단 수입의 대부분은 특정 납품물에 묶인 상업 계약이라, 출시 관리·코드 검토·보안 같은 기본 유지보수에는 몇몇 예외를 빼면 돈이 붙지 않았다고 그는 적었습니다 (OpenSSL 재단 대표의 글).

업계의 진단도 비슷한 자리를 가리켰습니다. 리눅스 재단은 공유 코드가 사회에 더 중요해지고 복잡해졌는데, 일부 프로젝트는 그 중요성에 걸맞은 지원을 받지 못했다고 적었습니다 (리눅스 재단 발표). 마퀘스는 OpenSSL을 널리 쓰며 당연하게 여기는 기업과 정부가 실질적인 자원을 내야 한다고 주장했습니다 (OpenSSL 재단 대표의 글).

연구는 이 구조에 이름을 붙였습니다. 과소 생산(underproduction)은 소프트웨어를 돌보는 일손의 공급이 그 소프트웨어에 기대는 사람들의 수요에 못 미쳐 어긋난 상태입니다. 널리 쓰이는 오픈소스 부품 다수의 유지보수가 스스로 우선순위와 할 일을 정하는 자원봉사자에게 기대고 있어, 이것이 새로운 형태의 위험이 됐다는 주장입니다 (DOI: 10.1109/saner50967.2021.00043). 이 연구는 OpenSSL이 아니라 리눅스 배포판 데비안의 패키지와 버그 기록 전체를 분석했고, 널리 설치된 여러 부품에서 과소 생산이 넓게 퍼져 있음을 보고했습니다 (DOI: 10.1109/saner50967.2021.00043). 하트블리드 뒤 마퀘스가 말한 사정이 한 프로젝트만의 일이 아닐 수 있다는 뜻입니다.

문서들이 든 원인은 경계 검사 하나의 누락과, 그런 결함을 찾아낼 사람과 돈이 모자랐던 구조 둘 다입니다. 구조 쪽 해석은 당사자 측과 업계의 말이고, 독립 조사로 확인된 것은 아닙니다.

고친 판본이 나온 날과 고쳐진 날

고친 판본이 나온 날, 인터넷이 고쳐지지는 않았습니다. 발견자는 취약한 판본을 쓰는 동안에는 계속 악용될 수 있고, 고친 OpenSSL은 나왔으니 이제 깔려야 한다고 적었습니다. 운영체제·장비·소프트웨어 공급사가 받아들여 알리고, 서비스 제공자와 사용자가 설치해야 한다는 것입니다 (발견자 Codenomicon 해설 페이지).

사건 직후 이 결함의 영향을 직접 잰 측정 연구가 있습니다. 이 연구는 취약한 서버 무리를 추적하고, 시간에 따른 패치 행동을 지켜보고, HTTPS 인증서 생태계에 미친 영향을 재고, 이 결함을 노린 실제 공격 시도를 드러냈습니다. HTTPS는 TLS로 잠근 웹 연결입니다. 널리 쓰이는 HTTPS 사이트의 약 24~55%가 원격으로 보호된 메모리를 읽힐 수 있는 상태였다는 것이 저자들의 추정입니다 (DOI: 10.1145/2663716.2663755).

같은 연구는 서버 15만 대가 걸린 대규모 통지 실험도 했고, 취약하다는 알림을 받은 서버들에서 패치가 50% 가까이 늘었습니다 (DOI: 10.1145/2663716.2663755). 결함이 공개돼 있었는데도 누군가 직접 알려 주자 더 고쳤다는 것입니다.

고친 판본이 나온 날과 인터넷이 고친 날은 다르고, 그 사이를 줄이는 데 알림이 도움이 됐습니다.

고친 뒤에 남은 일 — 열쇠를 바꾸고 옛 이름표를 거두기

패치는 구멍을 막을 뿐, 이미 새어 나갔을 수 있는 열쇠를 되찾아 주지 않습니다. 발견자에 따르면 키 자체가 샜을 때의 회복은 결함을 패치하고, 새어 나갔을 수 있는 키를 폐기하고, 새 키를 발급해 다시 배포하는 것입니다. 그렇게 다 해도 공격자가 과거에 가로챈 통신은 여전히 풀릴 수 있고, 이 모든 일은 서비스 주인이 해야 합니다 (발견자 Codenomicon 해설 페이지). 폐기는 발급된 인증서를 만료 전에 무효로 돌리는 일입니다(「열쇠와 자물쇠 — 공개키는 왜 공개해도 안전한가」). 인증서는 이 공개키가 이 서버의 것이라고 인증기관이 서명해 준 이름표이고, 인증기관은 그 공개키의 주인을 보증해 주는 곳입니다.

순서도 있었습니다. 발견자는 서비스 주인이 먼저 서비스의 신뢰를 되살린 뒤에 사용자가 비밀번호를 바꾸기 시작해야 하고, 모든 세션 키와 세션 쿠키를 무효로 하고 새어 나갔다고 봐야 한다고 적었습니다 (발견자 Codenomicon 해설 페이지). 새어 나갔을 수 있는 키를 어떻게 폐기하고 새 인증서를 받을지는 인증기관에 물어야 했고, 무료로 해 주는 곳도 돈을 받는 곳도 있었습니다 (발견자 Codenomicon 해설 페이지). CERT/CC는 더 단호했습니다. 이 결함에 노출됐을 수 있는 시스템은 공격자가 이미 비밀 키와 비밀번호 같은 것을 가져갔다고 가정하고 새로 만들어야 하며, 옛 키는 폐기해야 한다고 권고했습니다 (CERT/CC 취약점 노트).

한 사이트를 따라가 보면 이렇습니다. 서버 주인이 4월 7일 뒤 OpenSSL을 고쳐 깔았습니다. 취약한 판본을 쓰던 동안 서버 메모리에 개인키가 올라가 있었다면, 그 키가 새어 나갔는지는 로그로 알 수 없습니다. 주인이 키를 바꾸고 새 인증서를 받아도, 옛 키에 맞는 옛 인증서는 폐기하기 전까지 만료일까지 살아 있습니다. 옛 키를 쥔 사람이 있다면, 그 옛 인증서로 이 사이트인 척할 수 있습니다. 패치, 새 키, 새 인증서, 옛 인증서 폐기에 세션 무효화까지 마쳐야 이 사이트는 앞으로의 통신을 다시 지킬 수 있고, 사용자의 비밀번호 변경은 그 뒤의 일입니다. 그래도 그 전에 누군가 가로채 둔 통신은 여전히 풀릴 수 있다고 발견자는 적었습니다 (발견자 Codenomicon 해설 페이지).

실제로 그 일이 얼마나 됐는지는 하트블리드를 자연 실험으로 삼은 측정 연구가 쟀습니다. 인증서 재발급과 폐기는 대부분 사람이 손으로 하는 관리 절차인데, 하트블리드가 공개되고 3주가 지난 뒤에도 취약했던 인증서의 73% 넘게가 재발급되지 않았고 87% 넘게가 폐기되지 않았습니다. 하트블리드 발표 직후에도 주말에는 폐기가 크게 줄었습니다 (DOI: 10.1145/3176244). 패치를 깔아도 끝나지 않았습니다. 새 인증서를 받고 옛 이름표를 거두는 일은 사람이 손으로 하는 절차였고, 더뎠습니다.

폐기된 이름표를 알아보는 체계도 약했습니다. 2015년에도 인증서가 얼마나 자주 폐기되는지, 브라우저가 어떤 상황에서 폐기 여부를 확인하는지는 잘 이해되지 않은 상태였습니다 (DOI: 10.1145/2815675.2815685). 인증서가 아직 유효한지 묻는 대표적인 방식인 OCSP는 느린 성능, 불안정함, 확인이 실패해도 그냥 넘어가는 문제, 사생활 문제로 비판받았고, 이를 보완하는 장치에 웹 전체가 준비됐는지는 2018년에도 열린 물음이었습니다 (DOI: 10.1145/3278532.3278543). 자기 대안을 제안하는 2025년의 한 논문은 25년 동안 이어진 「실패해도 넘어가는」 규칙과 사생활 유출, 흔들리는 기반을 들어 웹의 폐기 체계가 깊이 실패했다고 주장하고, 폐기 응답의 62%를 콘텐츠 전송망 회사 한 곳이 내보내 신뢰가 다시 한곳에 몰렸다고 측정했습니다 (DOI: 10.1145/3718958.3754351). 이 세 연구가 다룬 것은 하트블리드 자체가 아니라 그 전후의 웹 폐기 체계입니다.

고친 뒤에 남은 일은 사람 손에 달려 더뎠고, 폐기를 알아보는 체계도 그 일을 끝까지 받쳐 주지 못했습니다.

같은 종류의 실수를 언어가 막을 수 있나

하트블리드는 C 언어로 쓴 OpenSSL에서 일어났습니다. 메모리 안전성(memory safety)은 프로그램이 잡아 둔 칸 밖을 읽거나 쓰는 것 같은 메모리 오류를 일으킬 수 없도록 보장되는 성질입니다. C나 C++처럼 기계에 가까운 언어에서 메모리를 덮어써 망가뜨리는 오류는 컴퓨터 보안에서 가장 오래된 문제 가운데 하나로, 30년 넘게 이어졌고 수많은 해법이 나왔지만 여전히 심각한 위협입니다. 더 엄격한 보호 장치가 널리 쓰이지 않은 큰 이유는 성능이었고, 경험상 부담이 적당한 범위 안에 드는 해법만 실제로 배치됐습니다 (DOI: 10.1109/sp.2013.13). 하트블리드는 같은 메모리 오류 가족 가운데 덮어쓰기가 아니라 넘겨 읽기 쪽입니다.

C에 경계 검사를 덧씌우는 일도 시도됐습니다. C와 C++가 경계 검사를 하지 않아 생기는 심각한 버그와 취약점은 잘 알려져 있지만, C의 포인터 계산 방식과 메모리 배치 때문에 나중에 공간 안전을 보장하는 장치를 덧씌우기가 극히 어렵습니다. 소스 코드를 고치지 않고 모든 경계 위반을 잡는 한 방식은 실행 시간이 평균 67% 늘었습니다 (DOI: 10.1145/1543135.1542504). 넘겨 읽기 쪽에는 덮어쓰기를 겨냥한 기존 방어 다수가 맞지 않거나 실용적이지 않습니다. 다만 경매 사이트를 본뜬 시험용 모형에서는 간단한 기법만으로도 적당한 성능 비용에 정보 유출을 크게 줄였습니다 (DOI: 10.1109/dsn.2015.59). 모형 위의 결과이고, 실제 서버에서 잰 값은 아닙니다.

언어를 바꾸는 길도 있습니다. Rust는 효율을 크게 잃지 않으면서 메모리 안전 버그를 막는 것을 목표로 한 프로그래밍 언어입니다 (DOI: 10.1145/3466642). 다만 Rust에는 빠져나갈 문이 있습니다. unsafe는 Rust에서 컴파일러의 안전 규칙 일부를 면제받고, 그 구역의 안전은 프로그래머가 책임지도록 표시한 코드입니다. 2020년 말까지 나온 Rust의 메모리 안전 관련 CVE를 모두 담은 버그 보고를 분석한 연구는, 메모리 안전 버그가 모두 unsafe 코드를 필요로 했다며 Rust가 이 약속을 지킨다고 결론지었습니다. 같은 연구는 그 가운데 다수가 unsafe 없이도 메모리 안전 버그를 쓸 여지를 남기는 가벼운 건전성 문제였다고 적었습니다 (DOI: 10.1145/3466642).

그 문은 생각보다 자주 열립니다. 실제 Rust 라이브러리 가운데 unsafe라는 표시를 직접 쓴 것은 30% 미만이었지만, 호출 사슬 어딘가에 숨은 unsafe 때문에 컴파일러가 전부 정적으로 확인할 수 없는 것은 절반이 넘었습니다 (DOI: 10.1145/3377811.3380413). unsafe 코드는 대부분 단순하고 잘 감싸여 있었지만, 특히 다른 언어로 쓴 코드와 맞물릴 때 널리 쓰였습니다 (DOI: 10.1145/3428204). Rust 생태계에 알려진 취약점에서는 메모리 안전과 동시성 문제가 거의 3분의 2를 차지했고, 취약한 코드에는 나머지 코드보다 unsafe 함수와 구역이 통계적으로 유의하게 많았습니다 (DOI: 10.1145/3624738). 이미 C로 쓴 큰 코드를 Rust로 손수 옮기는 일은 벅찬 작업이고, 자동으로 옮긴 프로그램에도 안전하지 않은 부분이 남습니다 (DOI: 10.1145/3485498).

TLS 라이브러리의 결함에는 메모리와 상관없는 종류도 있습니다. 널리 쓰이는 오픈소스 TLS 구현들에서 여러 규약 방식을 잘못 엮어 생긴 상태 기계 결함, 곧 메시지 순서를 다루는 논리의 결함이 발견됐습니다. 그 가운데 몇은 몇 해 동안 숨어 있었고, 네트워크 공격자가 인증된 연결에 끼어들 수 있게 했습니다. 저자들은 암호 라이브러리의 핵심 부품에 형식 검증이 필요하다고 주장했습니다 (DOI: 10.1109/sp.2015.39).

메모리 안전 언어는 하트블리드를 낳은 종류의 실수를 줄이는 도구이고, 그 약속은 unsafe 코드와 다른 종류의 결함 앞에서 끝납니다.

실제로 악용됐나 — 2014년의 「모른다」와 2022년의 목록

이 결함이 실제로 악용됐느냐는 물음에 발견자 페이지는 「모른다」고 답합니다 (발견자 Codenomicon 해설 페이지). 발견자 자신도 혹시 자기들이 처음 찾은 게 아니고 이미 악용됐을까 봐 자사 핵심 서비스를 힘들게 패치하고 키 문제를 다뤘다고 적었습니다 (발견자 Codenomicon 해설 페이지). CERT/CC의 「공격자가 이미 가져갔다고 가정하라」는 권고는 확인이 아닌 가정입니다 (CERT/CC 취약점 노트). 같은 노트는 이 결함의 악용 코드가 공개돼 있다고 적었습니다 (CERT/CC 취약점 노트).

공격 시도가 있었다는 기록은 있습니다. 앞의 사건 직후 측정 연구는 이 결함을 노린 실제 공격 시도를 드러냈다고 적었습니다 (DOI: 10.1145/2663716.2663755). 시도가 무엇을 가져갔는지는 그 초록에 없습니다.

미국 사이버보안·인프라보안청(CISA)이 이 결함을 「알려진 악용 취약점 목록」에 올린 날은 2022년 5월 4일입니다. 랜섬웨어 캠페인에 쓰였는지는 「Unknown」으로 적었습니다 (미국 CISA 악용 취약점 목록). 이 목록에 오르는 기준은 실제로 악용됐다는 신뢰할 만한 증거이고, 여기서 악용에는 시도와 성공이 모두 들어갑니다 (미국 CISA 악용 취약점 목록). 발견자의 2014년 「모른다」와 이 2022년 등재는 시점이 8년 다릅니다. 등재는 언제, 누가, 얼마나 악용했는지를 말해 주지 않고, 항목에도 그런 정보가 없습니다.

누가 악용했는지를 지목한 문서는 없습니다.

악용 시도가 있었다는 기록은 있지만, 무엇이 얼마나 새어 나갔는지는 이 글이 기댄 문서 가운데 어느 것도 적지 않았습니다.

돈 문제의 답도 열려 있습니다. 정부 연구비·기업 후원·소액 기부를 함께 받는 한 오픈소스 프로젝트의 유지보수자와 후원자를 인터뷰한 연구에서, 공공 자금과 민간 자금은 저마다 이득과 단점을 함께 가져왔습니다 (DOI: 10.1145/3678884.3681844). 어느 자금 방식이 기반 소프트웨어를 돌보는 데 맞는지는 한 사례 연구로 정해지지 않습니다.

의의 — 기부금 한 해 2,000달러에서 상근 두 명분으로

돈은 사건 뒤에 움직였습니다. 마퀘스에 따르면 사건 뒤 한 주 동안 약 200건, 대부분 5~10달러짜리 기부가 들어와 합계 약 9,000달러가 됐고, 그는 이것으로는 이토록 복잡하고 중요한 소프트웨어를 돌볼 인력을 유지하기에 턱없이 부족하다고 적었습니다 (OpenSSL 재단 대표의 글). 2014년 4월 24일, 비영리 컨소시엄인 리눅스 재단은 핵심 인프라 이니셔티브(CII)를 결성한다고 발표하며 이것을 하트블리드 위기에 대한 업계의 집단적 대응이라고 불렀습니다. 창립 후원사에는 Amazon Web Services·Cisco·Google·IBM·Intel·Microsoft 등이 들어 있었습니다 (리눅스 재단 발표). 규모는 수백만 달러 단위였고, 핵심 개발자가 상근으로 일할 수 있는 지원금·보안 감사·시험 인프라를 지원하며, 첫 검토 대상은 OpenSSL이었습니다 (리눅스 재단 발표). 리눅스 재단은 위기가 난 뒤에 손을 벌리는 방식을, 가장 중요한 프로젝트의 필요를 미리 살피는 방식으로 바꾸겠다고 했습니다 (리눅스 재단 발표).

5월 29일에 첫 지원 대상이 발표됐습니다. 시간 동기화의 NTP, 원격 접속의 OpenSSH, 그리고 OpenSSL이었습니다. 발표에 따르면 OpenSSL은 상근 핵심 개발자 두 명분의 자금을 받게 되고, 별도로 오픈 크립토 감사 프로젝트(OCAP)가 OpenSSL 코드의 보안 감사를 위한 자금을 받게 됩니다 (리눅스 재단 발표). 사건 직후 마퀘스가 말한 상근 한 명과 이 두 명분은 시점이 다른 두 숫자입니다.

하트블리드는 경계 검사 하나가 빠진 결함이었고, 당사자 측과 업계는 그런 결함을 찾아낼 사람과 돈이 모자랐던 구조를 함께 가리켰습니다. 고친 판본은 공개되던 날 나왔지만, 인증서를 새로 받고 옛것을 거두는 일은 공개 3주 뒤에도 대부분 끝나지 않았습니다. 실제로 무엇이 새어 나갔는지는 이 글이 기댄 문서 가운데 어느 것도 적지 않았습니다.

이 사건에서 고친 뒤에도 남은 일은 열쇠와 이름표였습니다. 그 열쇠와 이름표가 어떻게 짜여 있는지는 「열쇠와 자물쇠 — 공개키는 왜 공개해도 안전한가」가 다룹니다. 여러 프로그램 속에 숨은 작은 부품 하나가 패치 뒤에도 오래 남는 이야기는 「Log4j 취약점 — 벽 속에 묻힌 부품은 누가 찾아내나」에서, 유지보수자의 부담과 오래 쌓은 신뢰의 이야기는 「xz 유틸리티 백도어 — 몇 해에 걸쳐 쌓은 신뢰, 느려진 로그인에 들키다」에서 이어집니다.

사건 자료

• "OpenSSL Security Advisory [07 Apr 2014] — TLS heartbeat read overrun (CVE-2014-0160)" (2014-04-07) — https://www.openssl.org/news/secadv/20140407.txt — 유지보수 측 당사자 공지. 결함 한 줄 요약(경계 검사 누락, 최대 64k), 영향 판본, 발견·수정 크레딧, 고친 판본 1.0.1g.
• "The Heartbleed Bug" (2014-04-07 공개, 최종 갱신 2025-03-07) — https://heartbleed.com/ — 발견자 Codenomicon(보안 테스트 회사)의 해설. 독립 발견과 공개 경과, 새는 것의 네 갈래, 회복 절차, 영향 범위, 악용 여부 「모른다」, 재발 방지 제언.
• "CVE-2014-0160" (등록 2014-04-07, 최종 수정 2026-06-17) — https://nvd.nist.gov/vuln/detail/CVE-2014-0160 — 미국 국립표준기술연구소(NIST)의 국가 취약점 데이터베이스(NVD) 항목. 공식 설명(버퍼 과다 읽기), 심각도 점수, 약점 분류.
• "VU#720951 - OpenSSL TLS heartbeat extension read overflow discloses sensitive information" (2014-04-07 공개, 최종 갱신 2016-05-13) — https://www.kb.cert.org/vuls/id/720951 — CERT 조정센터의 취약점 노트. 영향과 해법, 키 재생성·폐기 권고, 공급사 통지 기록.
• "CISA Catalog of Known Exploited Vulnerabilities" CVE-2014-0160 항목과 등재 기준 (등재 2022-05-04) — https://www.cisa.gov/known-exploited-vulnerabilities — 미국 사이버보안·인프라보안청(CISA)의 악용 취약점 목록. 등재일·조치 기한·랜섬웨어 사용 여부, 「신뢰할 만한 악용 증거」 기준.
• "Of Money, Responsibility, and Pride" (2014-04-12) — http://veridicalsystems.com/blog/of-money-responsibility-and-pride/ — OpenSSL 소프트웨어 재단 대표 스티브 마퀘스의 개인 글. 기부금·인력·자금 구조에 대한 당사자 측 의견.
• "Amazon Web Services, Cisco, Dell, Facebook, Fujitsu, Google, IBM, Intel, Microsoft, NetApp, Rackspace, VMware and The Linux Foundation Form New Initiative to Support Critical Open Source Projects" (2014-04-24) — http://web.archive.org/web/20140425124353/http://www.linuxfoundation.org/news-media/announcements/2014/04/amazon-web-services-cisco-dell-facebook-fujitsu-google-ibm-intel — 리눅스 재단의 핵심 인프라 이니셔티브(CII) 결성 발표.
• "The Linux Foundation's Core Infrastructure Initiative Announces New Backers, First Projects to Receive Support and Advisory Board Members" (2014-05-29) — https://www.linuxfoundation.org/press/press-release/the-linux-foundations-core-infrastructure-initiative-announces-new-backers-first-projects-to-receive-support-and-advisory-board-members — CII의 첫 지원 대상(NTP·OpenSSH·OpenSSL), OpenSSL 상근 개발자 2명분 자금과 OCAP의 OpenSSL 코드 보안 감사 자금(발표 시점의 예정).

근거 논문

• "The Matter of Heartbleed" (2014) — DOI: 10.1145/2663716.2663755 — 사건 직후 측정 연구. 인기 HTTPS 사이트의 24~55%가 취약했다고 추정, 패치 추적, 인증서 생태계 영향, 실제 공격 시도 탐지, 15만 대 통지 실험에서 패치 약 50% 증가.
• "Analysis of SSL certificate reissues and revocations in the wake of heartbleed" (2018) — DOI: 10.1145/3176244 — 하트블리드를 자연 실험으로 삼아, 공개 3주 뒤에도 취약 인증서의 73% 넘게 미재발급·87% 넘게 미폐기, 주말 폐기 급감.
• "An End-to-End Measurement of Certificate Revocation in the Web's PKI" (2015) — DOI: 10.1145/2815675.2815685 — 인증서 폐기 빈도와 브라우저의 폐기 확인 조건은 아직 잘 이해되지 않았다는 문제 제기.
• "Is the Web Ready for OCSP Must-Staple?" (2018) — DOI: 10.1145/3278532.3278543 — OCSP는 느림·불안정·소프트 페일·사생활 문제로 비판받고, 보완 장치(Must-Staple)에 웹 전체가 준비됐는지는 열린 물음.
• "Reliable and Decentralized Certificate Revocation via DNS: The Case for RevDNS" (2025) — DOI: 10.1145/3718958.3754351 — 대안(RevDNS)을 제안하는 논문. 25년의 소프트 페일·사생활 유출·불안정 기반으로 웹 PKI 폐기가 깊이 실패했다고 주장, 폐기 응답의 62%를 한 CDN이 제공한다고 측정.
• "SoK: Eternal War in Memory" (2013) — DOI: 10.1109/sp.2013.13 — C/C++ 메모리 오류는 30년 넘은 문제, 배치된 보호는 무너질 수 있고 엄격한 장치가 안 쓰인 주된 이유는 성능.
• "SoftBound" (2009) — DOI: 10.1145/1543135.1542504 — C에 공간 안전을 덧씌우는 컴파일 시 변환. 완전 검사 모드 평균 실행 부담 67%.
• "Risk Assessment of Buffer "Heartbleed" Over-Read Vulnerabilities" (2015) — DOI: 10.1109/dsn.2015.59 — 과다 읽기에는 기존 덮어쓰기 방어가 맞지 않거나 비실용적. 경매 사이트 시험 모형에서 간단한 기법도 적당한 비용으로 유출을 크게 줄임.
• "Memory-Safety Challenge Considered Solved? An In-Depth Study with All Rust CVEs" (2021) — DOI: 10.1145/3466642 — 2020년 말까지의 Rust 메모리 안전 CVE 186건 분석. 모든 메모리 안전 버그가 unsafe 코드를 필요로 함, 다수는 가벼운 건전성 문제.
• "Is rust used safely by software developers?" (2020) — DOI: 10.1145/3377811.3380413 — unsafe 표시를 쓴 라이브러리는 30% 미만이나, 호출 사슬의 unsafe 때문에 절반 넘게가 전부 정적 확인 불가.
• "How do programmers use unsafe rust?" (2020) — DOI: 10.1145/3428204 — unsafe는 대부분 단순하고 잘 감싸였으나 특히 다른 언어와의 연동에서 광범위하게 쓰임. 「Rust 가설」은 부분적으로만 지지.
• "A Closer Look at the Security Risks in the Rust Ecosystem" (2023) — DOI: 10.1145/3624738 — Rust 생태계 취약점 433건 중 메모리 안전·동시성 문제가 거의 3분의 2, 취약 코드에 unsafe가 유의하게 많음.
• "Translating C to safer Rust" (2021) — DOI: 10.1145/3485498 — C를 Rust로 손수 옮기기는 벅차고, 자동 번역 프로그램에 남는 안전하지 않은 부분의 원인 분석과 제거 기법.
• "A Messy State of the Union: Taming the Composite State Machines of TLS" (2015) — DOI: 10.1109/sp.2015.39 — 오픈소스 TLS 구현에서 몇 해 숨어 있던 상태 기계 결함 발견, 형식 검증 필요 주장.
• "Underproduction: An Approach for Measuring Risk in Open Source Software" (2021) — DOI: 10.1109/saner50967.2021.00043 — 일손 공급이 수요와 어긋나는 「과소 생산」 개념, 데비안 21,902개 패키지·461,656건 버그 분석에서 널리 설치된 부품의 광범위한 과소 생산.
• "Open Source Software Developers' Views on Public and Private Funding: A Case Study on scikit-learn" (2024) — DOI: 10.1145/3678884.3681844 — 한 오픈소스 프로젝트의 유지보수자·후원자 인터뷰 25차례로 본 공공·민간 자금의 이득과 단점.