“수퍼버그” 가장 장수한 소프트웨어 버그 10가지

http://www.itworld.co.kr/slideshow/90591

“수퍼버그” 가장 장수한 소프트웨어 버그 10가지

Phil Johnson | ITworld.com

모든 소프트웨어에는 버그가 있다. 유명한 애플리케이션에도 오랜 시간 아무도 알아채지 못한 오류와 취약점이 존재할 수 있다.
이번 주 초, 마이크로소프트는 19년 전 1995년 윈도우가 출시된 이후부터 모든 버전의 윈도우 운영체제에 존재했던 것으로 드러난 보안 취약점을 패치했다. 이 버그를 발견한 IBM 연구원들의 말을 빌자면 오랜 세월에 걸쳐 동일한 라이브러리에 있던 다른 취약점들이 수정되는 동안에도 이 버그는 “빤히 보이는 곳에” 그냥 방치되어 있었다.
엄청나게 많은 사람들이 사용하는 유명 소프트웨어에 이런 치명적인 오류가 20년 가까이 누구의 눈에도 띄지 않았다는 사실이 놀랍게 느껴질지도 모르겠지만 사실 이런 경우는 생각만큼 드물지 않다. 광범위하게 사용되는 핵심적인 코드라 해도 오랜 시간 동안 다양한 이유로 발견되지 않거나 때로는 무시되는 버그가 있다. 버그 중에서 특히 오랜 기간 생존한 10가지 사례를 살펴보자. 이 중에는 아직 수정되지 않은 버그도 있다.  editor@itworld.co.kr

오픈BSD의 head 버그
지속 기간: 37년 2개월
발생 날짜: 1977년 8월
수정 날짜: 2014년 10월
오픈BSD는 18년 전에 등장했지만 그보다 앞서 만들어진 버그를 안고 있었다. 1977년 8월 미래의 썬 마이크로시스템즈 공동 창업자인 빌 조이는 유닉스에서 파생된 버클리 소프트웨어 디스트리뷰션(Berkeley Software Distribution: BSD)의 첫 릴리스인 1BSD 파일의 첫 번째 행을 표시하기 위해 head 함수를 만들었다. 이 코드는 이후 386BSD, 넷BSD, 오픈BSD 등에 계속 사용됐다.
조이가 head를 작성하고 15년이 지난 1992년, 이 코드가 오류를 일으킬 수 있다는 사실이 발견됐다. freopen이라는 함수를 사용하여 파일 및 스트림을 열 경우 stdin과 불협화음이 발생하는 버그다. 케이스 보스틱이 4.4BSD에서 문제를 수정했지만 1989년 4.3BSD에서 파생된 386BSD, 1993년 이 386BSD를 기반으로 파생된 넷BSD와 같은 일부 BSD 파생 버전에서는 이 버그가 그대로 방치됐다. 2014년 10월 잉고 슈와르츠가 22년 전에 나온 보스틱의 수정 코드를 오픈BSD에 병합함으로써 18년째 이어진 문제를 마침내 해결했다. 조이가 최초의 코드를 작성하고 37년만이다. Image courtesy flickr/Todd Huffman 

YACC의 버퍼 오버플로우 문제
지속 기간: 33년 2개월
발생 날짜: 1975년 5월
수정 날짜: 2008년 7월
스티븐 존슨은 1975년 AT&T 벨 연구소에서 근무하면서 언어 컴파일러용 파서를 생성하기 위한 도구인 옛 어나더 컴파일러-컴파일러(Yet Another Compiler-Compiler: YACC)를 개발했다. 처음에는 B 프로그래밍 언어, 이후 C 언어로 만들어진 YACC는 오랜 시간 동안 유닉스 시스템에서 기본 파서 생성기로 사용됐다. 1975년 5월 벨 연구소가 출시한 유닉스 6번째 에디션에 처음 포함된 이후 BSD를 포함한 많은 유닉스 파생 버전으로 이어져 내려갔다.
2008년, 오픈BSD 개발자인 오토 모어비크는 썬 스팍64 시스템에서 일부 대규모 C++ 프로그램을 컴파일할 경우 내부 컴파일러 오류가 발생하며 작업이 실패하는 이유를 추적하는 중이었다. 알고 보니 문제의 원인은 모어비크 자신이 작성한 새로운 메모리 할당 루틴이 아니라 존슨의 YACC 코드에 있었다. 모어비크의 새로운 malloc 코드를 통해 존슨의 YACC가 스팍64 시스템에서만 특정 조건에서 버퍼 오버플로우를 유발한다는 사실이 드러났다. 모어비크는 존슨의 YACC 코드가 처음 등장하고 약 33년 후에 오픈BSD에서 이 문제를 해결했다. Image courtesy flickr/Gabe Rosiak 

엑셀의 1900년 문제
지속 기간: 27년(현재진행형)
발생 날짜: 1987년 11월
수정 날짜: 미수정
마이크로소프트가 1980년대 중반 최초의 윈도우용 엑셀을 만들면서 정한 목표는 당시 독보적인 PC 스프레드시트였던 IBM 로터스 1-2-3이었다. 마이크로소프트는 로터스 사용자들의 마음을 끌기 위해 로터스에서 엑셀로 최대한 쉽게 스프레드시트를 이식할 수 있도록 했는데, 그로 인해 1900년을 윤년으로 취급하는 로터스의 잘 알려진 버그까지 그대로 가져오게 됐다.
로터스 1-2-3 엔지니어들은 날짜 계산을 쉽게 하기 위해 1900년이 윤년이 아니라는 사실을 의도적으로 무시했다. 존재하지 않는 윤일을 보상하기 위한 방편은 존재하지 않는 1900년 1월 0일을 설정하는 것이었고, 이는 즉 1900년 1월 1일부터 2월 28일까지의 모든 날짜가 잘못 반영됨을 의미했다. 엔지니어들은 이를 사소한 문제로 간주했다. 마이크로소프트는 1987년 11월 최초의 윈도우용 엑셀을 출시하면서 이 문제까지 그대로 가져왔다(1904년 1월 1일을 해결책으로 사용한 맥용 엑셀에는 이 문제가 존재하지 않음). 이 버그는 수정할 경우 발생할 수 있는 수없이 많은 문제로 인해 27년이 지난 지금까지 그대로 방치되고 있다. Image courtesy flickr/OliBac 

배시(Bash)의 셸쇼크(Shellshock) 취약점
지속 기간: 25년 1개월
발생 날짜: 1989년 8월
수정 날짜: 2014년 9월
1989년, 브라이언 폭스는 GNU 프로젝트의 일부로 배시 셸을 만들었다. 기존 본(Bourne) 셸을 대체하기 위한 것이었다(그래서 이름도 “Bourne-again shell”의 약어임). 배시는 인기를 끌었고 이후 BSD에서 리눅스, 맥 OS X에 이르기까지 모든 유닉스 기반 시스템의 필수적인 요소로, 그리고 많은 경우 기본 셸로 자리 잡았다. 그러나 폭스를 포함한 누구도 몰랐던 매우 심각한 보안 취약점이 수십 년 동안 남아 있었다.
리눅스 개발자 스테판 차젤라스는 2014년 셸쇼크로 알려진 일련의 취약점의 첫 번째 사례를 발견했다. 이는 배시가 환경 변수의 함수 선언 이후에 포함된 코드를 실행한다는 사실에 기반하는 문제다. 아파치는 백그라운드에서 배시를 실행하므로 웹 서버들이 가장 큰 위험에 노출된 것으로 간주됐다. HTTP 또는 CGI 스크립트를 통한 악의적 코드 전송이 가능했고, 이로 인해 해커의 원격 서버 제어, 봇넷 생성을 포함한 여러 가지 문제가 발생할 가능성이 있었다. 확인 결과 이 셸쇼크 취약점은 1989년 8월 배시 버전 1.03에서 처음 발생한 것으로 드러났다. 2014년 9월 첫 패치가 나올 때까지 25년 동안 악용 가능한 상태로 방치된 것이다. Image courtesy flickr/Elliott Brown 

BSD의 seekdir 문제
지속 기간: 24년 9개월
발생 날짜: 1983년 8월
수정 날짜: 2008년 5월
유닉스 변형 중 하나인 버클리 소프트웨어 디스트리뷰션(BSD)의 초창기에는 프로그램이 디렉터리 안의 파일을 직접 열고 읽어야 했다. 그러나 1983년 8월 4.2BSD부터는 커크 맥큐직이 만든 dir 라이브러리가 구현됐다. 맥큐직은 BSD를 만든 사람 중 하나인 빌 조이가 썬 마이크로시스템즈 창업에 참여하기 위해 떠난 후 BSD 개발을 이어받는 데 참여한 사람 중 한 명이다. 디렉터리 파일을 탐색하기 위한 맥큐직의 이 코드는 그가 인지하지 못한 버그와 함께 이후 BSD 버전 및 넷BSD, 오픈BSD, 그리고 맥 OS X를 포함한 많은 변형에서 오랫동안 운영체제의 일부분으로 사용됐다.
문제의 버그가 드러난 시점은 2008년이다. 오픈BSD 개발자인 마크 발머는 MS-DOS 시스템에서 파일을 서비스할 때 삼바가 멈추는 이유를 찾고 있었다. 삼바 코드에는 BSD에 디렉터리 처리와 관련한 문제가 있다는 주석이 달려 있었다. 발머는 마침내 맥큐직의 seekdir 루틴(디렉터리 스트림의 다음 항목을 찾는 데 사용됨)에서 파일이 삭제된 디렉터리를 탐색할 때 버그가 발생한다는 사실을 발견했다. 수정하는 작업은 버그를 찾기 위한 노력에 비하면 훨씬 더 간단했다고 한다. Image courtesy flickr/Phil Whitehouse 

마이크로소프트의 자동화 드라이브-바이 취약점
지속 기간: 19년 3개월
발생 날짜: 1995년 8월
수정 날짜: 2014년 11월
마이크로소프트는 1995년 윈도우 95를 출시하면서 OLE(Object Linking & Embeding) 프레임워크와 COM(Component Object Model)을 통해 애플리케이션이 더 쉽게 서로 통신하고 이질적인 데이터를 상호 공유할 수 있도록 했다. 윈도우 95에 포함된 COM의 서비스 중 하나로 OLE 자동화(지금은 그냥 자동화라고 함)가 있었는데, 이 서비스의 용도는 스크립팅 언어에서 통신을 상호 처리하는 것이었다. 자동화는 윈도우 95 이후 모든 윈도우(서버 포함) 운영체제의 필수 요소로 포함됐다.
지난 5월 IBM의 엑스포스(X-Force) 연구 팀이 OleAut32 라이브러리에서 드물긴 하지만 치명적이고 복잡한 보안 결함을 발견했다. 엑스포스 팀이 발견한 바에 따르면 VB스크립트를 도입한 인터넷 익스플로러 3.0부터 해커가 원격으로 컴퓨터를 제어하기 위한 드라이브-바이 공격을 감행할 수 있는 여지가 생겼다. IBM은 바로 마이크로소프트에 알렸지만 마이크로소프트는 문제에 대해 함구하고 있다가 이번 주 불쑥 패치를 내놨다. 문제의 코드가 처음 등장하고 19년이 넘게 지나서야 패치가 나온 것이다. Image courtesy flickr/Justin Henry 

LZO의 정수 오버플로우 조건
지속 기간: 18년 3개월
발생 날짜: 1996년 3월
수정 날짜: 2014년 6월
마커스 오뷰머는 1996년 3월 빠른 속도에 최적화된 렘펠-지브-오뷰머(LZO)라는 무손실 데이터 압축 알고리즘을 공개했다. 이후 LZO는 FFmpeg, 리눅스 커널 및 하둡을 포함한 다양한 오픈소스와 독점 소프트웨어에 사용됐다. 심지어 지구에서 멀리 떨어져 화성 탐사 로봇 큐리오시티에도 사용된다.
처음 LZO가 등장하고 거의 20년 만인 2014년, 랩 마우스 시큐리티(Lab Mouse Security)의 돈 베일리가 LZO의 알고리즘이 정수 오버플로우에 취약하다는 사실을 발견했다. 오버플로우는 상당히 드문 조건에서 발생한다(구체적으로, 32비트 시스템에서 16MB를 초과하는 압축된 바이트의 압축을 해제하려고 시도할 때). 이론적으로 시스템은 원격 코드 실행, 서비스 거부 공격, 인접 개체 덮어쓰기에 노출될 수 있다. 2014년 6월 버그를 수정한 LZO 버전 2.07이 나왔다. NASA가 큐리오시티의 코드를 패치했는지 여부는 알 수 없지만, 패치하지 않았다 해도 공격자가 큐리오시티에 악성 코드를 보내기는 아마도 무척 어려울 것이다. Image courtesy NASA/JPL-Caltech/MSSS 

윈도우 NT 가상 DOS 머신 문제
지속 기간: 16년 8개월
발생 날짜: 1993년 7월
수정 날짜: 2010년 3월
마이크로소프트는 1993년 7월 마이크로소프트 최초의 32비트 시스템인 윈도우 NT를 출시했지만 DOS는 물론이고 그때까지 축적된 다양한 16비트 소프트웨어들이 쓸모가 없어지는 상황은 원하지 않았다. 그래서 내놓은 해결책이 32비트 NT 컴퓨터에서 16비트 소프트웨어를 실행할 수 있게 해주는 윈도우 NT 가상 도스 머신(VDM)이다. 윈도우 NT(그 이후에 나온 모든 32비트 버전의 윈도우 NT, 2000, XP, 서버 2003, 비스타, 서버 2009, 윈도우 7까지) 사용자는 NT VDM을 사용하여 DOS 및 16비트 프로그램을 원활하게 이용할 수 있었다.
그로부터 약 16년 후, 구글 연구원 타비스 오맨디가 NT VDM 코드에서 심각한 버그를 발견했다. 오맨디가 시연한 바에 따르면 이 취약점을 통해 해커가 컴퓨터에 직접 로그인해서(원격 악용은 되지 않음) 자신의 권한을 시스템 수준으로 높일 수 있었다. 오맨디는 이 버그를 2009년 6월 마이크로소프트에 보고했는데, 마이크로소프트는 어떤 이유에선지 2010년 3월이 되어서야 문제를 수정한 보안 업데이트를 내놨다. Image courtesy flickr/Sam Howzit 

오픈SSL의 ChangeCipherSpec 주입 취약점
지속 기간: 15년 6개월
발생 날짜: 1998년 12월
수정 날짜: 2014년 6월
오픈SSL은 1998년에 SSL과 TSL 프로토콜의 오픈소스 구현으로 만들어졌다. 이후 큰 인기를 끌었으며, 현재 전세계 모든 활성 웹 사이트의 66%를 구동하는 아파치와 nginx 웹 서버의 기본 암호화 엔진으로 사용된다. 오픈SSL이 워낙 중요해진 만큼 미국 국토 안보부도 이를 지원하고 있다.
2014년, 오픈SSL이 하트블리드(Heartbleed) 버그에 취약하다는 사실이 밝혀졌다. 심각한 이 취약점 외에 오픈SSL 코드의 다른 문제점들도 함께 발견됐는데, 그 중에서는 일본 연구원 마사치 키쿠치가 6월 발견한 문제도 포함됐다. 키쿠치는 오픈SSL의 ChangeCipherSpec 처리 과정에서 해커가 클라이언트와 서버의 핸드셰이크 중 유효하지 않은 신호를 보냄으로써 맨인더미들 공격을 가할 수 있게 되는 문제점을 발견했다. 이 취약점은 하트블리드만큼 심각하진 않았지만 최초 출시 버전부터 이후의 모든 오픈SSL 클라이언트 버전 내에 15년 동안이나 존재했다. Image courtesy flickr/thefuturistics 

IE6 플래시 악용 결함
지속 기간: 12년 9개월
발생 날짜: 2001년 8월
수정 날짜: 2014년 5월
2001년 8월 출시된 인터넷 익스플로러 버전 6(마지막 독립형 버전)은 이내 브라우저 시장의 90% 이상을 차지하는 독보적인 웹 브라우저로 부상했다. 당시 거의 모든 사람들이 사용하는 브라우저였으므로 당연히 해커들의 주 공격 목표이기도 했다. 예를 들어 사용자와 동일한 보안 수준에서 실행된다는 사실 등 설계상의 문제점으로 인해 악용 공격에 특히 취약했으며 “사상 최악의 소프트웨어” 목록에 단골로 이름을 올리기도 했다.
IE6이 출시되고 13년이 지난 현재 IE6의 브라우저 시장 점유율은 1.68%에 불과하지만 심각한 보안 취약점은 지금까지도 계속 발견되고 있다. 2014년 4월 보안 업체 파이어아이(FireEye)는 IE6과 그 이후의 모든 버전에서 플래시 악용 결함을 발견했다. 해커는 원격 코드 실행이 가능한 이 결함을 통해 공격 대상 컴퓨터에서 사용자와 동일한 수준의 권한을 얻을 수 있었다. IE6, 7, 8의 시장 점유율은 미미하지만 마이크로소프트는 이례적으로 5월, 몇 주 전에 지원 기간이 끝난 윈도우 XP의 IE6까지 포함하여 이 악용 결함을 수정하는 보안 패치를 내놨다. 13년된 IE6 버그는 수정되었지만 아직 다른 취약점들은 패치되지 않은 채 남아 있다. Image courtesy flickr/Joe Goldberg