오픈소스의 두 얼굴··· 탁월한 가치, 만만치 않은 맹점

CSO
오늘날 IT 시장의 주연 중 하나는 단연 오픈소스다. 그러나 오픈소스가 모든 문제의 해답일 수는 없다. 오히려 고유의 강점이 문제를 일으키는 원인이 되기도 한다. 오픈소스의 지위가 높아지는 만큼, 그에 관한 진지한 고민 역시 필요한 시점이다.

코어 시큐리티(Core Security)에서 선진 보안 및 전략 사업부를 이끌고 있는 에릭 코퍼스웨이트 부사장은 CSO와의 인터뷰에서 “오픈소스 코드가 마침내 세계를 정복했다”라고 표현했다.

오픈소스는 다양한 강점과 명확한 가치를 가지고 있다. 시장의 사용자들은 이를 이미 잘 알고 있다. 오픈소스의 최대 매력은 이용함에 있어 별도의 비용이 들어가지 않는다는 점이다. 모두에게 공개되어 있고 누구라도 그것을 원하는 대로 커스텀 할 수 있다는 점은 오픈소스 생태계를 더욱 풍성하고 활발하게 만들어줬다. 생태계가 풍부해질수록 참여자는 더욱 늘어났고, 그들의 적극적인 참여 덕택에 발생하는 버그나 결함은 빠르게 수정된다.

레드스핀(Redspin)의 보안 엔지니어 앤드류 오스타셴은 “소스코드가 세계 누구에게나 열려있는 상황에서는 동일한 설정의 사용자가 수많도록 존재하게 된다. 특정 문제가 발생했을 때 그것의 발견과 해결의 가능성이 훨씬 커지게 되는 것이다”라고 설명했다.

오픈소스의 현재 입지에 관해 대다수의 보안, 법률 전문가들 역시 오스타셴과 같은 시각을 드러내고 있다. 시각이 엇갈리기도 하지만, 심각한 문제를 제기하지는 않는 분위기다. 그러나, 오픈소스가 완벽한, 그리고 모두에게 적합한 솔루션인 것은 절대 아니라는 경고의 목소리도 곳곳에서 들려오고 있다. 기업, 개인 사용자들이 오픈소스를 이용하는 과정에 조금은 주의를 기울일 필요가 있다는 시각들이다.


Credit: SGT Pablo Piedra


전문가에 따라서는 오픈소스의 강점으로 이야기되는 것들이 때론 위험 요소가 될 수 있다는 점을 지적한다. 가장 먼저, 특정 취약성이 모두에게 공유된다는 점은 공격자들 역시 그것을 알아차릴 수 있다는 말이 된다. 또한 수백 만의 눈이 오픈소스를 향하고 있다고 해서 모든 결함이 간단히 발견, 해결되리란 보장도 없는 것이 사실이다.

어큐번트(Accuvant)의 솔루션 연구 디렉터 라팔 로스는 “일부는 오픈소스의 공개성, 즉 ‘모든 사람이 소스코드를 리뷰할 수 있다는’ 특성이 오픈소스의 보안 수준을 높여준다고 주장하고 있다. 하트블리드(Heartbleed) 등 각종 버그 사례가 이미 확인됐는데도 이런 믿음을 가지고 있다는 사실이 당혹스러울 뿐이다”라고 말했다.

KNOS 프로젝트의 공동 설립자이자 최고 아키텍트인 케빈 맥컬리비는 “오픈소스의 취약성은 ‘공개된 상처’다”라고 표현했다.

맥컬리비는 “오픈소스는 그 소스 코드를 공개하며, 많은 이들이 그것을 검토할 수 있다. 코드 오류가 금새 노출될 수 있는 구조다. 그런데 하드블리드 사태를 보면, 2012년 2월 배포 이후 늘 그 자리에 있던 코드 오류가 그 ‘많은 눈들’에 발견되지 않았다. 2년 넘게 말이다. 결국 사고가 터졌고, 그 피해는 막대했다”라고 지적했다.

2005년 배포 이후 1년만에 문제가 발견된 GNUTLS 내 ‘고스트(Ghost)’ 익스플로잇 역시 맥컬리비를 비롯한 전문가들이 자주 인용하는 사례다.

맥컬리비는 “이 또한 익스플로잇이 무수히 쌓일 때까지 아무도 문제를 알아차리지 못한 경우다. BASH 셸 내 ‘셸쇼크(Shellshock)’ 익스플로잇 역시 1989년 1.03 버전 이래로 많은 리뷰가 있어왔지만 결국 취약점이 공격되고 만 사례다”라고 말했다.

많은 이들이 참여한다고 해서 정확성과 세밀함을 보장하는 것은 아니라는 지적도 있다.

폴리&라드너(Foley&Lardner)의 아론 탄틀레프(Aaron Tantleff) 파트너는 “코드 리뷰어가 많다는 논거만으로 리뷰 품질을 증명하기는 무리가 있다. 리뷰어들의 역량을 판단할 근거나 인증은 어디에도 없다”라고 지적했다.

맥컬리비 역시 탄틀레프와 같은 입장을 보인다. 그는 “단순히 소스 코드를 공개하는 건 그리 큰 의미가 아니다. 그것을 열람하는 이들이 코드의 실제 역할, 혹은 거기에 존재하는 문제를 이해하는지의 여부가 더 중요하다”라고 이야기했다.

또한 결함이 발견 되어 패치가 제작된다 해도, 그것이 모든 관련 기기 및 시스템에 설치되리란 보장 역시 없다.

탄틀레프는 “굳이 멀리 볼 필요 없이, 오픈소스 환경의 최근의 역사만 살펴봐도 답을 알 수 있다. 줌라(Joomla) 콘텐츠 관리 플랫폼에 존재한 오픈소스 보안 취약성으로 파크앤플라이(Park’n Fly)와 원스톱파킹(OneStopParking.com)가 얼마나 매서운 공격을 받았는지 모두 기억할 것이다”라고 말했다.

그는 “관련 보안 패치는 공격이 일어나기 전 이미 배포된 상황이었지만, 안타깝게도 두 업체는 이를 설치하지 않았다”라고 설명을 덧붙였다.


맥컬리비는 자신이 (가장 성공적인 오픈소스 OS인) 리눅스를 이용하기 시작했다는 점을 언급하며 “이것이 20년 전에 출시됐더라면 패치 미설치와 관련한 문제는 더 심각했을 것이다. 오픈소스가 ‘두 개의 구분된 조직’으로 존재했을 것이기 때문이다”라고 이야기했다.

맬컬리비는 “리눅스의 경우 그 자체로 제1 OS인 ‘커널 팀(kernel team)’과 ‘애플리케이션 유지관리자(application maintainer)’가 별개로 존재한다”라고 설명했다.

그는 “리눅스 커널 자체에 대한 모든 변경은 여전히 리눅스(의 창시자 리누스 토발즈) 본인 혹은 소수의 어플리케이션 유지관리자들의 승인이 있어야 가능하다. 그들, 오직 그들만이 코어 커널 OS에서 이뤄지는 활동을 결정할 수 있다”라고 설명을 이었다.

그러나 그들은 리눅스 애플리케이션 혹은 ‘패키지’(‘디스트로(distro)’ 혹은 ‘디스트리뷰션(distribution)’이라고도 불리는)를 유지하는 수천의 오픈소스 개발자들에 대해서는 어떤 관심도 보이지 않는다. 그곳은 독자적인 생태계라 할 수 있다.

이는 유저랜드(userland) 영역의 완전한 무정부 상태를 야기했다. 이 곳에서는 안정성과 보안에 모두 위험한 수준이다. 책임자가 없기 때문이다.

로스는 “폐쇄형 소스 소프트웨어 역시 오픈소스처럼 ‘버려질’ 여지가 있긴 마찬가지라 할 수도 있지만, 상용, 독점 소프트웨어들에겐 유지 및 업데이트에 따른 경제적 인센티브가 있다. 품질 관리를 신경 쓰는 벤더라면 패치 등의 문제는 크게 걱정할 것이 없을 것이다”라고 설명했다.

맥컬리비와 마찬가지로 로스 역시 상용 애플리케이션에 이용되는 오픈소스 컴포넌트의 가장 큰 문제로 잊혀질 가능성을 지적했다. 예를 들어 오픈SSL 라이브러리를 이용 중 그 속의 각종 주요 결함으로 갑작스런 문제가 발생할 수 있다. 문제 발생 시 패치가 필요한 것은 오픈소스 소프트웨어나 상용 소프트웨어 모두 마찬가지지만, 상용 애플리케이션에서 오픈SSL이 이용되는 경우에는 많은 최종 사용자들이 그것의 존재 자체를 인식하지 못하고, 따라서 패치가 필요하다는 사실 자체를 인지하지 못하게 될 수 있는 것이다.

탄틀레프도 같은 문제를 강조하며 “패치가 있다고 문제가 사라지는 것은 아니다. 환경의 누군가는 아직 그것을 설치하지 않았다. 일반적으로 오픈소스 애플리케이션에 ‘자동 업데이트’는 지원되지 않는다”라고 설명했다.

개발자 혹은 조직의 니즈에 맞춘 커스텀이나 변경이 부메랑이 되어 위협을 안겨줄 수도 있다. 탄틀레프는 “각 수정들이 모여 오픈소스 프로그램을 변경, 혹은 분리 버전으로 만든다. 이 변경된 애플리케이션들 가운데 다수는 다시 배포가 이뤄지고, 그 경우 ‘어떤 버전을 사용할 것인가?’라는 문제가 제기되어 버린다. 그리고 그 문제에 답을 내리기란 매우 곤란하다”라고 설명했다.

즉 사용자 혹은 개발자들은 자신이 애플리케이션 패치를 시행했다 생각했지만, 실제로는 버전의 차이로 패치가 적용되지 못하고, 취약성은 그대로 남아있게 되는 것이다.

변경의 가능성은 누군가의 장난이 가능하다는 의미이기도 하다. 탄틀레프는 “마음만 먹는다면 코드에 맬웨어를 주입하는 것도 가능하고, 더 나쁜 경우에는 아예 설계 단계에서부터 맬웨어를 숨겨둔 오픈소스 애플리케이션이 배포 되어 문제를 야기할 수도 있을 것이다. 슬프게도 이들 모두 가정의 수준을 넘어서, 실제 사례로 발견된 바 있는 것들이다”라고 말했다.

마지막으로, 법률이나 규제 관련 문제가 발생했을 때 커뮤니티 내 수 천의 관계자 중 특정인에게 책임을 묻기 어렵다는 점도 큰 문제다. 맥컬리비는 “아무도 책임지지 않는 도구를 누가 이용할 수 있겠는가?”라고 지적했다.

물론, 오픈소스의 지지자들은 커뮤니티가 독점적 시스템의 기업보다 훨씬 믿을 수 있다고 이야기한다. 일례로 CMS 크리틱에 개재한 기고문에서 다니엘 스렐폴은 “독점 시스템을 관리하는 그 한 곳의 기업에 사고가 생기면 무엇이 남는가? 반대로 오픈소스 CMS는 보다 역동적이라 할 수 있다. 어떤 집단도 이를 소유하지 않으며, 대신 지원 네트워크가 그것을 유지해나간다. 커뮤니티는 안정적인 존재 기반이다”라고 강조했다.

그렇다면, 사용자들은 오픈소스를 활용함에 있어 어떻게 최악의 상황을 피할 수 있을까?

답은 어렵지 않다. 탄틀레프는 “간단하다. 오픈소스를 다른 소프트웨어들과 동등하게 다룬다면, 기업들은 그 가치를 최대한 이용할 수 있다”라고 말했다.

그는 “시작은 소스에 대한 이해에서부터다. 소프트웨어가 어디에서, 즉 믿을만한 소스에서 오는지를 검증하는 것이 중요하다. 믿을만한 소스들을 파악하는 것만으로도 소프트웨어 조달은 한결 용이해질 것이다”라고 설명했다.

하지만 소스에 대한 검증 이후에도 소프트웨어 자체에 대한 적절한 통제 프로세스와 프로그램을 적용하기 이전에는 배치에 주의해야 한다고 탄틀레프는 덧붙였다.

그는 “마지막으로, 환경 내부의 소프트웨어들을 관리하고 모니터링 할 프로그램 역시 필요하다. 취약성 발생은 없는지, 새로 배포된 패치는 없는지, 그리고 무엇보다, 필요한 모든 패치들이 제대로 설치되어 있는지를 언제나 확인해야 한다”라고 강조했다. ciokr@idg.co.kr