Ext 2, Ext 3 개념과 분석 - 메타데이터 범주

-> 메타데이터 범주는 파일이나 디렉토리를 설명하는 데이터를 포함한다. 이 절은 데이터가 어디에 저장되어 있는지, 그리고 그것들을 어떻게 분석하는지에 대해 설명한다.

 

▶ 개요

- ExtX 에서 파일의 주 메타데이터는 inode 데이터 구조체에 저장된다. 추가적인 메타데이터는 확장된 속성들에 저장될 수 있다. 

 

▷ inode

- 모든 ExtX inode 들의 크기는 동일하고, 슈퍼블록에 정의되어있다. 한개의 inode는 모든 파일들과 디렉토리에 할당되고, 각 inode에는 1로 시작하는 주소가 있다. 슈퍼블록에서 크기가 주어지는 inode 집합은 각 블록 그룹에 할당된다. 각 그룹의 inode들은 테이블에 저장되고 그 위치는 그룹 기술자에서 주어진다. 그 그룹은 다음과 같은 계산으로 결정될 수 있다. 

 

group = (inode - 1) / inodeS_PER_GROUP

 

- inode 1~10은 대체로 예약되어있고, 할당된 상태로 있을 수 있다. 슈퍼블록은 예약되지 않는 첫 번째 inode의 값을 갖는다. 예약된 inode 중 단지 번호 2만 특정기능이 있고, 그것은 루트 디렉토리를 위해 사용된다. inode 1은 불량 블록들을 추적하는데 사용하지만 리눅스 커널에서 어떠한 특별한 상태도 갖지 않는다. 저널은 보통 inode 8을 사용하지만, 이것은 슈퍼블록에서 다시 정의할 수 있다. 첫 번째 사용자는 일반적으로 inode 11에 할당되고, 이것은 거의 lost + found 디렉토리를 위해 사용된다. 파일의 일관성 검사는 lost + found에서 디렉토리를 이용해 할당했으나, 파일이름이 없는 inode는 새로운 이름으로 이 디렉토리에 추가해 그것을 연결하는 파일 이름을 갖지 못하도록 한다. 

- 각 inode에는 필드에 고정된 번호가 있고, 추가정보는 확장된 속성들과 이 절 나중에 설명할 간접 블록 포인터에 저장된다. inode의 할당상태는 그룹 기술자에 있는 inode비트맵을 사용하여 결정된다.

- inode에는 파일의 크기, 소유권 같은 일시적 정보가 있다.

- '소유권' 정보는 사용자, 그룹ID를 이용해서 저장된다. 유닉스에서는 모든 사용자에게 ID를 할당하고, 사용자 ID를 사용자 이름으로 변경하는데 /etc/passwd 파일을 사용한다. 이와 유사하게 /etc/group 파일은 그룹 ID를 그룹이름으로 변환하는데 사용한다. chown과 chgrp을 통해 Id를 쉽게 변경할 수 있다. 따라서 inode의 사용자 ID정보로 사용자가 파일을 생성했다고 확신할 수 없다. 또한 모든 사용자 이름이 사용자 ID를 위해 /etc/passwd에 있어야 하는 것은 아니다. 표준 시스템 도구들은 사용자 이름을 찾을 수없다면 간단하게 ID를 보여준다.

- inode는 한시적 정보로 마지막 접근, 수정, 변경, 삭제시간을 포함한다. 그 시간들은 1970년 1월1일 UTC 이래로 초단위로 나타낸다. 마지막 수정, 접근 변경 시간들은 또한 UFS에 존재하고, 흔히 MAC시간으로 부른다. 마지막 접근시간 A-time(Access)은 파일내용에 마지막으로 접근된 시간에 해당한다. 마지막 수정시간 M-time(Modify)은 내용을 마지막으로 수정하고 변경한 시간에 해당한다. 마지막 변경시간 C-Time(change)은 파일 메타데이터가 마지막으로 변경된 시간에 해당한다. 삭제 또는 D-time은 파일이 지워졌을 때 해당한다. 리눅스와 다른 유닉스 시스템들에서 touch 명령어를 통해 임의의 M-, A-Time을 쉽게 변경할 수 있지만, C-time은 앞서 설명한 과정으로만 업데이트 된다. 

- 파일타입은 모든 필드에 저장되어 있고, 또 기본 허가권 값도 포함되어 있다. 유닉스에서는 모든 것이 파일이고, 그래서 거기에는 많은 파일 유형이 있다. 사용자가 생성하는 일반 파일은 정규파일(Regular File)이라 부르고, 디렉토리는 직관적으로 디렉토리라고 부른다. 

- 하드웨어 장치들에는 한개 또는 그 이상의 파일 이름들이 할당되고, 각각은 블록이나 문자 장치 타입이다. 블록장치(block device)는 하드디스크처럼 블록크기의 데이터 묶음으로 동작하는 장치이다. 2장에서 하드디스크는 어떤 데이터를 읽더라도 512바이트 이상을 읽어야 한다고 설명했다. 응용프로그램이 블록장치에서 한 섹터보다 적게 읽는다면 운영체제가 나머지 섹터들을 읽어 응용프로그램이 요청한 것을 되돌려준다.

반면에 문자장치(Character Device)는 미가공 장치로 불리며 키보드같이 블록단위 동작이 필요하지 않은 장치에 사용된다. 블록장치는 문자장치를 가질 수 있으나, 블록단위가 아닌 데이터를 읽거나 쓰면 오류가 발생한다. 파일에 할당된 블록에 대한 정보가 저장되어 있는 inode 공간은 장치 식별자 정보를 저장하는데 사용된다. 

- 다른 파일 타입들은 프로세스 사이에 데이터를 전송하는데 사용된다. FIFO는 지명형 파이프로 불리고 두개 또는 그 이상의 프로세스들 사이에 단방향 데이터 전송을 제공한다. 프로세스는 파일을 열고, 다른 프로세스가 파일에 쓴 데이터를 받는다. 그 데이터는 디스크가 아닌 커널 메모리에 저장된다. 만약 양방향 프로세스 통신이 필요하다면 유닉스 소켓이 사용된다. 유닉스 소켓은 특별한 기능을 사용해서 프로세스들을 여는 한 파일이고, 양방향 통신이 가능하도록 한다. 지명형 파이프들처럼 그 데이터는 디스크에 써지지 않는다. 파일의 마지막 유형은 소프트 링크라고 하는 심볼릭 링크이다. 심볼릭 링크들은 "파일 이름 범주" 절에서 좀 더 자세히 언급하겠지만, 그것들은 다른 파일이나 디렉토리에 단축 경로를 제공한다.

- 파일타입 이외의 모든 필드는 기본 허가권을 포함한다. 소유자, 그룹, 사용자들이 명령어를 읽고, 쓰고 실행할 수 있도록 이 허가권들을 부여한다.

예를들어 그룹에만 읽기 접근이 가능하도록 허가권이 설정되었다면 inode에 저장되어있는 ID가 그룹사용자인 경우만 그 파일을 읽을 수 있다. 그룹사용자들은 /etc/groups 파일을 사용해서 판단할 수 있다. 이것들은 운영체제가 허가권을 집행하지는 않기 때문에 부가데이터이다.

- 마지막으로 모든 필드는 파일이나 디렉토리가 갖는 특별한 속성을 구분한다. 'Sticky bit'가 실행파일에 설정되어 있다면 일부 프로세스 데이터는 프로세스가 끝난 후에도 메모리가 남아있을 것이다. 디렉토리에 설정시, 오직 파일의 소유자만 디렉토리 내용을 지울 수 있다. SUID(set user ID)와 SGID(set group ID) 비트들이 실행파일에 설정될 때 프로세스는 실제로 실행전 사용자 대신 SUID의 사용자와 그룹 권한으로 실행된다. 이것은 권한이 없는 사용자가 특정프로그램을 권한이 있는 사용자로 실행하도록 한다. SGID비트가 디렉토리에서 설정될 때 디렉토리에 모든 파일들은 디렉토리와 동일한 그룹 ID로 할당된다. 

- 각 inode에는 자신을 가리키는 파일 이름의 개수를 나타내는 링크카운트 값이 있다. 이 링크카운트 값이 0이고, 그 파일을 열고있는 프로세스가 없을때, inode는 비할당되어있다. 또한 inode는 새로운 파일이 할당될 때를 결정하기 위해 생성 ID값이 있고, NFS(Nework File System)에 의해 사용된다. inode를 새로운 파일에 할당할 때 이 값을 변경해서 서버가 새로운 파일이 존재하는지를 알 수 있도록 한다. 이것은 NTFS에서 보았던 순서번호와 유사하다. 리눅스는 이벤트 카운터로 이 값을 할당하고, 잠재적으로는 파일 할당순서를 결정하는데 사용한다. 데이터 구조체 레이아웃과 inode 예는 다음장을 보자.

 

▷ 블록포인터

- UFS 같은 ExtX는 작은 파일들의 효율성을 위해 설계되었다. 그래서 각 inode는 파일에 할당할 12개의 블록주소를 저장할 수 있고 이것은 '직접포인터'라고 한다. 파일에 12개 블록 이상이 필요하다면 한 블록을 나머지 주소들을 저장하는데 할당한다. 이 블록을 간접 블록 포인터라고 한다. 블록주소들은 모두 4바이트이며, 각 블록의 전체 수는 블록크기를 기반으로 결정된다. 간접 블록 포인터는 inode에 저장된다.

- 만약 한 파일이 12개의 직접포인터들과 간접블록에서 할당 가능한 것보다 많은 블록들이 필요하다면 이중간접 블록을 사용해야 한다. 이중간접 블록은 inode가 한 블록을 가리키는데, 단일 간접 블록 포인터가 직접 포인터 목록을 포함하는 경우이다. 마지막으로 파일에 여전히 더 많은 공간이 필요하다면 삼중 간접 블록 포인터를 사용한다. 지금까지 설명한 데이터 구조체 유형을 아래 그림에서 확인할 수 있다. 각 inode는 12개 직접포인터, 단일간접포인터, 이중간접 블록포인터, 삼중간접 포인터를 포함한다.

 

<단일, 이중, 삼중 간접 블록 포인터>

 

▷ 속성

- 각 플래그 필드를 설명하는 속성이 있지만 그것들은 실제로 현재 운영체제에서 지원하지 않는다. 지원된 속성들에는 파일과 디렉토리들의 A-Time을 업데이트 하지 않도록 하는 것이 있다. 어떤것은 캐시를 사용하지 않고 대신 데이터 변경이 일어나자마자 디스크에 쓰는 파일들을 정의하는 속성도 있다. 보안을 위해 두가지 속성이 있는데, 하나는 데이터를 지울 수 없고 추가하도록만 하고, 하나는 파일의 데이터를 변경하지 못하도록 하는 것이다. 마지막으로 덤프 속성은 dump 명령어가 파일을 백업할 때 저장해서는 안되는 파일을 지정한다. 

- 현재 일반적으로 지원되지 않은 속성들은 안전한 삭제, 압축, 비삭제가 있다. 안전한 삭제는 파일과 관련있는 블록들을 영구히 삭제하고, 비삭제는 파일이 지워졌을때 그것을 복구할 수 있도록 파일의 복사본을 만드는 것이다. 실험적인 패치들을 구성하는 리눅스 커널들은 이러한 속성들 중 몇개를 사용한다.

- 파일은 이미 설명했던 속성들 외에 확장된 속성들을 갖는다. 리눅스에서 확장된 속성들은 파일시스템이 usr_xattr 옵션으로 마운트될 때, 그리고 그것들을 지원할 때 사용할 수 있다. 파일시스템이 기본적으로 usr_xattr 옵션으로 마운트되었는지 /etc/fstab 파일을 확인해 점검할 수 있다. 파일시스템이 확장된 속성을 갖는다면 호환성 기능 플래그가 설정되어있다.

- 확장 속성에는 이름과 값 두개가 있다. 사용자는 setfatter 명령어를 이용해 'user.source = http://~~' 같이 어떤 쌍이든지 생성할 수 있다. 이 경우 user는 이름공간이고, 거기에 또한 신뢰와 보안이름 공간들이 있다. 그 확장된 속성들은 파일에 할당된 블록에 저장된다. 만약 한개 이상의 파일이 같은 확장된 속성을 갖는다면, 그것들은 동일한 블록을 공유한다.

- 운영체제가 확장된 속성들을 사용하는 방법들 중 하나는 POSIX ACL(Access Control List)이다. ACL들은 ExtX에서 파일 접근을 제한하는 것보다 더욱 개선된 방법이다. ACL로 선택된 사용자들은 유닉스 그룹을 사용하는 것 대신 접근이 허가된다. 그 ACL 정보는 확장속성에 저장된다. 사용자가 setfacl명령어로 ACL을 설정하면 그 파일시스템은 ACL 옵션으로 마운트 할 필요가 있다. 데이터 구조체와 확장된 속성들의 예제는 다음 장에서 확인할 수 있다.

 

▷ 예제 이미지

- 파일에 있는 예제 이미지를 보기 위해 파일시스템 이미지에서 istat를 실행한 결과를 보도록 하자. 이 inode는 다음장에서 해석할 예정이지만 간략하게 구성된 요약본을 확인해보자. 

 

-> 파일은 10MB이고, 할당된 블록들을 위해 4개의 간접 블록 포인터들이 필요하다. (inode=16) 위 결과에서 파일은 MAC 시간 뿐 아니라 권한과 파일유형 또한 볼 수 있다. 

 

 

▶ 할당 알고리즘

- 이 절은 ExtX 메타데이터를 할당하는 방법과 관련해 리눅스 커널 소스코드를 확인한 내용을 언급한다. 다른 운영체제나 리눅스 커널은 또 다른 할당 알고리즘을 사용할 수 있다. 이 할당 알고리즘의 내용은 페도라 코어 2 시스템을 분석해서 확인한 결과이다.

 

▷ inode 할당

- 새로운 inode를 파일이나 디렉토리에 할당할 대, 리눅스가 우선 고려해야 할 사항은 inode가 있어야 하는 블록그룹이다. inode가 디렉토리를 위한 것이 아니면, 리눅스는 부모 디렉토리와 동일한 블록에 inode를 할당한다. 이것은 디렉토리를 위한 모든 정보가 동일한 영역에 있도록 한다. 만약 그룹에 비할당된 블록이나 inode가 없다면 다른 그룹에서 탐색이 수행된다.

- 리눅스는 임의의 그룹을 선택하기 위해 이차 해시를 사용한다. 2차 해시 과정은 현재 블록 그룹에서 시작하고 2의 거듭제곱을 더해서 그룹을 선택한다.(1,2,4,8 등) 만약 선택된 그룹에 비할당 inode가 있다면 그것을 사용한다. 그 과정에서 비할당 inode가 있는 그룹을 찾지 못하면 현재 그룹에서 선형검색을 시작한다. 두 과정은 이용가능한 inode를 찾기위해 '첫 번째 적용' 검색을 사용한다.

- inode를 디렉토리에 할당한다면 inode를 가장 많이 사용하지않는 그룹에 위치시킨다. 이것은 모든 그룹들이 inode를 균등하게 사용하는데 도움을 준다. 이 탐색은 먼저 그룹당 비할당 inode 개수와 비할당 블록의 평균 개수를 계산한다. 슈퍼블록에 저장되어있는 비항당 inode와 블록 총 개수를 이용하여 계산할 수 있다. 리눅스는 그러고 나서 0으로 시작하는 각 그룹들을 탐색하고, 비할당 inode와 블록개수가 평균보다 더 작은 그룹에 첫 번째 비할당 inode를 사용한다. 이 두 값으로 발견된 그룹이 없다면, 디렉토리 개수가 가장 적고, 가장 많은 비할당 inode가 있는 그룹을 사용한다. 이 두 값들은 그룹 기술자에 존재한다. 

- inode가 할당될 때 이전의 내용들은 제거되고, MAC time은 현재시간으로 설정된다. D-time은 0으로 설정된다. 몇 개의 파일 이름이 그 inode를 가리키고 있는지 구분하는 링크카운트는 이름을 위해 1로 설정된다. 디렉토리는 그 내부의 '.' 엔트리 때문에 링크카운트가 2이다. 또한 리눅스는 생성 필드에 카운터 현재 값을 할당한다.

- 리눅스에서 파일이 지워졌을때, inode 링크 값은 1씩 감소한다. 만약 링크카운트가 0이되면, 그 inode는 할당이 해제된다. 만약 프로세스가 여전히 파일을 열고있다면 그 파일은 고아 파일이 되고 슈퍼블록 목록에 그 파일을 더한다. 프로세스가 파일을 닫거나, 시스템을 다시 부팅할때 그 inode(고아파일) 할당을 해제한다.  

 

▷ 시간 값 업데이트

- ExtX inode에는 4개의 한시적인 값들이 있고 그것들이 업데이트되는 경우를 언급할 필요가 있다.

 

⊙ A-time : 파일이나 디렉토리를 읽을 때 업데이트한다. 파일에서 이것은 프로세스가 그 내용을 읽을 때, 파일을 복사할 때, 파일을 새로운 볼륨으로 이동할 때 업데이트가 일어난다. 같은 볼륨으로 이동하는 것은 내용이 이동하지 않기 때문에 이 시간은 변경되지 않는다. 디렉토리에서 목록을 확인하거나, 파일이나 하위 디렉토리를 열었을 때, A-time은 업데이트 된다. 디렉토리의 블록 내용들은 디렉토리에 잇는 파일들의 이름이다.

⊙ M-time : 마지막 파일 수정시간에 해당하고, 그 시간은 파일이나 디렉토리의 내용이 변경될 때 업데이트된다. 파일에는 파일 내용이 일부 변경될 때 발생하고, 디렉토리에서는 파일이 생성되거나 지워질때 발생한다. 파일이 이동할때 파일의 내용이 변경되지 않는다. 따라서 파일의 M-time은 변경되지 않는다. 파일을 복사할 때 목적지 파일의 M-time은 새로운 파일 내용을 생성하기 때문에 현재 시간을 반영해서 업데이트 된다.

⊙ C-time : 마지막 inode 변경시간에 해당하고 파일이나 디렉토리의 메타데이터가 변경될 때 변경된다. 파일의 허가권, 소유권이 변경될 때 시간이 변경된다. 한 파일이 이동하면 그 파일의 C-time이 변경된다.

⊙ D-time : 오직 파일이 삭제될 때 설정되고, inode가 새롭게 할당될 때 그 값은 삭제된다. 지워진 많은 파일들의 M,C,D time 값은 같다.

 

-> ★중요★

요약하면 파일이 생성될 때, MAC는 생성시간으로 업데이트가 되고, D는 0으로 설정되며, 부모 디렉토리의 M,C는 업데이트된다. 파일이 복사시 부모 디렉토리는 A값이 바뀌고, 목적지 파일은 MAC 그리고 목적지 부모 디렉토리는 MC 값이 바뀐다. 파일이 이동될 때 원본 파일의 부모 디렉토리는 MAC를 업데이트하고, 목적 부모 디렉토리는 MC를 업데이트한다. 목적지 파일은 원본과 동일한 MA를 갖고 업데이트된 C를 갖는다. 만약 그 이동이 같은 볼륨이라면 동일한 inode를 사용하지만, 새로운 볼륨으로 이동했다면 원래의 inode는 비할당 되고, MACD들은 업데이트된다. 

 

 

▶ 분석기술

- 메타데이터 범주 분석은 파일과 디렉토리의 메타데이터를 저장하는 데이터 구조체 위치를 확인하고, 처리하는 것을 포함한다. ExtX에서는 inode 데이터 구조체 위치를 확인하고 처리한다. 특정 inode 위치를 확인하기 위해서 우선 어떤 블록 그룹인지를 판단할 필요가 있다. 다음에 그룹의 그룹 기술자를 처리하고, 그 그룹의 inode 테이블 위치를 확인한다. 마지막으로 테이블에 어떤 엔트리가 해당 inode를 위한 것인지를 구분하고 그것을 처리한다. 

- 간접 블록 포인터와 확장 속성을 제외하고 inode는 모든 메타데이터를 자체적으로 저장하고 있다. 파일이나 디렉토리에 할당된 블록들을 구분하기 위해 12개의 직접 블록 포인터를 읽는 더 많은 블록을 할당하면 단일, 이중, 삼중 블록 포인터를 처리한다. 만약 블록포인터가 주소를 0을 갖는다면 그 파일은 Sparse이고, 한 블록이 0으로 채워진다. 이는 그 파일의 일부분으로 할당되지 않는다.

- 그룹 기술자에서 inode 비트맵의 주소를 확인하고, inode 비트맵을 조사하여 inode의 할당상태를 결정하자. (1이면 할당)

- 삭제된 모든 파일들에 대한 데이터를 확인하기 위해 각 비할당된 inode엔트리를 조사할 필요가 있다,

- 확장된 속성들은 파일과 관련된 중요한 데이터를 포함할 수 있다. inode에 포인터들을 사용하고, 관련있는 블록을 처리하여 중요한 데이터 위치를 알 수 있다.

 

 

▶ 분석 고려사항

- UFS 기반 파일시스템들에 의해 사용되는 할당 정책은 비할당 inode엔트리가 쓰기 작업이 거의 없는 그룹에 있다면 더 오랜 이전시간 값을 유지할 수 있다. MCD 값은 파일이 지워졌을 때 그때 시간값으로 설정된다.

- 리눅스에서는 touch 명령으로 쉽게 M,A-time을 설정할 수 있기 때문에 독립적인 정보를 찾아서 해당 파일 시간의 신뢰성을 파악하는 것이 좋다. 예로 네트워크 패킷이나, 로그들이 있다. 시간 값은 UTC를 사용하므로 어느 시간대를 사용하는 지 알아야 한다. 

- 리눅스는 블록에 파일을 할당할 때 사용하지 않는 바이트들은 0으로 쓴다. 그래서 지워진 파일은 오직 비할당된 블록에만 존재한다. 

- 파일크기와 할당된 블록들은 비할당 inode에서 영구삭제가 된다. 그래서 간접 블록 포인터를 찾아봐야 할 수도 있다. 찾으려는 특정 파일이나 디렉토리가 있다면 할당정책을 사용해서 전체 파일 시스템 대신 특정 블록 그룹에 비할당 데이터를 추출할 수 있다. 만약 이 간접 블록 포인터들이 재할당되서 다른 블록들을 가리킨다면 다른 파일을 위해 존재하게 된다. 

- 추가 증거를 확보하기 위해 파일의 확장된 속성들도 조사해야한다. 분석도구 키워드 검색에서 이 속성 값들도 검색이 가능한지 테스트해야한다. 이것은 NTFS의 ADS(Alternate Data Stream)와 비슷하지만 크기가 훨씬 작다.

- 파일을 숨길 수 있는 방법 중 하나는 프로세스가 파일 하나를 열어 읽거나 쓰게 한 다음 그 파일 이름을 삭제한다. 이 경우 링크카운트는 0이지만, 비할당 되지 않는다. 슈퍼블록에 고아 inode가 추가되고, 사고 조사시 이 목록도 확인해야 한다. TSK fsstat을 실행하여 이 같은 파일을 확인할 수 있다.

 

 

▶ 분석시나리오

- 리눅스 사고조사시 의심스러운 이름의 디렉토리를 발견했다면 어떠한 사용자 계정이 그 파일을 생성했는지 확인해야 한다. inode는 파일 소유자의 사용자 ID를 포함하고, /etc/passwd 파일을 이용해 실제 이름을 확인할 수 있다.

- 사용자 ID 값을 변환할때 어떤 경우는 passwd파일에 해당 계정이 존재하지 않을 수 있다. 여기에는 두가지 발생 시나리오가 있을 수 있다. 

 

1. 사용자가 계정을 만든 후 그 파일을 생성하고 나서 계정을 삭제하는 경우이다.

2. 파일들이 tar같은 아카이브 파일로부터 생성된 것이다. 그래서 컴퓨터에는 그 ID가 있을 수 없다. 

 

- 첫 번째 시나리오 검증을 위해 /etc/디렉토리에 비할당 된 블록을 찾아야 한다. 검색용어를 위해서 현재 파일에서 스트링을 복사한다. -> 새로운 파일과 겹칠 수 있어서 이 검색은 성공적이지 않다.

- 두 번째 시나리오 검증을 위해 의문의 파일들을 포함하던 tar 파일을 시스템에서 검색하는 것이다. HoneynetProject에서 TSK로 타임라인을 만들면 아래와 같은 결과를 확인할 수 있다.

 

타임라인

-> /usr/man/.ci의 두 파일은 08:51:56의 변경된 시간을 갖고, 사용자 ID는 1010이다. 파일의 사용자 ID는 chown 명령어를 통해 변경될 수 있고, ID가 패스워드 파일에 존재하여도 그 파일을 생성한 사용자라는 사실을 증명할 수 없다. 만약 수상한 이름의 디렉토리를 생성한 사용자를 찾으려면, 부모디렉토리의 허가권을 조사해야한다. 위 예제에서 부모디렉토리는 /usr/local이고, root 소유권에 쓰기 허가권을 갖는다. 이것은 보통 설치했을 때 기본 권한으로 공격자가 디렉토리를 생성한 후 그 허가권들을 변경하지 않았다고 가정할 수 있다. 이것은 공격자가 루트계정에 접근한 것을 의미한다. 

 

 

---

p.s ........너무많았다