Programming 이슈, 4월 1주. Heartbleed Bug

1.
Heartbleed Bug 소스 분석

요약
Heartbeat라는 기능이 있는데(아마도 서버가 살아있는지 체크?), 이때 유저가 패킷에 데이터를 보낼때 실제 보내는 데이터 크기에 관계없이 데이터 길이 값을 유저가 맘대로 넘겨줄 수 있음(이걸 서버가 체크하지 않은게 첫번째 잘못)
서버는 응답으로 유저가 보낸 데이터를 다시 되돌려 보내주는데 이때 유저가 데이터 길이 값을 일부러 실제보다 크게 적어서 보내줬다면 서버는 실제 유저가 보내준 데이터 범위를 넘어서 서버 메모리 내 인접한 다른 영역까지 복사해서 줄 가능성이 있음. 최대 64KB(버퍼 길이 필드가 2바이트이므로)

게다가 리눅스에서 malloc의 특성상 유저 정보등 민감한 정보가 같은 메모리 블록에 존재할 확률이 높아서 버퍼 오버런시에 해당 정보가 쉽게 노출이 됨. (보충 : 2번 링크에서의 추가 설명에 의하면 커스터마이징 된 malloc함수에 의해 여러 차례의 메모리 할당 요청이 같은 메모리 블록내에서 이뤄지게끔 되어있음.(퍼포먼스 개선을 위해), 그래서 더욱더 민감한 유저 정보를 가져오기 쉬웠음.)

2.
Heartbleed Bug 의 숨겨진 원인

malloc을 커스터마이즈 해버렸기 때문에 각종 메모리 보호 툴들이 설치된 시스템에서도 메모리 오버런을 감지하지 못했음. 그렇지 않았다면 진작 밝혀졌을 것을.

이번 이슈의 잘못들

A custom allocator that is written in a way so that it won’t crash or show any unusual behavior when allocation bounds are overrun even after many requests.

A custom allocator that favours re-using recently used areas of memory. Which as we’ve seen, tends to lead it to it expose recently decoded https requests.

Avoidance of third party memory testing measures that test against such flaws under the guise of speed on some platforms.

A Heartbeat feature that actually responds to users that haven’t got any sort of authorization.

A Heartbeat feature that has no logging mechanism at all.

A Heartbeat feature that isn’t part of the TLS standard and isn’t implemented by any other project.

A Heartbeat feature that was submitted in a patch on 2011-12-31 which is before the RFC 6520 it’s based on was created. By the same author as the RFC.

Code that is extremely obfuscated without reason.

교훈