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

오픈소스 소프트웨어 보안은 코드를 꼼꼼히 살피고 버그를 찾아내 이를 고치는 프로그래머들의 능력에 달려있다. 이는 “두 눈 크게 뜨고 잘 감시한다면 버그는 걱정할 것 없다”는 법칙인 ‘리누스의 법칙(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을 개발하지 말라고 무작정 강요하는 것은 무리가 있다. 대신 그 역량을 누리는데 따르는 책임을 외면하지 않으면 된다”라고 말했다.

오픈SSL, 트루크립트(Truecrypt)를 통해 보는 오픈소스 코드 리뷰의 한계
수많은 오픈소스 프로젝트들이 직면한 문제 중 하나는(그리고 세글먼이나 오픈SSL 개발팀 개인의 실책을 묻기 어려운 이유는) 꼼꼼한 코드 보안 리뷰 작업을 하려면 엄청난 시간과 고도의 기술이 필요하다는 것이다. 즉, 제대로 된 코드 리뷰를 위해서는 돈이 많이 들어간다.

이는 트루크립트 암호화 프로그램이라는 오픈소스 프로젝트를 통해서도 잘 드러났다. 10년 전 프로젝트가 시작됐을 때부터 코드는 모든 이에게 개방돼 있었다. 그렇지만 이 코드가 제대로 된 보안 검사를 받은 것은 최근 인디에고 및 펀드필(Indiego and Fundfill)의 펀드레이징 캠페인을 통해 6만 달러가 모이고 나서였다.

부트스트랩 로더와 윈도우즈 커널 드라이버만 살펴 보았는데도 11개의 취약점이 발견 되었다. 이 초기 보고서에 따르면 소스 코드의 질이 매우 낮았으며 트루크립트를 컴파일링 하기 위해서는 (21년씩이나 지난) 오래되고 검증되지 않은 빌드 툴을 사용해야 했으며 이 때문에 악성 공격을 당할 가능성이 높고 믿을 만한 소스로부터의 접근하기가 어려웠다.

코드 리뷰어들은 “전반적으로, 부트스트랩 로더와 윈도우 커널 드라이브의 소스 코드는 소스 코드 기대 표준을 충족하지 못했다”라고 평가했다.

우려를 야기하는 부분은 이것이 코드 리뷰 수행을 위한 자원 채용을 위한 펀드 모금 이후에 알려진 사실이라는 점이다. 오픈소스 커뮤니티는 지난 10년 간 이를 수행할 충분한 기회를 가지고 있었다. 시간과 기술, 자원(돈을 포함한)은 절대 부족하지 않았다.

오픈SSL을 방해하는 보안 문제도 있다. 오픈BSD 팀의 리브르SSL(LibreSSL)이라는 이니셔티브 덕분에 코드가 갈라지게 된 것이다. 리브르 SSL은 오픈SSL에서 불필요한 군살을 뺀 기본형으로 디자인 되었다. 리브르SSL 프로젝트의 첫 주에만 VMS나 OS/2같은 운영 체제를 지원하는 코드 등을 포함해 9만 줄이 넘는 잉여 코드가 제거됐다.

간단히 말해, 문제는 다음과 같다. 리브르SSL에서 어떤 코드가 제거되고 어떤 코드가 불안전한 것으로 판명돼 대체되었는지 확연히 볼 수 있기 때문에, 해커들이 이러한 취약점을 이용해 악성 공격을 시도하면 오픈SSL 사용자들은 이에 고스란히 노출될 수 밖에 없다는 것이다. 오픈SSL 프로젝트가 리브르SSL 프로젝트를 따라잡지 못한다면 말이다.

물론 뭐가 뭔지 알 수 없는 애매모호한 상태를 통해 취약점을 감춰보겠다는 것도 좋은 생각은 아니지만, 취약점이 백일하에 드러나게 될 경우 당장 고쳐야 한다. 그런데 오픈SSL 팀이 과연 그렇게 할 수 있을지 확실치 않다. 오픈SSL 프로젝트에 풀-타임 작업자가 한 명뿐이라는 이야기도 있고, 오픈SSL을 사용하는 소프트웨어 및 하드웨어 제품을 곧바로 업데이트 해야 한다는 이야기도 있다.

하트블리드 이후, 오픈소스 보안을 좀더 진지하게 받아들일 때
오픈SSL과 같은 오픈소스 프로젝트의 보안 문제를 걱정하는 이들에게 반가울 소식이 있다. 하트블리드(Heartbleed) 취약성 사태 이후 리눅스 재단이 후원하는 코어 인프라 이니셔티브(CII, Core Infrastructure Initiative)라는 새로운 프로젝트가 윤곽을 잡아가며 산업에 활력을 불어넣을 것으로 기대되고 있는 것이다. 이것의 목표는 인터넷 기능에 핵심적인 역할을 하는 오픈SSL과 같은 소프트웨어 프로젝트들에 그것들이 요구하는 수준의 자금을 공급하는데 있다.

리눅스 재단의 전무 짐 젬린은 “세계 경제는 수많은 오픈소스 프로젝트를 기반으로 건설됐다. 이제는 더 많은 개발자 및 작업자들이 풀 타임으로 오픈소스 프로젝트를 관리할 수 있도록 지원해야 한다”고 주장했다.

CII에 대한 지원에는 보안 감사 및 컴퓨팅, 테스트 인프라를 위한 투자도 포함된다. 지금까지 구글, 마이크로소프트, 페이스북 등의 기업들이 향후 3년 간 약 400만 달러의 자금을 지원할 것을 약속한 상태다.

*Paul Rubens는 영국에 거주하는 테크놀로지 저널리스트다. dl-ciokorea@foundryco.com