flawopen.com/보안 사고/Heartbleed

Heartbleed: 단 한 줄의 길이 검사 누락이 인터넷 절반을 마비시키다

Critical — Memory disclosure CWE-125: Out-of-bounds Read Disclosed 7 April 2014
쉬운 설명 (ELI5)

동료에게 '고양이라는 단어를 따라 해줘. 길이는 3글자야'라고 외치면 동료는 '고양이'라고 답합니다. 이번에는 '고양이라는 단어를 따라 해줘. 길이는 6만 글자야'라고 외칩니다. 동료는 실제 길이를 검증하지 않고 '고양이'를 말한 뒤 책상에 놓인 다른 직원들의 비밀번호와 비밀문서를 줄줄이 읽어버립니다.

The fix is two comparisons. That ratio — a two-line check against a two-year, internet-wide exposure — is the reason Heartbleed became the standard illustration of how little code stands between working software and catastrophic failure.

Why remediation was so painful

Patching OpenSSL was the easy part. The hard part followed from a property of the bug: because it was silent and untraceable, no operator could prove they had not been exploited. With no logs to examine, the only defensible assumption was that every secret resident in the process memory during the exposure window had leaked.

That meant regenerating private keys, reissuing and revoking certificates at a scale the certificate authority ecosystem had never handled at once, invalidating every session, and prompting global password resets. Deployments without forward secrecy were worse off again: an attacker who had recorded encrypted traffic earlier could decrypt it retroactively once they held the key.

The lessons that actually transfer

FAQ

Why is it called an over-read rather than an overflow?

An overflow writes past a boundary, corrupting adjacent memory and often enabling code execution. An over-read only reads past it. Heartbleed never corrupted anything — it simply handed the attacker memory contents, which in this case was more than sufficient.

Could the private key really be recovered?

Yes. It was not guaranteed on any given request, but private key material can reside in the same heap. Repeated requests sampling different memory made recovery practical, and it was demonstrated publicly.

Related reading

출처 및 공식 보안 권고