---[  Phrack Magazine   Volume 8, Issue 52 January 26, 1998, article 18 of 20

-------------------------[  Weakening the Linux Kernel
-------------------------[  Linux Kernel 무력화시키기

--------[  plaguez <dube0866@eurobretagne.fr>
--------[  번역 : redcloak <redcloak@igrus.inha.ac.kr>
--------[  최근 수정 : 2002년 2월 8일



----[  머리말


다음은 Linux x86 2.0.x kernel을 대상으로 한다. 이전 버젼에서도 적용가능할 것 같으나,
테스트해보지는 않았다. 2.1.x kernel은 memory management 루틴에 있어 주목할 만한
많은 변화가 소개되었으므로 여기에서는 다루지 않는다.

많은 세련된 아이디어를 준 Halflife와 Solar Designer에게 감사하며, plaguez와 WSD가
이를 소개하겠다.


----[  사용자 공간 vs 커널 공간


Linux는 수많은 아키텍쳐를 제공하지만, 이 문서의 대부분의 코드와 논의는 i386 version에
대한 것이다.

메모리는 커널 공간과 사용자 공간, 두 부분으로 이루어진다. 커널 공간은 GDT(Global
Descriptor Table)에서 정의되며, 각 프로세스의 주소 공간(address space)으로 대응된다.
사용자 공간은 LDT(Local Descriptor Table)에서 정의되고, 각 프로세스에 대한 local영역을
나타낸다. 한 프로그램은 그것이 사용자 공간, 커널 공간에 대응이 되더라도 사용자 공간과
커널 공간에 동시에 있을 수 없으므로 커널 메모리에 직접 쓸 수 없다.

또한 전형적으로 커널에서 사용자 공간의 메모리로 접근할 수 없지만, 이는 정말 쉽게
극복할 수 있다. 우리가 시스템콜을 수행하게 되면, 커널이 하는 일 가운데 가장 먼저
하는 것이 DS(Data Segment register)와 ES(Extra data Segment register)를 메모리
참조를 할 수 있도록 커널 데이터 세그먼트를 가리키도록 세팅하는 것이다. 만일 우리가
시스템콜에서 커널 메모리를 사용하길 원한다면, FS(F data Segment)를 먼저 스택에
push한 다음, FS값을 DS값으로 세팅해야만 한다. 물론 이것을 정확히 테스트해보지는 
않았으므로, 양념으로 맛보길 바란다. :)

여기 커널 모드에서 사용자 공간의 메모리에서 데이터 바이트를 읽거나 사용자 공간의
메모리로 쓰기 위해 사용하는 몇 개의 유용한 함수가 있다. 

#include <asm/segment.h>

get_user(ptr)
    인자로 주어진 byte, word, long형의 데이터를 사용자 공간의 메모리에서 가져온다.
    이것은 매크로이며, 전송할 바이트 수는 인자의 타입에 따라 결정된다. 
    우리는 형변환(typecast)을 적절하게 사용해야 한다.

put_user(ptr)
    get_user()와 같으며, 데이터를 읽는게 아니라 사용자 공간의 메모리에 쓴다.

memcpy_fromfs(void *to, const void *from,unsigned long n)
    사용자 공간의 메모리 *from가 가리키는 곳에서 커널 공간 메모리의 *to가 가리키는
    곳에 n 바이트를 복사한다.

memcpy_tofs(void *to,const *from,unsigned long n)
    커널 메모리내에 *from이 가리키는 곳에서 사용자 공간 메모리내의 *to가 가리키는
   곳으로 n 바이트를 복사한다.



----[  System calls


대부분의 libc function call은 사용자 프로그램이 호출할 수 있는 가장 간단한 커널 함수인
내부의 시스템콜에 의존한다. 이러한 시스템콜은 커널 자체에서 구현되기도 하고, 커널
코드와 동적으로 링크가능한 LKM(Loadable Kernel Module, 동적으로 적재가능한 
커널 모듈)형태로 구현되기도 한다.

MS-DOS와 다른 많은 OS처럼, Linux 시스템콜은 주어진 마스킹(역자주 : EFlags 
레지스터의 IF(Interrupt Flag)를 0으로 세팅하여 인터럽트를 금지시킬 수 있다)
가능한 인터럽트와 함께 호출되는 멀티플렉서(역자주 : 시스템 콜 핸들러를 의미)
를 통해서 구현된다. Linux에서 이 인터럽트가 int 0x80이다. 'int 0x80' 어셈블리어
명령이 실행되면, 제어는 커널로 넘겨지며(보다 정확히 말하면, _system_call() 
함수로), 실제 디멀티플렉싱(역자주 : 시스템콜 핸들러에서 해당하는 시스템콜 서비스
루틴으로 연계) 작업이 이루어진다.

_system_call() 함수는 다음과 같이 작동한다:

먼저, 모든 레지스터 값을 저장하고, %eax 레지스터의 내용을 모든 시스템 콜과 메모리상의
주소를 열거하고 있는 전역 시스템콜 테이블의 엔트리와 비교한다. 이 테이블은 
extern void *sys_call_table[] 변수를 가지고 접근할 수 있다. 이 테이블에서 시스템콜
번호와 메모리주소(역자주 : 해당 시스템콜 서비스 루틴의 메모리상의 위치)가 각 시스템콜과
일치한다. 시스템콜 번호는 /usr/include/sys/syscall.h에 'SYS_시스템콜이름' 형태로 정의
되어 있다. 만일 어떤 시스템콜이 구현되어 있지 않다면, sys_call_table내에 부합하는 엔트리
값은 0이며 error가 리턴된다. 그렇지 않으면, 시스템콜이 존재하며 부합하는 테이블내의 엔트
리는 시스템콜 코드가 있는 메모리상의 주소가 된다.

여기 유효하지 않은 시스템콜 예제가 있다:

[root@plaguez kernel]# cat no1.c
#include <linux/errno.h>
#include <sys/syscall.h>
#include <errno.h>

extern void *sys_call_table[];

sc()
{ // 현재 시스템콜 번호 165가 존재하지 않는다.
  // (역자주 : sys/syscall.h, asm/unistd.h에 보면 현재(linux 2.4.x) 165번은 getresuid 
  // 시스템콜에 할당되어 있다.)
    __asm__(
            "movl $165,%eax
             int $0x80");
}

main()
{
    errno = -sc();
    perror("test of invalid syscall");
}
[root@plaguez kernel]# gcc no1.c
[root@plaguez kernel]# ./a.out
test of invalid syscall: Function not implemented
[root@plaguez kernel]# exit


정상적인 경우에, 제어는 사용자가 요청한 것을 수행하는 실제 시스템콜로 옮겨갔다가
리턴(역자주 :  시스템콜 서비스 루틴을 실행후 시스템콜 핸들러로 리턴)하게 된다.
그런 다음 _system_call()은 여러가지?를 체크하기 위해 _ret_from_sys_call()
을 호출했다가 끝으로 사용자 공간의 메모리로 리턴하게 된다.

----[  libc wrappers
----[  libc 포장함수

int $0x80이 시스템콜을 위해서 직접 사용되지는 않는다; libc 함수가 인터럽트 0x80에
대한 포장함수(wrapper)로 사용된다.
libc는 실제 커널 함수에 대한 사용자 공간의 인터페이스이다.

libc는 일반적으로 _syscallX() 매크로(X는 해당 시스템콜에 대한 파라미터의 개수)를 
사용하는 시스템콜의 특성을 갖는다.

예를 들어, write(2)에 대한 libc 엔트리는 실제 write(2)의 프로토타입이 파라미터 3개를
요구하기 때문에, _syscall3 매크로로 구현된다. 인터럽트 0x80을 호출하기 전에,
_syscallX 매크로는 스택프레임과 해당 시스템콜이 요구하는 인자 리스트를 세팅해야
한다. 결국, _system_call()(int $0x80으로 호출되는)에서 리턴되면, _syscallX() 매크로는
%eax에 있는 리턴값이 음수인지 확인하고 errno을 해당하는 값으로 세팅하게 된다.

write(2)가 어떻게 전처리되는지 다른 예제를 보자.

[root@plaguez kernel]# cat no2.c
#include <linux/types.h>
#include <linux/fs.h>
#include <sys/syscall.h>
#include <asm/unistd.h>
#include <sys/types.h>
#include <stdio.h>
#include <errno.h>
#include <fcntl.h>
#include <ctype.h>

_syscall3(ssize_t,write,int,fd,const void *,buf,size_t,count);

main()
{
    char *t = "this is a test.\n";
    write(0, t, strlen(t));
}
[root@plaguez kernel]# gcc -E no2.c > no2.C
[root@plaguez kernel]# indent no2.C -kr
indent:no2.C:3304: Warning: old style assignment ambiguity in "=-".
Assuming "= -"

[root@plaguez kernel]# tail -n 50 no2.C


#9 "no2.c" 2




ssize_t write(int fd, const void *buf, size_t count)
{
    long __res;
    __asm__ __volatile("int $0x80":"=a"(__res):"0"(4), "b"((long) (fd)), 
"c"((long) (buf)), "d"((long) (count)));
    if (__res >= 0)
        return (ssize_t) __res;
    errno = -__res;
    return -1;
};

main()
{
    char *t = "this is a test.\n";
    write(0, t, strlen(t));
}
[root@plaguez kernel]# exit



위의 write() 함수에서 '4'가 /usr/include/sys/syscall.h(역자주 : 2.4.x kernel에서는 
/usr/include/asm/unistd.h를 참고)에서 정의된 SYS_write와 일치한다는 것을 알 수 
있다.


----[  나만의 시스템콜 만들기

자신만의 시스템콜을 만드는 데에는 몇 가지 방법이 있다. 예를 들면, 커널 소스를 변경하여
자신의 코드를 붙일 수도 있다. 하지만 좀더 쉬운 방법은 적재가능한 커널 모듈(LKM)을 
만드는 것이다.
LKM은 필요할 때 커널에 동적으로 링크될 코드를 포함하고 있는 파일 객체 이상 아무것도
아니다.

이것은 작은 커널을 만들기 위함에 주 목적이 있으며, 필요할 때 insmod(1) 명령으로
원하는 드라이버를 커널에 올릴 수 있다. 또한 커널 소스 트리내에 코드를 써넣는 것보다
lkm을 만드는 것이 좀더 쉽다.

lkm을 가지고, 시스템콜을 추가하거나 변경하는 것은 다음에 보게될 sys_call_table 배열을 
변경하는 문제일뿐이다.



----[  lkm 만들기

lkm은 C로 쉽게 만들 수 있다. 몇 줄의 #define, 코드부분, init_module()이라고 부르는 초기화
함수와 cleanup_module()이라고 부르는 모듈을 내리는 함수로 구성된다. init_module()과
cleanup_module() 함수는 모듈 적재와 모듈 삭제라고 부를 것이다. 또한 모듈은 커널코드
이며, 만들기 쉽다고 할지라도 어떤 프로그래밍 실수나 굉장히 심각한 결과를 초래할 수도 
있다는 것을 명심하기 바란다.

여기 전형적인 lkm 소스 구조가 있다:



#define MODULE
#define __KERNEL__

#include <linux/config.h>
#ifdef MODULE
#include <linux/module.h>
#include <linux/version.h>
#else
#define MOD_INC_USE_COUNT
#define MOD_DEC_USE_COUNT
#endif

#include <linux/types.h>
#include <linux/fs.h>
#include <linux/mm.h>
#include <linux/errno.h>
#include <asm/segment.h>
#include <sys/syscall.h>
#include <linux/dirent.h>
#include <asm/unistd.h>
#include <sys/types.h>
#include <stdio.h>
#include <errno.h>
#include <fcntl.h>
#include <ctype.h>

int errno;

char tmp[64];

/* for example, we may need to use ioctl */
_syscall3(int, ioctl, int, d, int, request, unsigned long, arg);

int myfunction(int parm1,char *parm2)
{
   int i,j,k;
   /* ... */
}

int init_module(void)
{
   /* ... */
   printk("\nModule loaded.\n");
   return 0;
}

void cleanup_module(void)
{
   /* ... */
   printk("\nModule unloaded.\n");
}

#defines (#define MODULE, #define __KERNEL__)와
#includes (#include <linux/config.h> ...)는 꼭 써넣어야 한다.

또한 lkm은 커널 모드에서 실행될 것인만큼 libc 함수를 사용할 수 없다. 하지만 앞에서 논의
된 _syscallX() 매크로를 이용하여 시스템콜을 사용할 수 있고, 또는 sys_call_table 배열에
서 함수에 대한 포인터를 사용함으로써 직접 시스템콜을 호출할 수도 있다.

이 모듈을 'gcc -c -O3 module.c'와 같이 컴파일하고 'insmod module.o'로 커널에 삽입할
수 있다. (최적화를 반드시 해야한다).

제목처럼 lkm은 커널 전체를 컴파일하지 않고 커널 코드를 수정하기 위해 사용될 수 있다.
예를 들면, write(2) 시스템 콜을 주어진 파일의 부분을 숨기도록 패치할 수 있다. 또한 백도어
를 심어놓기에 좋은 장소이기도 하다: 만일 자신의 커널을 신뢰할 수 없다면 무슨 일을 하겠는
가? :-P


----[  커널과 시스템 콜 백도어

이를 위한 주 아이디어는 굉장히 간단하다. 우리는 보통의 시스템콜을 우리가 원하는 대로 커널
이 반응하도록 만들 lkm안의 우리 자신의 시스템콜로 리다이렉트할 것이다. 예를 들어, 우리
는 IOCTL 시스템콜을 패치하여 PROMISC 비트를 마스킹하고 스니퍼를 숨길 수 있다. 충분하
진 않지만 효과적이다.

주어진 시스템콜을 변조하려면, lkm안에 extern void *sys_call_table[] 정의를 추가하고,
init_module() 함수를 sys_call_table안의 해당 시스템콜에 일치하는 엔트리를 실제 시스템콜
서비스 루틴이 아닌 우리 자신의 코드를 가리키도록 변조한다. 그러면 모든 사용자 프로그램이 
그러한 시스템콜에 의지하기 때문에, 변조된 시스템콜을 사용하는 경우 우리가 원하는 대로
행동하도록 할 수 있고, 이렇게 되면 그 전체 시스템에 대한 제어를 갖게 되는 것이다.

이것은 침입자가 시스템에 침입했을 때, 그 시스템에 머무르는 것을 막기가 매우 어려워진다는
것을 의미한다. 막는다는 것은 여전히 보안을 위해 최고의 방법이며, 기밀을 다루는 시스템의
경우에는 리눅스 커널을 견고하게 만드는 것이 필요하다.


----[  몇 가지 프로그래밍 트릭

- lkm내에서 시스템콜을 호출한다는 것은 사용자 공간에서 인자를 해당 시스템콜에 넘기는 것
만큼이나 매우 쉽다. 만일 커널 공간으로 인자를 넘길 필요가 있는 경우에, FS 레지스터를
변경하였는지 확인해야 한다. 그렇지 않으면 모든 것이 표면으로 드러날 것이다. 이것은 함수에
대한 포인터 변수에 시스템콜 함수를 가리키도록 저장하고, 그 변수를 사용하는 문제일뿐이다.
예를 들면:

#define MODULE
#define __KERNEL__

#include <linux/config.h>
#ifdef MODULE
#include <linux/module.h>
#include <linux/version.h>
#else
#define MOD_INC_USE_COUNT
#define MOD_DEC_USE_COUNT
#endif

#include <linux/types.h>
#include <linux/fs.h>
#include <linux/mm.h>
#include <linux/errno.h>
#include <asm/segment.h>
#include <sys/syscall.h>

#include <unistd.h>
#include <linux/unistd.h>


int errno;

/* pointer to the old setreuid system call */
int (*o_setreuid) (uid_t, uid_t);
/* the system calls vectors table */
extern void *sys_call_table[];


int n_setreuid(uid_t ruid, uid_t euid)
{
    printk("uid %i trying to seteuid to euid=%i", current->uid, euid);
    return (*o_setreuid) (ruid, euid);
}


int init_module(void)
{
    o_setreuid = sys_call_table[SYS_setreuid];
    sys_call_table[SYS_setreuid] = (void *) n_setreuid;
    printk("swatch loaded.\n");
    return 0;
}

void cleanup_module(void)
{
    sys_call_table[SYS_setreuid] = o_setreuid;
    printk("\swatch unloaded.\n");
}

-  모듈은 여러 방법으로 숨길 수 있다. Runar Jensen이 버그트랙에서 보인 것처럼,
다른 프로그램이  /proc/modules을 읽기 전에 몰래 /proc/modules에서 없앨 수 있다.
그러나 이 방법은 증명된 것만큼, 구현하는 것이 다소 어려우며 'dd if=/proc/modules
bs=1'으로 모듈을 볼 수 있다. 다른 방법이 필요한데, Solar designer (다른 무명씨들도 :))
가 한가지 방법을 제안했다. 모듈정보(module info) 리스트는 커널로 전달되지(exported) 
않기 때문에 우리 모듈의 init_module()를 호출하는 sys_init_module()에서 사용하는 모듈정보
구조체를 제외하고는 이것에 직접 접근할 수 있는 방법이 없다. gcc는 init_module()에 들어가
기 전에 레지스터를 건드리지 않기 때문에 struct module *mp에서 사용되는 레지스터를 미리
가져와서 이 구조체(환형 리스트) 멤버의 주소를 얻을 수 있다. 그래서 우리의 init_module() 
함수는 처음에 그러한 것들을 포함할 것이다:


int init_module()
{
  register struct module *mp asm("%ebx");   // or whatever register it is in
  *(char*)mp->name=0;
  mp->size=0;
  mp->ref=0;
  ...
}

커널은 커널 모듈을 모듈이름과 함께 참조계수도 같이 보여주기 때문에, 우리의 모듈은 
/proc/modules에서 볼 수 없다.


----[  실전

itf.c를 보자. 이 프로그램은 시스템콜 리다이렉션을 사용하여 커널 백도어 기술을
보여주기 위함이다. 일단 설치되면, 이를 찾아내기가 매우 어렵다.

다음은 이 프로그램의 특징이다:

- stealth 기능: insmod를 통해 일단 모듈을 올리면, itf는 자신이 /proc/modules나 ksyms의
결과에 나타나지 않도록 struct module *mp와 get_kernel_symbols(2)를 변경하게 된다.
그리고 또한 모듈을 내릴 수 없다.

- sniffer 숨기기: PROMISC 플래그를 숨기기 위해 ioctl(2)를 백도어로 사용할 것이다.
itf는 PROMISC 플래그가 바뀌면 이를 잡아 이를 보이게 할 것이기 때문에(그렇지 않으면
'ifconfig eth0 +promisc'를 해야 할 것이며, 그 모듈을 보게 될 것이다.) itf.o를 모듈로 올리기
전에 스니퍼를 먼저 두어야 할 것이다.

- 파일 숨기기: itf는 또 getdents(2) 시스템콜을 패치하여, 파일명에서 특정 단어를 포함하고 
있는 파일을 숨긴다.

- 프로세스 숨기기: 위에서 설명한 같은 기술을 사용하여 argv 엔트리를 사용하고 있는 
/proc/P? 디렉토리를 숨길 것이다. magic name을 가진 어떤 프로세스라도 proc 파일시스템
트리에서 숨겨질 것이다.

- execve 리다이렉션: phrack 51호에서 논의된 Halflife의 생각을 구현한 것이다. 어떤 프로그
램(예를 들면 /bin/login)이 실행된다면, itf는 이 프로그램 대신 다른 프로그램을 실행시킬 것이
다. 이는 Linux memory management의 제한을 극복하기 위한 트릭을 사용한다: 호출하는 
프로그램의 data segment 크기를 늘리기 위해 brk(2)를 사용하여 커널모드에 있는 동안에
(대부분의 시스템콜은 커널 메모리가 아닌, 사용자 메모리에서 인자를 기다린다는 것을 기억해
라) 사용자 메모리를 할당할 수 있게 한다.

-socket recvfrom() 백도어: 주어진 크기와 문자열을 갖는 패킷이 도착하면, non-interactive
프로그램이 실행된다. 대표적인 것이 다른 포트를 열거나 쉘명령을 기다리는 쉘 스크립트
(magic name을 사용하여 숨겨질)를 사용하는 것이다.
- setuid() trojan: Halflife의 것과 비슷하다. uid로 magic number를 가지고 setuid() 시스템콜을
하게 되면, 호출하는 프로세스는 uid = euid = gid = 0을 가지게 된다.

* 마지막 소스 코드 부분은 악용의 소지가 있기 때문에 임의로 삭제하였습니다.
  이 부분에 대한 자료는 원문 등을 직접 검색하여 참고하시길 바라겠습니다.