2017.06.26
Fahmida Y. Rashid | CSO
리눅스(Linux), 솔라리스(Solaris), BSD 기반 시스템이 공격자에게 루트 권한과 시스템 전체 제어권한을 갖게 하는 스택 클래시(Stack Clash) 취약점에 노출되어 있다고 퀄리스(Qualys) 연구진들이 경고했다.
특히 공유 환경의 관리자와 호스팅 제공업체는 주의해야 한다. 사용자 1명이 침해당하면 같은 서버의 다른 모든 사용자가 침해당할 수 있기 때문이다.
스택 클래시란 애플리케이션 스택(stack)에 영향을 미치는 권한 상승 취약점들(예: CVE-2017-1000364, CVE-2017-1000365, CVE-2017-1000367)을 지칭한다(애플리케이션 스택이란 애플리케이션에 사용되는 단기 데이터를 저장하는 곳으로 필요에 따라 크기가 늘어나는 메모리 구역이다).
애플리케이션의 스택 크기가 지나치게 늘어나면 힙(heap)에 지나치게 근접하게 된다(힙이란 현재 보기와 편집이 진행 중인 파일 등과 같은 정보를 저장하는 메모리 구역). 공격자는 이 두 메모리 구역의 근접성을 악용해 애플리케이션에 혼란을 일으켜 스택과 힙의 일부를 겹쳐쓰게 만든다. 이를 통해 애플리케이션 내부의 실행 흐름을 장악하는 것이다.
퀄리스 제품 관리 담당 이사 지미 그래함은 "스택 클래시는 스택 크기를 계속 늘리고, 보호 기능은 피해가며, 코드 실행이 불가능한 메모리 구역 내부로 침투한다"고 설명했다.
공격자는 장악한 프로그램의 권한을 얻게 된다. 단순히 흔한 애플리케이션도 아니고 신뢰받는 시스템 수준의 프로그램이다. 예를 들면, 데비안(Debian), 우분투(Ubuntu), 센트OS(CentOS) 등 리눅스 배포판의 'sudo', 데비안, 우분투, 페도라(Fedora), 센트OS의 Id.so와 SUID-루트 바이너리, 솔라리스의 'rsh' 등의 프로그램이다.
프로그램에 루트 권한이 있으면 공격자는 관리자의 자격으로 시스템 전체를 접수하게 된다. 그래함은 "사용자 수준 접근권한을 얻은 후에 루트(Roots)로 가는 비교적 간단한 방법"이라고 설명했다.
취약점은 i386 및 amd64 아키텍처 상의 유닉스(Unix) 기반 시스템에 존재한다. 레드햇, 데비안, 우분투, 수세(SUSE), 센트OS, 젠투(Gentoo) 등의 리눅스 배포판이 영향을 받는다. 솔라리스는 오라클(Oracle)이 소유하고 있다. FreeBSD, OpenBSD, NetBSD도 역시 영향을 받는다.
퀄리스는 취약점 해결을 위해 5월부터 배포판 및 업체들과 작업 중이며 업데이트가 공개되기 시작했다. 관리자들은 취약점에 노출된 시스템을 보안 업데이트로 신속히 업데이트해야 한다.
특히 서둘러야 하는 이유는 유닉스 기반 시스템이 주로 서버 환경에서 사용되기 때문이다. 퀄리스 측은 마이크로소프트나 애플 제품을 조사하지 않았으며, 이번 취약점이 이들 시스템에 어떤 영향을 미칠 것인가에 대해 확답을 주지 못했다.
특정 규정을 준수해야 하거나 중요한 데이터가 포함된 시스템을 우선적으로 업데이트해야 한다. 공유 환경을 담당하는 관리자와 호스팅 제공업체는 시스템이 업데이트 되도록 반드시 조치해야 한다.
여러 사용자가 존재하는 멀티테넌시(multi-tenancy) 시스템에서는 사용자가 서버에 쉘(shell) 접근권을 갖는 것이 보통이다. 이 경우, 공격자는 쉘 접근권이 있는 사용자를 침해한 후 스택 클래시를 이용해 해당 사용자 공간에 실행 중인 애플리케이션을 장악할 수 있다. 그 시점에 이르면 공격자가 해당 공유 환경의 다른 사용자 공간으로 점프해 이동하는 것이 가능하다.
스택 클래시에 의한 위험을 평가할 때 염두에 둬야 할 다섯 가지는 다음과 같다.
1. 로컬 익스플로잇에 의한 피해를 과소평가해서는 안 된다
퀄리스 연구진은 원격 익스플로잇(exploit)이 발견되지 않았지만 이를 배제할 수 없었다. 그것이 중요한 차이점이다. 발견되지 않았다고 해서 불가능하다고 단정할 수는 없다. 전적으로 프로그램 구축 방식에 달려 있다. 그래함은 퀄리스에서 살펴 본 데비안 상의 엑심(Exim) 메일 서버가 원격으로 악용되지 않았던 것은 '천운'이었다고 전했다.
공격 시 취약점이 하나만 이용되는 경우도 드물다. 여러 개를 결합해야 더 효과적이기 때문이다. 스택 클래시는 공격자가 네트워크에 침투해 좌우로 이동 시에 활용할 수 있는 강력한 무기다. 원격 익스플로잇 등을 통해 네트워크 침투의 초기 발판을 마련할 수도 있지만, 취약한 시스템에서는 스택 클래시를 이용해 루트 접근권을 얻고 다른 동작을 수행할 수 있다.
예를 들면, 최근 해결된 sudo 취약점(CVE-2017-100367)이 스택 클래시와 결합되면 임의의 코드를 최고의 권한으로 실행할 수 있다. 원격으로 접근 불가능한 서버라고 해서 방심하지 말고 서둘러 업데이트해야 한다.
2. 스택 보호 페이지는 이런 종류의 공격을 방지한다
아쉽게도 그렇지 않다. 사실 스택 클래시는 스택 보호 페이지(guard-page)를 완벽하게 우회한다. 스택 클래시의 개념은 2005년 이래로 잘 파악되었다. 지난 2010년 악용된 이후(CVE-2010-2240), 리눅스 커널(kernel)은 이런 종류의 공격을 약화시키기 위해 스택 보호 페이지를 추가했다.
보호 페이지는 스택과 힙 사이의 칸막이 역할을 한다. 그러나 퀄리스 연구진은 보호 페이지를 완전히 우회할 수 있었다. 왜냐하면 애플리케이션에 내장된 스택 보호 기능이 충분하지 않았기 때문이다.
퀄리스 연구진은 "아쉽게도 몇 킬로바이트짜리 스택 보호 페이지로는 충분하지 않다. 만일 스택 포인터가 보호 페이지를 '점프'해 버리면(즉, 보호 페이지에 접근하지 않고 스택에서 다른 메모리 구역으로 이동해 버리면), 페이지 폴트(page-fault) 예외가 일어나지 않고 스택은 다른 메모리 구역으로 확장되어 버린다"고 경고문을 통해 설명했다. "스택 클래시는 사용자 공간에 광범위하게 퍼져 있으며 스택 보호 페이지가 있어도 악용될 수 있음을 입증했다"고 덧붙였다.
업데이트를 적용할 수 있을 때까지 임시방편으로 스택 보호 페이지 크기를 최소한 1MB까지 늘려야 한다.
3. 스택 클래시는 가상 머신과 컨테이너에 영향을 미치지 않는다. 그러나…
그렇기도 하고 아니기도 하다. 스택 클래시는 운영체제 자체가 아닌 사용자 공간에서의 로컬 익스플로잇이다. 즉, 네임스페이스(namespace)와 컨트롤그룹(cgroup)과 같은 컨테이너 보안 격리가 제대로 작동한다면 공격자는 컨테이너 내에서 루트 권한을 얻을 수는 있어도 컨테이너를 빠져나가 시스템 상에서 루트 권한을 얻을 수는 없다. 분리가 제대로 되어 있기만 하다면 chroot에서 chroot로 점프하는 것은 불가능하다.
가상 머신도 마찬가지다. 가상 머신 내부의 취약한 운영체제에서 실행되는 프로그램은 장악할 수 있지만 상승된 권한은 가상 머신 자체 내에 머물게 된다. 공격자 입장에서는 컨테이너나 가상 머신을 빠져나올 수 있는 다른 취약점과 스택 클래시를 결합해야 한다.
그러나 매우 중대한 주의 사항이 하나 있다. 많은 기업이 가상 머신과 컨테이너에 의존해 배포와 관리를 간소화한다. 보안 업체 폴리버스(Polyverse Corporation) CEO 알렉산더 가너리스는 가상 머신 설정 후 그 안에 멀티테넌시 환경이나 공유 환경 호스팅 컨테이너를 설정한다면, 스택 클래시는 그러한 가상 머신과 컨테이너 안에 있는 모든 사용자에게 영향을 미칠 것이라고 경고했다. 이 시점에 이르면 기본 시스템이 베어메탈인지, 가상 머신인지, 컨테이너인지 여부는 더 이상 중요하지 않게 된다. 환경 내에서 사용자 1명이 침해당하면 다른 사용자의 침해로 이어지기 때문이다.
스택 클래시는 64비트 환경에서는 어렵고 도커(Docker) 컨테이너는 기본적으로 64비트에서 실행된다는 점도 참고할 만 하다. 도커 옵션 가운데에는 --ulimit stack=[size] 플래그를 추가해 컨테이너 이미지의 스택 크기를 제한하는 것도 있다. 단, 크기 값이 너무 낮으면 정상적인 애플리케이션 동작에 영향을 줄 수 있으므로 주의한다. 트위스트록(Twistlock)의 보안 연구자 대니얼 샤피라는 "이 옵션을 설정하면 "스택이 힙에 도달하는 일은 절대 없다"고 강조했다.
4. 암호화된 데이터는 서버가 침해되어도 안전하다
절대로 그렇지 않다. 데이터를 암호화해서 서버에 저장하는 것은 좋은 생각이지만, 만일 해당 데이터를 다루는 애플리케이션이 스택 클래시 공격에 의해 장악된다면 암호화된 정보도 침해당할 수 있다. 공격자가 루트 접근권한을 손에 넣으면 전면적인 제어가 가능하기 때문에 데이터 암호화를 풀 수 있는 애플리케이션에도 접근할 수 있는 것이다.
5. 임시방편을 활용하라. 그러나 절대 신뢰는 금물이다.
관리자들은 서버에 소프트웨어 업데이트를 적용할 때 조심해야 한다. 특히 패치는 잠재된 문제가 없는지 신중하게 테스트해야 하기 때문이다. 생산 서버 재부팅 역시 사전 계획이 많이 필요하다. 임시방편으로 스택 크기의 상한선을 설정할 수 있다. 로컬 사용자와 원격 서비스의 RLIMIT_STACK 및 RLIMIT_AS 리소스를 설정하면 된다. 그러나 이로 인한 문제도 있다.
스택 크기 상한선이 너무 낮으면 정상 작동에 필요한 매개변수를 이동시킬 수 없기 때문에 프로그램이 갑자기 중단된다. 애플리케이션의 최대값 산정에 필요한 적정량을 찾으려면 테스트가 필요하다. 극단의 작동 매개변수 상황을 많이 테스트해야 하기 때문에 정확히 알아내기도 어렵다.
이러한 임시방편도 우회될 가능성이 있다. 퀄리스의 경고문에는 "이 임시방편을 활용하되 위험 부담은 본인이 져야 한다. 상한선을 아무리 낮게 설정해도 모든 공격에 다 대항하지는 못할 가능성이 높다"고 전했다. 퀄리스에서 만든 악성 프로그램들이 할당한 힙 메모리는 137MB에 불과하며 스택 메모리는 "거의 없다시피" 하다. 최신 애플리케이션 기준으로는 너무 낮은 값이다.
동적 라이브러리 ld.so를 다시 구축/설치하고 gcc의 -fstack-check 옵션을 이용해 프로그램을 모두 다시 컴파일하면 스택 포인터가 다른 메모리 구역으로 이동하는 것을 막을 수 있다. 이를 위해 필요한 전 프로그램 재컴파일에는 분명히 막대한 노력이 소요되지만 스택 클래시를 완전히 막을 수 있다.
공격에 시간이 걸리도록 메모리 랜덤화
퀄리스의 개념 증명은 순차적으로 4단계를 거쳤다. 스택을 다른 메모리 구역과 충돌시키기, 스택 포인터를 스택 시작 부분으로 실행하기, 스택 보호 페이지 위를 점프하기, 스택이나 다른 메모리 구역을 충돌시키기 위해 메모리 구역에 쓰기(writing) 등이다. 마지막 단계인 메모리 구역에 쓰기에서 퀄리스는 무차별 대입 기법으로 ASLR(주소 공간 구조 랜덤화)를 우회하는 데 성공했다. 사용 엔트로피(entropy)가 8비트에 불과했기 때문이다.
가너리스는 "스택 클래시가 성공하는 이유는 공격 대상 시스템의 데이터 저장 장소와 코드의 행동 방식 등 예측 가능한 상세 정보에 의존하기 때문"이라고 설명했다. 공격자의 입장에서 상세 정보의 내용이나 존재 장소나 쉽게 예상된다면 무차별 대입 공격을 통해 필요한 정보를 입수할 수 있다. 예를 들면, 퀼리스 악용 프로그램은 가능한 조합을 모두 시도한 끝에 불과 5시간만에 ASLR를 우회하는 데 성공했다.
가너리스는 "만일 공격 대상의 상세 정보를 모르거나 예측할 수 없다면, 악용되는 근본적인 버그가 계속 존재한다고 해도 스택 클래시와 같은 공격은 무용지물이 된다"고 말했다. 스택 클래시 문제를 해결하려면 서버 업데이트에 예외는 없다. 취약한 시스템이 파상 공격의 제물이 되기 전에 업데이트를 실시해야만 심각한 피해를 막을 수 있다. editor@itworld.co.kr
추천기사