CVE-2014-0160 (Heartbleed): OpenSSL 하트비트가 새어나간 메모리

Heartbleed는 SSL/TLS 구현체로 인터넷 대부분의 암호화 통신에서 쓰이던 OpenSSL 라이브러리에서 발견된 메모리 노출 취약점이다. 2014년 공개 당시 전 세계 웹 서버의 상당수(추정치로 수십만 대 이상)가 영향을 받았고, "심장에서 피가 샌다"는 이름 그대로 서버 메모리에 있던 개인키, 세션 쿠키, 사용자 비밀번호 같은 민감 정보가 그대로 유출될 수 있었다.

Heartbeat 확장 기능이란

TLS의 Heartbeat 확장은 연결이 살아있는지 확인하기 위한 기능이다. 클라이언트가 임의의 데이터와 그 길이를 서버에 보내면, 서버는 같은 데이터를 그대로 돌려보내는 단순한 핑퐁 구조다.

클라이언트 → 서버: "이 데이터(길이: N바이트)를 그대로 돌려줘"
서버 → 클라이언트: (동일한 데이터, N바이트)

근본 원인: 길이 검증 누락

취약한 OpenSSL 코드는 클라이언트가 "길이는 N바이트"라고 주장한 값을 그대로 믿고, 실제로 보낸 데이터의 실제 길이와 대조하지 않았다. 공격자가 실제로는 1바이트짜리 데이터만 보내면서 "이건 64KB짜리 데이터야"라고 주장하면, 서버는 그 1바이트 뒤에 이어지는 서버 프로세스 메모리의 나머지 부분(공격자가 보낸 적 없는 데이터)까지 그대로 응답에 채워서 돌려보냈다.

// 개념적으로 이런 문제였다
memcpy(response_buffer, payload, claimed_length);  // claimed_length를 검증 없이 그대로 사용

이건 전형적인 버퍼 오버리드(over-read) 취약점이다 — 쓰기가 아니라 읽기 방향으로 경계를 넘는다는 점에서 스택 버퍼 오버플로우와는 성격이 다르지만, "길이를 검증하지 않고 신뢰한다"는 근본 원인은 동일한 패턴이다.

왜 이렇게 치명적이었나

한 번의 요청으로 서버 메모리의 최대 64KB를 읽어갈 수 있었고, 이 요청을 반복하면 서버 프로세스 메모리를 계속 다른 조각으로 훑어볼 수 있었다. 서버 프로세스 메모리에는 그 시점에 처리 중이던 다른 사용자의 세션 쿠키, 로그인 정보, 심지어 서버의 TLS 개인키(private key) 조각까지 우연히 포함될 수 있었다. TLS 개인키가 유출되면 그 인증서로 이루어지는 모든 통신을 사후에 복호화하거나, 해당 서버를 완벽하게 사칭하는 것까지 가능해진다 — 단순 정보 유출을 넘어 신뢰 체계 자체가 무너지는 결과다.

특히 무서웠던 지점

• 인증이 전혀 필요 없었다. 익명 상태로 TLS 핸드셰이크만 시작하면 누구나 시도할 수 있었다.
• 공격 흔적이 거의 남지 않았다. 정상적인 Heartbeat 요청처럼 보여서, 사후에 "언제부터 얼마나 유출됐는지"를 로그로 확인하기가 매우 어려웠다. 이 때문에 많은 조직이 "유출 여부를 확신할 수 없으니 모든 인증서를 전부 재발급"하는 보수적인 대응을 택했다.

패치와 대응

1. OpenSSL 버전 업그레이드 (1.0.1g 이상으로) — 실제 전송된 데이터 길이와 주장된 길이를 대조하는 검증 로직 추가
2. TLS 인증서 재발급: 개인키가 유출됐을 가능성을 배제할 수 없으므로, 영향받은 모든 서버의 인증서를 폐기하고 새로 발급
3. 모든 사용자 세션/비밀번호 재설정: 유출 가능성이 있는 세션 토큰을 전부 무효화

이 사건이 남긴 교훈

• 인터넷 인프라 대부분이 소수의 오픈소스 라이브러리에 의존한다는 사실이 이 사건으로 명확히 드러났고, 이후 OpenSSL 같은 핵심 인프라 프로젝트에 대한 펀딩/감사(audit) 지원이 크게 늘어나는 계기가 됐다 (Core Infrastructure Initiative 등)
• "길이 필드는 항상 실제 데이터와 대조 검증한다"는, 어떻게 보면 아주 기본적인 원칙이 지켜지지 않아서 생긴 문제였다 — 아무리 널리 쓰이고 오래된 코드라도 기본 검증이 빠질 수 있다는 경각심을 남겼다
• 유출 흔적이 로그에 남지 않는 유형의 취약점은 사후 대응 자체를 훨씬 어렵고 보수적으로 만든다는 것도 이 사건의 중요한 시사점이다