• 경고(?)
    • 이 글은 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 종류의 공격을 하겠다. (서버 어플리케이션은 패치 되어도 서비스 프로그램 버그는 널려있으니깐)

끝