칼럼 | 생각만큼 오픈소스SW가 안전하지 않은 이유

2014.06.16 Paul Rubens | CIO

오픈 SSL 하트블리드(OpenSSL Heartbleed)의 악몽으로 많은 이들이 오래도록 의심해 온 것이 사실로 밝혀졌다. 오픈소스 소프트웨어가 철저한 검열 대상이라고 해서 실제로 철저한 검열이 이뤄진다거나 반드시 안전한 것은 아니라는 것이다.

오픈소스 소프트웨어 보안은 코드를 꼼꼼히 살피고 버그를 찾아내 이를 고치는 프로그래머들의 능력에 달려있다. 이는 “두 눈 크게 뜨고 잘 감시한다면 버그는 걱정할 것 없다”는 법칙인 ‘리누스의 법칙(Linus’s Law)’에 잘 나타나 있다.

하지만 오픈SSL 참사를 보면 이러한 믿음이 철저히 무너진다. 뮌스터 대학 출신 독일 프로그래머 로빈 세글먼은 하트비트 킵-어라이브(Heartbeat keep-alive) 기능을 추가해 오픈SSL 코드를 업데이트 했다. 불행하게도 그의 실수 때문에 코드를 제대로 확인하지 않았고, 코드를 배포하기 전 이를 확인했던 오픈SSL 개발팀 역시 이를 놓치고 말았다. 그리고 하트블리드 버그가 탄생한 것이다.

버그가 있다는 확신이 없는 상태에서는 누구라도 이런 실수를 저지를 수 있다. 문제는, 2년이 넘는 시간 동안 오픈SSL과 브라우저, 웹 서버 등에 하트블리드 버그가 존재해 했는데도 오픈소스 커뮤니티 내의 그 누구도 이를 알아채지 못했다는 것이다. ‘두 눈 크게 뜨고’ 감시한 사람이 없었다는 뜻이다.

상용 업체들은 오픈소스 코드를 따로 검토하지 않는다

또 한가지 문제는 오픈SSL이 F5 네트웍스, 시트릭스시스템즈, 리버베드 테크놀로지, 버라큐다 네트웍스 같은 상용 업체들의 하드웨어 구성 요소로 쓰였다는 것이다. 그리고 포럼 시스템즈(Forum Systems)의 CEO인 마문 유누스에 따르면, 이들 업체 중 누구도 코드를 사용하기 전 문제점을 알아채지 못했다고 한다.

“오픈 SSL을 상업화하는 입장에 있는 사람이라면 그 안전성을 철저하게 검증할 의무가 있다. 오픈소스에 기반한 기업을 운영한다면 코드 자체의 소유권을 가지고 있어야 한다”고 그는 말했다.

그런데도 많은 업체들이 오픈SSL을 단순히 하드웨어 제품을 만드는 데 유용한 도구 정도로 취급하고 있다고 유누스는 말했다. 게다가 ‘오픈소스’다 보니 나 말고 다른 사람이 제대로 살펴 보았겠지 하고 넘어간다는 것이다. “다들 남들이 어련히 알아서 했겠지 하며 신경 쓰지 않았다. 바로 이 점 때문에 오픈소스의 보안이 취약해 지는 것”이라고 그는 밝혔다.

유누스는 상용 업체들이 자신들이 활용하는 모든 오픈소스 코드에 효율적인 상호 리뷰 프로그램을 적용해야 하며, 또한 그 전반에 정적, 동적 분석 도구를 운영하고 버그 안정성 확보를 위한 코드 ‘유연화'에도 신경 써야 한다고 강조했다. 그는 “지난 10년, 15년 간 이 기업들이 한 일이 무엇인가? 내가 IT업체였다면, 장기적이고 철저한 품질 보증(QA) 과정에 보다 신경을 썼을 것이다”라고 전했다.

그는 또 오픈SSL에 C언어 같은 저급 언어를 이용하는 것이 옳은가에 대한 의문을 던진다. 이는 보안 전문가 브루스 슈나이어와도 비슷한 관점이다. 그토록 보안이 중요한 애플리케이션에 메모리 매니지먼트가 취약한 언어를 사용하는 것은 ‘거의 범죄 행위’라는 것이다.

포레스터 리서치의 보안 애널리스트 제프리 해먼드는 이와는 다른 시각을 견지했다. 그는 오픈SSL의 핵심 속성은 실행 역량이라고 말했다. 대규모 패킷을 다룰 수 있어야 하기 때문이다. 해몬드는 “일부 공격 유형에 취약한 메모리가 더 높은 성능을 담보해주는 경우도 있다. C 언어로 오픈SSL을 개발하지 말라고 무작정 강요하는 것은 무리가 있다. 대신 그 역량을 누리는데 따르는 책임을 외면하지 않으면 된다”라고 말했다.