오픈소스는 '여전히' 보안에 취약한가?

이 질문의 답은 여러 개다. OpenSSL과 Bash의 사례와 오픈소스 프로젝트 개수를 고려한다면 대답은 ‘예스’에 가깝다. SW기업들의 대응책에 후한 점수를 준다면야 ‘보완되는 중’이라고 답할 수도 있을 것이다.

오픈소스의 장점은 소스코드가 공개돼 있어 누구나 접근해 새로운 프로젝트에 활용할 수 있다는 점이다. 현재 오픈소스 프로젝트는 100만개 이상으로 추정된다.

개발 주체는 기업뿐만 아니라 다수의 개인들도 존재한다. 오픈소스는 상용 소프트웨어에도 쓰인다. 실제로 마이크로소프트와 오라클 등 글로벌 기업들도 오픈소스를 적극적으로 도입·활용하고 있다.

GPL, LPGL, Apache2.0, BSD 등은 최근의 ‘핫’한 오픈소스다. 이를 바라보는 시선은 ‘젊다’. 이들은 새로운 아이디어의 실험·성장·혁신의 근원으로 인식된다. 실제로 그렇다. 자연히 다수의 소프트웨어 기업과 개인, 커뮤니티 차원의 검증이 이뤄진다.

문제는 운영체제에 핵심적인 영향을 끼치나 상대적으로 인기를 끌지 못한 더 많은 프로젝트들이다. 보안 취약점은 상당부분 여기서 발생된다.

처음 오픈소스가 등장할 무렵만 해도 소스코드를 공개하지 않는 상용 소프트웨어들보다 많은 소스코드 오디터(auditor)들에 의해 분석돼 더 안전할 것으로 전망됐었다. 시간이 지나면서 보안에 심각한 구멍들이 계속 발견되자 글로벌 기업 중심으로 대응책이 마련되기 시작했다.

이러한 상황을 빗대 IT매체 와이어드는 ‘집단 지성의 거짓말(The Lie of Many Eyes)’이라고 표현했다.

“리누스의 법칙은 유효하다, 단 감시자가 있다면!”

지난 2014년 9월12일 아카마이의 IT매니저였던 스테판 챠젤라스는 쳇 레이미에게 이메일을 썼다. Bach에서 버그를 발견했다는 내용이었다. 곧장 이 소식은 전 세계로 퍼졌다. 일명 ‘쉘쇼그 버그’다.

해커들은 컴퓨터를 원격으로 장악할 수 있는 코드로 봇넷을 만들어 인터넷을 감염시켰다.

물론 오픈소스가 아니라도 이와 유사한 사태는 어떤 소프트웨어에서라도 발생 가능하다. 오라클 데이터베이스나 MS의 소프트웨어 등의 상용 소프트웨어에는 어떤 버그가 존재하는지 알 수조차 없다.

MS가 화이트해커를 통해 자사의 소프트웨어를 검증케 한 것은 2003년 블래스터 웜의 악몽에서 얻은 교훈인 셈이다. 홍보 차원에서 이는 매우 효과적인 이벤트이기도 하다.

처음으로 돌아가 보자. 오픈소스는 보안에 취약하냐는 질문에 대해 한국레드햇의 이규석 부장은 “오픈소스 자체만으로는 보안에 취약하다고 단정 지을 수는 없다”는 알쏭달쏭한 대답을 전했다. 기술 발달에 따라 최근 오픈소스 SW의 보안 허점이 줄어드는 추세이기도 하거니와 기술 보고서를 통해 보안 취약점 등을 사용자가 사전에 확인할 수 있다는 것이다.

그는 “상용 소프트웨어에 심각한 버그가 있다면 일반 사용자는 이를 전혀 알지 못한 채 해커 공격에 무방비로 노출될 수밖에 없다”고 말했다. 일순 맞는 말이다. 실제로 상용 소프트웨어 관련 보안 사고 사례를 보면 이용자는 해킹을 당하고 나서야 해당 SW의 취약점을 인지하거나 심지어는 공격을 받았는지도 알아차리지 못하는 경우가 적지 않다.

레드햇 측은 지속적인 보안 취약점을 지적받아온 오픈소스에 대해 커뮤니티와의 검증을 진행 중이라고 밝혔다. 일례로 레드햇의 보안 처리 과정을 보면 기업 차원의 대응 애티튜드가 꽤나 진지하다는 것을 알 수 있다.

레드햇 측은 CVE를 공개하고 자사에서 운영 중인 보안 블로그를 통해 관련 내용을 공개하고 있다. 관련해 이규석 부장의 말을 들어보자.

“외부에서 보안 취약점이 발견되면 CVE ID가 부여되고 커뮤니티와 테스트를 거쳐 수정된 버전이 나오게 됩니다. 고객의 장애 발생 신고를 접수하면 이를 리포팅을 거쳐 해당 사안이 보안 취약점인지 여부를 판단하게 됩니다. 맞다고 판단되면 커뮤니티와의 공조로 패치 개발 후 커뮤니티에 이를 알립니다.”

주지하다시피 레드햇을 포함한 대다수의 벤더들, 구글·삼성·페이스북·시스코·인텔·HP·MS 등이 오픈소스를 사용하는 만큼 이들 중 여럿은 보안 대응 프로세스에도 참여하고 있다. 이 과정에서 웃지 못 할 오해도 산다.

예컨대 레드햇이 패치를 공개하면 레드햇 자체의 결함으로 치부되는 경우가 있다는 것이다.

이쯤해서 의구심이 고개를 든다. 각 기업이 메울 수 있는 오픈소스의 구멍은 자사와 관련된 것일 경우가 대다수일 터. 앞서 거론한 것처럼 현재 알려진 오픈소스는 100만개를 상회하고 있지 않은가. 가짓수는 많은데 여과지는 현저히 부족한 것 아닐까.

이 부분에 대해 레드햇 측은 한계를 일부분 인정하기도 했다. 다만 2014년의 상황보다 진일보 한 것은 사실아니냐는 논리를 폈다.

“2014년 이후 상황이 변했다. 핵심 기업들의 운영체제에 영향을 미치는 필수적인 오픈소스이지만 인기가 높지 않은 경우를 집중적으로 관리·검토하고 있어 이전과 비교해 안전성이 점차 확보되고 있다.”

모두에게 열려있는 소스코드는 다수의 이성에 의해 추가·보완·수정이 이뤄진다는 소위 리누스의 법칙은 이론적으로 적재적소에 작동돼야 한다. 리눅스의 아버지라 불리는 리누스 토발즈는 와이어드와의 인터뷰를 통해 리누스의 법칙의 전제가 잘못됐을지 모른다는 점을 지적한 바 있다.

“많은 눈이 Bach를 25년 동안 쳐다봤다면 쉘쇼크 버그는 오래전에 발견됐을 것이다(If many eyes had been looking at bash over the past 25 years, these bugs would’ve been found a long time ago).”

레드햇을 필두로 여러 핵심 기업들의 오픈소스 SW 보안 대응책은 그간 부재했던 ‘많은 눈’을 얼마나 보완할 수 있을까. 귀추가 주목된다.

<참고자료>

한국인터넷진흥원(2014), ‘GNU Bash 원격코드실행 취약점 이슈 분석 및 대응방안’

wired(2014. 9.29) ‘The Internet Is Broken, and Shellshock Is Just the Start of Our Woes’

한국레드햇(2016. 11.9), ‘오픈소스와 보안’ 등