Lunatine
· 1 min read

glibc 취약점 GHOST (CVE-2015-0235)

  • 경고(?)
    • 이 글은 GHOST에 대한 분석의 글이 아닙니다.
    • 보안에 기웃거렸을 뿐 보안이 뭔지 모르는 저의 개인적인 소감입니다.

GHOST?

heartbleed, shellshock, POODLE ... 작년에 이름을 떨쳤던 보안 취약점이다. 그리고 이번엔 GHOST란다. 며칠 전에 접했던 취약점인며 국내 뉴스기사도 있다. GHOST는 glibc의 취약점인데 glibc가 갖는 범용성 때문에 꽤나 심각하게 보이는 취약점이다.

glibc를 잘 모르는 분들을 위해 추가 설명을 하자면 glibc는 GNU C라이브러리 (GNU libc)를 의미하며 C라이브러리라는 것은 C언어의 기본 중의 기본이 되는 라이브러리를 의미한다. 다시말해 C언어로 작성 된 프로그램 중에 glibc에 의존하지 않는 프로그램이 없다는 뜻이기도 하다. (Linux는 C언어 기반의 운영체제이다)

취약점 설명

아래의 링크는 취약점에 대한 소개와 이에 대한 문서 들이다.

상세한 내용은 위 링크들에 잘 나와있고 요약하면 아래와 같습니다.

  • 2000년도에 포함 된 __nss_hostname_digits_dots() 코드에 취약점이 존재
  • 이를 호출하는 시스템 콜 중 gethostbyname()이 대표적
  • 호스트 주소와 이름을 저장하기 위한 버퍼 계산에서 포인터 크기만큼을 빼먹는 실수가 있음
  • 따라서, 32bit 머신은 4바이트 64bit 머신은 8바이트 만큼 크기 오차 발생
  • 계산 된 값으로 strcpy()로 복사를 하는데 복사 할 때는 제대로 된 크기만큼 복사해서 포인터 크기만큼의 취약점이 생겨남
  • Qualys가 소개한 내용처럼 몇몇 어플리케이션에서 해당 취약점을 악용 할 수 있음
  • 크기 계산 오류이기 때문에 2013년에 패치가 있었으며 이 때는 보안버그로 취급하지 않고 일반적인 버그로 취급하여 패치했다
  • 배포 주기가 긴 리눅스 배포판 들은 여전히 취약한 버전을 사용한다

제 3의 Heartbleed?

뉴스기사에서는 제 3의 Heartbleed 관측도 있다는 제목을 뽑았다.

먼저, 소스코드에서 취약한 부분을 동작시키기 위해서는 입력 값에 아래와 같은 전제 조건이 수반된다.

  1. 첫 번째 바이트는 숫자
  2. 마지막 바이트는 점(.)이면 안된다
  3. 숫자와 점 그리고 NULL로만 이루어져야 한다
  4. 버퍼의 크기가 커야 한다 (gethostbyname() 처럼)
  5. inet_aton()에서 정상적으로 파싱이 되어야 함

그런데, 개인적으로 이게 정말 Heartbleed 급이라고 볼 수 있을까라는 의문이 든다. 내가 드는 생각을 요약하면 아래와 같다.

  • 예외처리 없이 위 전제조건을 정상적인 입력 값으로 받아서 gethostbyname()을 호출하는 프로그램이 많을까?
  • 2000년에 추가 된 코드가 아직까지 문제를 일으킨 사례가 있었나?
    • 물론, 이를 잘 써먹고 있던 공격자가 있을 수도 있다.
  • 공격자에게 4(또는 8)바이트의 크기가 협소한 건 아닐까?
  • IPv6도 지원하지 않는 gethostbyname()보단 더 간편하고 좋은 getaddrinfo()를 요즘엔 많이 쓰지 않나?

제 점수는요

물론, 이 보안 취약점을 시스템 관리자가 무시 할 내용은 아니다. 대상이 광범위하고 세상에 많은 능력자가 있기 때문에 저걸 쉽게 사용하는 Exploit을 만들어 낼 지도 모른다.

하지만, 지금 상황에서는 Heartbleed 급이라는 얘기는 내게는 설레발처럼 느껴진다. 내가 공격자라도 이걸 이용하기 보다는 웹에서 상대적으로 쉽게(?) 만날 수 있는 여러 Injection 종류의 공격을 하겠다. (서버 어플리케이션은 패치 되어도 서비스 프로그램 버그는 널려있으니깐)