art.oriented : 애니 커서 보안 취약성, 윈도우 비스타 다운 동영상?

minjang.egloos.com

소개 · 이전글 · 구독

컴퓨터 · 그리고 · 나머지

재밌는 동영상 하나를 보았습니다. Zero-day attack에 관한 것인데요. 많은 분들이 잘 못 이해하시는 것 같아서 한 말씀 드리고자 글을 간단히 씁니다. 먼저, zero-day attack은 비교적 최근에 등장한 용어로 보안 취약점과 그것을 악용한 코드가 동시에 출현하는 경우를 가리킵니다.

이 문제는 애니 커서 파일인 .ani를 다루는 모듈에 보안 취약성이 있는 문제를 악용하는 것입니다. 그래서 결국엔 remote malicious code (외부에 있는 악성 코드)를 실행시키는 것이 목적입니다. 한마디로 .ani 파일을 읽는 것 만으로 임의의 .exe를 실행시킬 수 있다는 소리입니다. 이 .exe가 바이러스 프로그램이라면 바로 재앙이 일어나는 것이죠.

이러한 문제는 (이 ani 문제 자체는 자세히 보지 않았습니다) 아주 간단한 소스 몇 줄 때문에 일어나는 경우가 대부분입니다. 제 블로그의 두 번째 글인… malloc에 관한 글을 잠시 참고 하시면, C/C++ 프로그램은 거의 모두 malloc/free를 호출 합니다. (C++의 new도 결국 malloc/free로 연결이 됩니다) 그런데 이러한 힙 메모리 관리는 많은 보안 취약성을 가지고 있고 지금 수 많은 윈도우 업데이트 및 각종 보안 배치가 바로 이러한 문제 때문에 발생하고 있습니다. 이건 윈도우만의 문제가 당연히 아닙니다.

조금 더 자세히 설명을 하면, malloc/free가 하는 역할은 다들 아실 것입니다. 그렇다면 이렇게 할당하고 해제한 메모리 상태를 기록을 하여야 합니다. 한마디로 대출 장부와 같은 것 말이죠. 이것을 meta-data로 표현을 하고, 여기에는 "어떤 크기의 데이터를 할당하였는가?"와 "이 데이터 블록이 사용 중인가?" 이 두 가지를 기록합니다. 그런데 malloc/free는 프로그램의 성능에 결정적인 영향을 미칠 수 있으므로 무결성 검사를 거의 (솔직히 하나도) 하지 않는 편입니다. 왜냐면 malloc/free가 사용 된 지는 20년이 훨씬 넘었고 옛날에는 이러한 악성 코드가 존재하지도 않은 시절이었죠. 그래서 보안은 거의 고려를 하지 않고 속도만을 고려해서 만들어졌습니다.

그러나, 세상이 바뀌었고 사악한 사람들이 넘쳐나고 있습니다. Buffer overflow attack이라는 말은 컴퓨터 좀 관심 있으신 분은 들어보셨을 것입니다. malloc으로 할당 받은 데이터 보다 더 많은 데이터를 "의도적"으로 써서 나쁜 짓을 하는 것입니다.

좀 더 자세히 이야기를 해보면, 위에서 설명한 meta-data는 각 데이터 사이에 존재하게 됩니다. 그래서 할당 받은 데이터를 지나쳐 데이터를 강제로 쓰면 이 meta-data가 조작이 됩니다. 그러면 최악의 경우 임의의 exe를 실행시킬 수 있습니다. 물론 이 과정을 하기 위해서는 많은 조건이 필요하고 쉽지가 않습니다. 그러나 우리의 위대한 크래커들은 이러한 틈을 비집고 들어가 결국 악성코드를 실행하기에 이릅니다.

자, 저 동영상을 자세히 설명해보죠. 저건 보안 취약성 문제를 제대로 재현하지 못하고 있는 것입니다. 저건 "다행히" 바탕화면 (explorer.exe) 프로그램이 계속 재실행 되고 죽는 것을 반복하는 것입니다. 차근차근 설명하면:

조작된 .ani 파일을 바탕화면에 옮겨 놓습니다.
바탕화면에 올라온 .ani 파일은 자동적으로 읽어지게 됩니다. (미리 보기를 하기 위해)
그러나 .ani 파일을 읽는 코드에 보안 취약성이 존재하고 그만 오류를 내게 됩니다.
바탕화면, explorer.exe 프로그램이 죽습니다.
윈도우 오래 사용해보신 분들은 알겠지만 바탕화면이 죽으면 자동으로 재실행이 됩니다.
다시 재실행된 바탕화면은 또 문제의 ani 파일을 열려고 합니다.
GOTO 2

그러니까 "다행히" 보안 취약성이 제대로 나타나지 않는 경우를 보여주고 있습니다. 제대로 악성 코드가 나쁜 짓을 했다면 정말 임의의 악성 코드가 실행이 되어야 합니다. 바탕 화면이 끊임 없이 재실행 되는 것은 문제의 핵심이 아닙니다. -_-

그러면 이 문제를 해결하려면? 간단하지요. 다른 계정으로 들어가서 바탕 화면의 .ani 파일만 지우면 됩니다. 좀 지나치게 문제를 과장하였네요. 그것도 엉뚱한 방향으로요. 저 악성 코드를 만든 사람이 보면 웃을 것 같아요. 그래도 어쨌든 사용자를 짜증나게 만들었으니 소기의 목적은 달성.

이 문제를 다시 위에서 설명한 malloc/free와 연관 지어 설명하면, 일반적으로 파일을 열면 그것을 메모리 버퍼에 할당을 하고 처리를 할 것입니다. 물론 이 버퍼는 동적으로 할당해야 하기 때문에 malloc으로 얻은 것이겠죠. 그런데 엄한 파일을 읽는데 그것을 대비하지 못한 코드가 그 파일을 그대로 복사하면 위의 meta-data가 그만 corrupt 되고 맙니다. 이걸 노려서 악성 코드를 실행하게끔 하는 겁니다.

실제로 이와 비슷한 문제가 여러 개 있습니다. JPEG/WMF 파일을 여는 곳에도 비슷한 보안 취약성 문제가 있었습니다. 그래서 악성 WMF 파일을 탐색기에 올려 놓으면 WMF 파일에 숨겨진 악성 코드를 실행시킵니다. 그러나 실제로 실험을 해보면 그냥 탐색기가 죽고 말죠. 사실 악성 코드가 실행되어야 하는데 이거 직접 구경하기가 좀 힘듭니다. (제가 이와 관련된 프로그램을 한 학기 동안 만들어서 자신 있게 말할 수 있습니다.)

여기서 "역시 윈도우는 보안에 취약해"라는 반응을 보이시면 상당히 난감합니다. 저러한 보안 취약성은 리눅스, 맥을 떠나 C/C++로 만들어진 모든 프로그램이 안고 있는 원초적인 문제입니다. 윈도우는 그 만큼 많은 사람들이 쓰고 있기 때문에 위험성이 있는 것이지 윈도우가 더 '바보'여서 저런 것은 아닙니다. 리눅스에도 심각한 보안 취약성이 있습니다. sudo같은 것에도 보안 취약성이 있어서 그걸 공격하여 root를 탈취할 수도 있었습니다. 맥은 괜찮을까요? 역시 똑같은 문제가 있습니다. 다만 사용자가 적어서 큰 영향이 가시적으로 보이지 않을 뿐입니다.

저런 문제가 나오면 저는 오히려 반갑습니다. 친절히 '버그'를 찾아주었으니깐요. Code Red 웜과 같이 RPC와 같은 네트웍을 타고 퍼지는 웜은 정말 무섭습니다. 그러나 이런 데스트탑에서 벌어지는 보안 취약성은 심각한 수준이라고 해도, 실제 사용자가 겪으려면 첨부파일 클릭이라던가 아니면 "바탕화면에 ani 파일을 끌어다 놓는" 특이한 단계를 더 거치는 경우가 보통입니다. 그런데 이번 보안 취약은 단순히 이메일만 보기만 해도 ani 파일이 해당 페이지에 있다면 이러한 문제가 벌어질 수 있으니까 좀 더 주의를 기울여야 합니다.

간단히 쓴다는 것이 너무 길어졌습니다.

이 글과 관련있는 글을 자동검색한 결과입니다 [?]

# by object | 2007/03/31 16:27 | 컴퓨터 | 트랙백(1) | 핑백(1) | 덧글(5)

트랙백 주소 : http://minjang.egloos.com/tb/1060912
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]

Tracked from 여우@보금자리 at 2007/03/31 17:28

제목 : 윈도우즈 애니 커서 제로데이 공격 보안 취약점
마이크로소프트(Microsoft)는 윈도우즈 제품에서 움직이는(애니메이션) 커서 원격 코드 실행 취약점이 발견되어 긴급 보안 자문 자료를 3월 29일자로 공개한 상태이다. 이번 취약점은 보안 패치가 준비되지 않은 상태에서 실제로 관련 악성 코드(트로이 목마)가 발견되어 나타난 제로데이 공격(Zero-Day Attack)으로, 시큐니어(Secunia)에서는 관련 취약점에 대한 보안 등급에 대해 가장 높은 수준인 매우 심각한 보안 취약점으로 등급을......more

Linked at art.oriented : R.. at 2007/10/06 12:58

... k based와 heap based로 나뉠 수 있다. 간단한 스택 오버플로우의 경우는 아래와 같다 (여기서 temp를 스택이 아닌 malloc으로 힙 영역에 할당하면 heap overflow가 발생하며 Code Red와 같은 재앙이 발생할 수도 있다): char temp[8]; strcpy(temp, "very_long_mailicous_string ... more

Commented by 불타는여우 at 2007/03/31 17:27

좋은 글 감사합니다. :)

Commented by 최준열 at 2007/03/31 17:55

그러면요... .NET Framework 하에서 managed code만 실행되도록 OS에 제약을 가하거나 Java Virtual Machine 하에서 역시 JAVA 코드만 실행되도록 제약을 가하면 저 문제를 어느 정도 막을 수 있나요?

근본적인 해결책이 과연 C/C++로 개발을 못하게 하는 것인가...라는 문제에 관심 있습니다.

Commented by object at 2007/04/01 01:17

Managed code에서 작동이 되면 당연히 대다수의 오버플로우나 많은 수의 메모리 릭을 막을 수 있죠. 물론 managed 환경에서도 다른 형태의 메모리릭은 존재합니다. 그렇다고 C/C++을 막는다? 에고~ 가슴이 철컹. 더 이상 노코멘트 :)

Commented by 학주니 at 2007/04/01 07:54

malloc/free를 이용한 buffer overflow야 이미 여러번 언급이 되어있으니까요.
저 역시 프로그래밍을 하면서 저 부분에 대한 검증을 안하고 넘어가는 경우가 많네요.
주로 서버단에서 프로그래밍을 하다보면 클라이언트에서 알아서 잘 맞춰보내겠지 하는 생각을 하니까요. ^^;

Commented by object at 2007/04/01 07:58

strcpy 함수가 애초부터 strncpy 형태로만 있었어도 지금의 수 많은 보안취약성이 사라졌을 것입니다. 이제는 어떠한 데이터도 의심을 해야하는 시대. Taint라는 메커니즘이 있습니다. 외부 네트웍 혹은 디스크 (논란은 있다고 함)에서 읽어들인 데이터는 tainting을 시키고 항상 의심을 하여 컴퓨터 보안을 구현하는 방법이 있습니다. 가만히 놓고 보면 0.0001%의 테러리스트를 잡겠다고 공항의 모든 사람들의 신발을 벗기게하는 꼴과 같죠. 보안이라는 것이 참 무식해보여요.