|
http://www.hackerschool.org/HS_Boards/zboard.php?id=advisory&no=21 [복사]
다음은 지난 3월 1일 iSEC에서 발표한 기술 문서를 번역한 것입니다.
:: Linux kernel do_mremap VMA 로컬 권한 상승 취약점 ::
.버전: Linux kernel 2.2 - 2.2.25, 2.4 - 2.4.24, 2.6 - 2.6.2
.URL : http://isec.pl/vulnerabilities/isec-0014-mremap-unmap.txt
.CVE : CAN-2004-0077
.저자: Paul Starzetz
.날짜: March 1, 2004
.번역: y2family@wiseguys(hackerschool research team)
문제점:
========
mremap(2) 시스템 콜 내부의 리눅스 커널 메모리 관리 코드가 함수 리턴값을 체크 하지
않아서 생기는 중대한 보안상 취약점이 최근 발견 되었다. 이 버그는 05-01-2004에 발표
된 mremap 버그와 같은 커널 내부의 함수 코드에 관련되어져 있다는 점 이외에는 완전히
별개의 것이다.
세부사항:
==========
리눅스 커널은 사용자가 접근 가능한 유효 메모리 지역들의 리스트를 프로세스별로 관리한다.
각각의 프로세스들은 소위 '가상 메모리 영역 기술자'들(VMAs)라고 불리는 단일 링크드 리스트
를 가지고 있다. 각각의 VMA는 페이지 보호와 같이 유효 메모리 지역의 출발점, 그것의 길이
뿐만 아니라 다양한 메모리 플래그들을 기술한다.
그 리스트 안에 있는 모든 VMA는 프로세스의 페이지 테이블의 한 부분과 각각 대응하며, 그
페이지 테이블은 프로세스에 의해 보여지는 물리적 메모리 페이지의 기술자들(Page Table
Entries-PTEs)을 포함한다. 그러므로 VMA 기술자는 '페이지 R/W 플레그 등과 같이 PTE 내용을
저장하는 특정한 영역의 프로세스 페이지 테이블' 이라고 할 수 있다.
mremap() 시스템 콜은 현존하는 가상 메모리 영역 또는 그것(VMA)의 어떠한 부분을 프로세스의
접근 가능한 메모리 공간으로 이동시킬 수 있을 뿐만아니라, 사이즈 또한 변화 시킬 수 있다.
(감소 또는 증가)
VMA 내부의 가상 메모리 일부를 새로운 장소로 이동시키는 것은 원래의 페이지 테이블 목록을
복사하는 것 뿐만 아니라 새로운 VMA 기술자를 생성하는 것을 필요로 한다.
이 일을 수행하기 위해 do_mremap 코드는 do_munmap()라는 커널 내부 함수를 불러 오는데, 이
함수는 기존의 가상 메모리 매핑을 제거하고 새로운 장소안에 존재하고 있지도 모를 기존의 메
모리 매핑을 제거 하기위해 쓰인다. 불행하게도 그 코드는 사용 가능한 최대 갯수의 VMA 기술
자 수가 초과 되어 실패할지도 모를 do_munmap() 함수의 리턴 값을 체크하지 않는다. 이것은
현존하는 메모리 매핑의 중간 부분 매핑을 해제시키고 VMA 기술자들이 프로세스의 한계 수치
(현재 65535)에 도달했을때 발생한다.
그중에서 한가지 가능한 상황을 다음 그림과 같이 나타낼 수 있다.
대응하는 페이지 테이블 엔트리들(PTEs)을 o와 x로 표시하였다.
mremap() 콜 이전:
(oooooooooooooooooooooooo) (xxxxxxxxxxxx)
[----------VMA1----------] [----VMA2----]
[REMAPPED-VMA] <---------------|
VMA 한계에 도달하지 않은 mremap() 콜 이후:
(oooo)(xxxxxxxxxxxx)(oooo)
[VMA3][REMAPPED-VMA][VMA4]
VMA 한계에 도달 한 mremap() 콜 이후:
(ooooxxxxxxxxxxxxxxoooo)
[---------VMA1---------]
[REMAPPED-VMA]
프로세스의 VMA 목록에서 VMAs가 최대 갯수에 도달한 이후부터, do_munmap()는 필요한 VMA 홀을
생성하는것을 거부한다. 그것은 VMA 기술자 한계를 초과하여 원래의 VMA를 2개의 VMA 영역으로
쪼개어 버릴 것이기 때문이다.
VMA1(이것이 바로 do_mremap 코드 내부에서 do_munmap의 첫번째 기원이다)의 중간 부분의 매핑
해제를 시도한 이후 리턴값을 체크하지 않음으로 인해서 VMA2의 대응하는 페이지 테이블 목록은
여전히 VMA1로 기술되는 페이지 테이블 영역 속으로 삽입되어 지고, 따라서 VMA1 페이지 보호
플래그의 영향아래 놓인다. 또한 VMA1 내부의 원래 PTEs가 상실되므로 대응하는 페이지 프레임
들은 영원히 사용할 수 없는 상태로 남겨진다.
커널은 또한 겹쳐진 VMA 영역을 VMA 기술자 리스트에 삽입하려고 하지만 이것은 나아가 저수준의
VMA 조작 코드가 체크 함으로 실패하게 된다. 커널 버전 2.4와 2.6 에서 저수준의 VMA 목록 체크
는 단지 BUG()를 호출함으로써 악의적인 프로세스를 종료시킨다.
do_mremap() 코드 내부의 do_munmap()에는 2가지의 또다른 체크되지 않은 호출이 있는데, 두번째
발생하는 체크되지 않은 do_munmap 역시 공격가능하다고 믿는다. 두번째 경우는 재 맵핑될 VMA가
잘려나갈 경우에 발생한다. do_munmap는 메모리가 아주 부족한 상황에서 VMA 기술자를 할당하려고
시도 할때도 실패할 수 있다는 것을 주목 하자.
취약점 공략:
============
취약점을 이용하는 것은 아주 쉬웠다. 우리들의 첫번제 추측은 읽기전용 파일(/etc/passwd 등)의
한 VMA 매핑을 다른 쓰기 가능한 VMA로 PTEs를 이동시키는 것이었다. 그러나 이 시도는 실패하였
다. BUG()가 호출된 이후 메모리 기술자의 mmap 세마포어가 잠긴 상태(down_write())로 되었기
때문 이었다. 따라서 다른 클론 쓰레드에서 세마포어를 획득하는 더 이상의 메모리 작업이 방지
되었다.
따라서 우리의 관심은 초기의 2.4 버전에서 소개되었지만 기본적으로 설정되지는 않았던 페이지 테
이블 케쉬 코드로 옮겨갔다. 2.4.19 이후의 커널에서는 기본적으로 페이지 테이블 캐쉬가 사용된다.
페이지 테이블 캐쉬의 기본 개념은 최근에 사용된 페이지 테이블들을 링크드 리스트에 보관하여
새로운 페이지 테이블 할당을 빠르게 하는 것이다.
리눅스 시스템의 모든 프로세스들은 페이지 디렉토리에 관한 포인터를 담고 있는 메모리 기술자
(mm_struct)와 관련이 있다. 이 페이지 디렉토리는 페이지 테이블에 대하여 1024개의 포인터들을
포함하는 싱글 페이지 프레임(우리는 PAE가 없는 4kb 크기의 페이지에 대해서 기술한다)이다.
i386기반에서 하나의 페이지 테이블은 프로세스 가상메모리의 4MB 까지 커버하는 1024개의 PTEs를
가지고 있다. 하나의 PTE는 PTE의 가상 주소에 매핑된 물리적 주소와 페이지 접근 권리를 포함한다.
페이지 테이블들은 페이지 폴트가 발생하는 경우에 할당되어진다. 그리고 만약 프로세스가 최소한
4MB 크기와 4MB의 정렬된 메모리 영역 부분을 포함하는 적어도 한 페이지 테이블 범위의 가상 메모
리 매핑이 해제되는 경우 페이지 테이블은 자유롭게 되며 대응하는 페이지 프레임들은 메모리 관리
자에게로 넘어간다.
새로운 페이지 테이블이 할당 되어야져 한다면 다음과 같은 두가지의 길이 있다:느린것과 빠른것.
빠른 방법은 페이지 테이블 캐쉬의 첫 부분으로부터 한 페이지를 차지하는 반면에 느린 방법은
단지 get_free_page()만 호출한다. 이것은 페이지 테이블 캐쉬의 페이지들이 캐쉬에 삽입되기 전에
적절하게 제거된 경우에 잘 작동한다. 일반적으로 페이지 테이블들은 do_munmap로 부터 호출되는
zap_page_range()에 의해 제거된다. 실제의 유효한 PTE를 포함하는 프로세스의 페이지 테이블의
모든 장소가 대응하는 VMA 기술자에 의해서 커버 되는데, 이것은 리눅스 메모리 관리를 적절히
작동시키는데 아주 중요하다.
mremap 코드 안에서 체크 되지 않은 do_munmap의 경우에서, 우리는 VMA에 의해 커버되지 않은체
페이지 테이블의 한 부분이 남겨지는 경우를 찾았다. 그 코드는 다음과 같다.
[269] if (old_len >= new_len) {
do_munmap(current->mm, addr+new_len, old_len - new_len);
if (!(flags & MREMAP_FIXED) || (new_addr == addr))
goto out;
}
이 부분의 코드는 사용자가 매핑을 해제하기를 원하는 위치의 VMA를 자르는 역할을 한다.
do_munmap는 [addr+new_len, addr+new_len + (old_len-new_len)] 부분이 VMA의 중간 부분으로
가고 허용된 최대 번호의 VMA 기술자가 이미 프로세스에 의해 사용되어 지고 있다면 실패할 것
이란 것을 쉽게 볼 수 있다. 그것은 또한 페이지 테이블은 addr+new_len 으로부터 여전히 유효한
PTEs를 포함하게 된다는 것을 의미한다. 이후 mremap 코드에서, VMA의 대응하는 한 부분은 이동
되고 잘려진다.
[179] if (!move_page_tables(current->mm, new_addr, addr, old_len)) {
unsigned long vm_locked = vma->vm_flags & VM_LOCKED;
if (allocated_vma) {
*new_vma = *vma;
new_vma->vm_start = new_addr;
new_vma->vm_end = new_addr+new_len;
new_vma->vm_pgoff += (addr-vma->vm_start) >> PAGE_SHIFT;
그러나 새로운 장소가 MREMAP_MAYMOVE 플래그의 상태인 경우 생성된 VMA의 길이보다 더 많은 PTE
s(즉 old_len)가 이전의 장소로 부터 이동된다. 이것은 이전의 do_munmap가 실패하지 않은 경우
에만 효과가 있다. 이 경우는 다음과 같이 나타내어질 수 있다.
mremap 이전:
<-- old_len -->
(oooooooooooooooooooooooooooo)
[------|-----VMA1-----|------]
|---------------------------------> new_addr
VMA 한계 아닐경우, mremap 이후:
new_len
(oooooo) (oooooo) (oooooo)
[-VMA1-] [-VMA3-] [-VMA2-]
VMA 한계일 경우, mremap 이후:
new_len [*]
(oooooo oooooo) (oooooo)ooooooooo
[-----------VMA1-------------] [-VMA2-]
페이지 테이블 안에 이런 [*] '임자없는' PTE들은 메모리 관리자가 통제력을 상실했기 때문에
더 나아가 공격이 가능하다. 이제 만약 프로세스가 저 주인없는 PTEs들을 커버하는 충분히 큰
지역을 매핑해제 하는 경우, 밑에있는 페이지 테이블 프레임이 페이지 테이블 캐쉬로 삽입 될
것이다. 하지만 아직 유효한 PTEs를 포함한다. 그것은 프로세스 P에서 주소 A로의 다음 페이지
테이블 프레임 할당시에 우리의 PTEs는 프로세스 P의 페이지 테이블 안에 나타난다는 것을 의미
한다! 그 프로세스가 주소 A 의 가상 메모리에 접근하려고 시도 하는 경우 PTEs가 적절한 권한
(읽기 또는 쓰기)을 가지고 있다면 페이지 폴트 또한 일어나지 않을 것이다. 즉, 페이지 테이블
케쉬를 통하여 우리는 어떠한 데이터라도 다른 프로세스의 가상 메모리 공간에 삽입할 수 있다는
것이다.
우리의 코드는 setuid 바이너리를 통하는 방법을 사용하지만 이것이 가능한 모든 방법은 아니다.
캐쉬 바로 앞에 하나의 빈 페이지 프레임이 존재 하도록하기 위해서 페이지 테이블 캐쉬를 그리고
스스로 실행하는(self executing) 페이지들을 포함하는 특별한 페이지 테이블을 준비했다.
그것이 어떻게 작동하는지 완전히 이해하기 위해서는 execve() 시스템 콜을 파헤쳐 봐야만 한다.
만약 사용자가 execve()을 호출하면, 커널은 프로세스에 대해 가상 메모리 지역과 프로세스의 페
이지 테이블 할당을 포함한 현재 실행 가능한 모든 추적을 제거한다. 그런 후 가상 메모리의
꼭대기에 새로운 바이너리의 프로그램 환경변수와 인자들이 저장되는 스택을 위한 새로운 VMA가
생성된다.(그것들은 커널 메모리에 보존된다.) 이것은 첫번째 페이지 테이블 프레임이 가상 메모
리의 0xbfc00000에서 0xc0000000까지의 지역에 할당되게 된다.
다음은, 더 이상의 로딩을 담당하는 프로그램 인터프리터 뿐만아니라 실행 될 바이너리의 .text
와 .data 부분이 새로운 가상 메모리 공간으로 매핑된다. ELF 링킹 포멧 때문에 이것은 보통
ld.so 다이나믹 링커이다. 이 부분에서 커널은 아래의 페이지 테이블을 할당하지 않는다. 오직
VMA 기술자들이 프로세스의 VMA 목록으로 삽입될 뿐이다.
중요치 않은 몇몇의 작업 이후 커널은 바이너리를 실행하기 위해서 제어권을 다이나믹 링커에게
로 넘긴다. 이것은 두번째 페이지 폴트를 일으키며 다이나믹 링커 첫번째 코드 페이지의 로딩을
유발한다. 표준의 리눅스 커널에서 이것은 0x40000000에서 0x40400000까지 범위의 페이지 테이블
을 위한 페이지 프레임을 할당 할 것이다.
페이지 테이블 캐쉬가 사용되는 커널에서 두가지 할당 모두 첫번째 캐쉬로 부터 페이지 프레임을
가질 것이다. 이것은 만약 캐쉬 페이지 리스트 안의 두번째 페이지가 유효한 PTEs를 포함하면
그것들이 정상적인 다이나믹 링커 코드대신 나타나게 된다는 것을 의미한다. PTEs를 위치 시켜서
그것들이 다이나믹 링커의 코드 영역을 덮어버리게 하는것은 쉽다. 페이지 테이블의 첫번째 PTE
는 페이지 리스트를 유지하기 위해 캐쉬 코드에 의해 사용된다는 것을 주의해야 한다. 우리의
코드에서는 페이지 테이블 캐쉬를, 마지막에 짧은 쉘코드가 있고 NOP로 채워진 페이지의 PTEs를
포함하는 특별한 프레임으로 위치하게 하였다.
또한 2004년 1월 5일 발견되어진 첫번째 mremap 홀 또한 페이지 테이블 캐쉬를 통해서 아주 쉽게
공격이 가능하다. 세부 사항은 숙련된 독자들을 위해 남겨둔다.
mremap 버그 공격을 위한 두번째 가능성은 /etc/passwd와 같은 읽기 전용 파일로 부터 주인없는
PTEs를 커버하는 또다른 VMA를 생성하는 것이다.
영향:
=====
mremap(2) 시스템 콜을 이용하는데 특별한 권한이 필요없기 때문에 어떠한 프로세스라도 커널
메모리 관리 하부조직을 붕괴시키기 위해 그 예기치 않은 행동을 사용 하는것이 가능하다.
이 취약점의 적절한 이용은 공격자에게 루트 권한을 주는 로컬 권한 상승을 유도한다. 또한 그
취약점은 사용가능한 시스템 메모리에 서비스 거부 공격(DOS)을 이르킬 수 있다.
테스트 되고 취약한 것으로 알려진 커널 버전은 2.2.25이하, 2.4.24 이하 그리고 2.6.2 이하
모든 버전이다. 리눅스 커널 2.2.25 버전은 MREMAP_FIXED 플래그를 인식하지 않는다. 하지만
이것이 성공적으로 공격 당하는 것을 막지는 못한다. 모든 사용자는 적절한 패치가 배포되는
즉시 패치할 것이 권장된다. 제한된 사용자당 가상 메모리 또한 do_munmap()를 실패하게 한다.
저자의 말:
==========
Paul Starzetz 가 이 취약점을 밝혀냈으며 연구를 하였음.
이곳에 제공된 복사, 배포 그리고 정보의 수정은 저자의 동의하에 허가됨.
역자의 말:
==========
이 글의 저작권은 없습니다. 역자에게는 오역이나 악용 으로 인한 책임은 없으며, 오역 된
부분이 있다면 메일로 연락주시고 검토후 수정하도록 하겠습니다.
[취약점 패치] |
Hit : 3581 Date : 2004/03/16 09:48
|
25, 
1/1 
멍멍
