OS 공부하다가 race condition이 잠깐 나오길래,
문득 해킹 기법 중 race condition이 생각나 이것저것 찾아봤다.
두개 골랐는데 비슷하다.
그리고 어렵다 =_=
뭐 쉬운개념이긴한데 중간중간 모르는게 조금씩 있다.
일단 하나는
[#M_race condition in the Unix system |숨기기|
/*------------------------------------------------*/
/* race condition in the Unix system */
/*------------------------------------------------*/
/* Written by Laks Bluesky */
/*------------------------------------------------*/
0. 프로세스와 CPU
유닉스 시스템에서 두개 이상의 프로세스가 동시에 실행
될 경우, 그 두개의 프로세스는 서로 CPU 를 차지하기
위해 CPU 를 향해 경쟁하며 달리는 형태가 되어진다.
예를 들어, 이러한 프로그램이 있다고 가정해 보자.
{
- X 를 출력
- child process를 생성
- O 를 출력
- 무한루프
}
이 프로그램을 실행시켰을 경우 이론상으로는 XOXOXOX..
식으로 모프로세스가 출력하는 X와 자프로세스가 출력하
는 O가 한번씩 번갈아 나타나야 하겠지만 실제로는 모프
로세서와 자프로세서가 CPU를 차지하기 위해 계속해서
달리는 형태가 되어 XXOOXOOXOOOXXOOOOX...와 같이 불규
칙적인 결과가 나타나게 된다. race condition은 이러한
특성을 이용하는 해킹 기법으로, 목표 프로그램과 해커
의 exploit이 서로 경쟁하게 만듦으로써 작업의 처리시
간을 가로채는 것이다. race condition은 주로 임시파일
을 생성하는 setuid 프로그램을 목표 프로그램으로 하는
데, 목표 프로그램이 임시파일을 생성하기 전에 해커의
exploit이 먼저 그 임시파일을 생성하도록 함으로써 이
루어 지는 것이다.
1. race condition 의 정의
race condition이란, 버그를 갖고 있는 setuid 프로그램
과 해커의 exploit 이 서로 경쟁(Race) 상태(Condition)
에 이르게 하여, setuid 프로그램의 권한으로 다른 파일
에 접근할 수 있게 하는 방법을 말한다. 예를 들어 한
프로그램이 root의 소유권으로 setuid가 붙어 있고, 또
이 프로그램이 작업의 성격상 임시파일을 생성한다고 할
때 해커가 그 임시파일과 같은 이름의 심볼릭 링크를 생
성해 두었다면 실제로 프로그램이 조작하는 파일은 심볼
릭 링크된 목표파일일 것이다. 보다 구체적인 예를 들어
보자.
Solaris 2.6 이하 모든 시스템에서 kcms_calibrate 라는
프로그램은 /tmp 디렉토리에 Kp_kcms_sys.semcd 라는 임
시파일을 생성하게 된다. 만약 해커가 kcms_calibrate를
실행하기 직전에 /tmp/Kp_kcms_sys.semcd 라는 이름으로
/root/.rhosts 를 목적지로 갖는 심볼릭 링크를 만든다
면 실제로 kcms_calibrate가 조작하는 파일은 심볼릭 링
크의 목표파일로 설정되어 있는 /root/.rhosts가 되는것
이다. 다행히 Solaris 에서는 /root/.rhosts를 조작하는
것만으로 root권한의 쉘을 얻을 수는 없지만 root의 권
한으로 다른 파일에 접근할 수 있다는것만으로도 충분히
보안상의 헛점이 될 수 있다.
그러면 이와같은 race condition이 이루어지기 위한 조
건을 먼저 알아보자.
2. race condition이 발생할 조건
해커가 A라는 프로그램을 대상으로 race condition을 시
도하고자 할때, A 는 다음과 같은 조건을 만족하고 있어
야 한다.
- setuid 가 붙어 있을것.
- 임시파일을 생성할 것.
- 그 임시파일의 이름을 해커가 미리 알고 있을것.
- 임시파일을 생성할때 race condition 에 대한 대처를
하지 않을것.
위의 4개의 조건이 동시에 만족될 때, 해커는 A 라는 프
로그램을 대상으로 race condition을 시도할 수 있다.
3. exploit 의 구조
race condition을 이용한 exploit을 제작할 때에 explo-
it은 최소한 다음의 기능을 가져야 한다.
{
- system() 함수 또는 exec() 함수를 이용하여 타
겟 프로그램을 백그라운드로 실행시킬것.
( 이로써 목표 프로그램과 exploit은 race condition 상
태에 놓여지게 된다. )
- symlink() 함수를 사용하여 이미 알고 있는 임시
파일의 이름으로 심볼릭 링크를 생성한다.
( 목표 프로그램이 임시파일을 생성하기 전에 미리 같은
이름의 심볼릭 링크를 생성함으로써 목표 프로그램이
조작하는 파일의 경로를 바꾸어 두는 것이다. )
}
이 exploit을 목표 프로그램에 대해 실행시켰을때 expl-
oit의 실행이 끝나기 전에는 race condition이 성공했는
지를 파악할 수 없으므로, for 문을 이용하여 여러번 반
복시켜 주는것이 성공확률을 높일 수 있다.
symlink() 함수를 이용하여 심볼릭 링크를 생성할때, 목
표파일을 존재하지 않는 파일로 지정할 경우 default u-
mask에 의해서 rwxrwxrwx의 권한을 갖는 목표파일이 생
성되어 진다. 목표 프로그램이 만일 root 소유라면, 결
국 목표파일은 root 소유로 만들어 질 것이다. 해커는
이렇게 생성된 목표파일을 이용할 수도 있다. 또는, 이
미 존재하는 파일, 예를 들어 /etc/passwd 등을 목표파
일로 지정하면 목표 프로그램이 조작하는 파일은 심볼릭
링크로 연결된 /etc/passwd 가 되는 것이다.
4. 새로운 race condition
프로그래머들은 해커들이 race condition을 이용하여 시
스템을 위협하는 것을 막기위해 다음과 같은 방법을 생
각해 냈다.
- 임시파일을 생성할 때, 그 임시파일이 이미 존재하는
파일인지 검사한다.
- 만일 이미 존재하고 있다면 exploit이 생성한 심볼릭
링크일 가능성이 있으므로, 그 파일을 지우고 새로 임
시파일을 생성한다.
하지만 해커들은 프로그래머들의 노력을 무시하듯이 더
욱 발전된 형태의 race condition을 개발함으로써 이를
무색하게 했다. 보다 발전된 형태의 race condition은
다음과 같은 구조를 갖는다.
{
- system() 함수 나 exec() 함수를 이용하여 목표
프로그램을 백그라운드로 실행시킨다.
- 임시파일이 심볼릭 링크인지 판단하여 심볼릭 링
크가 아니라면 임시파일을 지운다.
- 임시파일의 이름으로 심볼릭 링크를 생성한다.
}
다시 말해서, 목표 프로그램이 임시파일을 생성할 때,
race condition이 이루어지고 있는가를 검사한 뒤에 임
시파일을 생성한다는 점을 이용하여 일단 목표 프로그램
으로 하여금 안전한 조건을 만들어 주고 목표 프로그램
이 안전하다고 생각하며 임시파일을 생성하는 순간 생성
된 임시파일을 지우면서 심볼릭 링크를 생성하는 것이다.
이렇게 되면 목표 프로그램과 exploit 은 임시파일을 사
이에 두고 서로의 동태를 파악하며 CPU 를 향해 계속해
서 달리는 형태가 되어 그야말로 race condition 이라는
이름이 잘 걸맞게 된다.
5. 프로그래머의 대응책
프로그래머들은 기존의 방법으로는 race condition을 피
할 수 없음을 알고 또 한번 race condition에 대한 대응
을 고안해 냈다. 임시파일을 생성할 때, 일단 임시파일
을 생성한 뒤에 방금 생성한 파일이 심볼릭 링크인지를
검사하는 방법이다. 현재까지 이러한 방식의 프로그램은
race condition이 불가능한 것으로 알려져 있다.
/**************************************************/
ps. security.kaist.ac.kr 의 서의성(paladin@sparcs.ka
ist.ac.kr)님의 리포트를 참고하였습니다.
_M#]
또 하나는
[#M_Study on Race Condition|숨기기|
Study on Race Condition----------------
1. 머리말
유닉스는 멀티 유저를 지향한 매우 훌륭한 시스템이다. 여러 사람으로 하여금 정보를 공유할 수 있도록 잘 만들어져 있다. 그러면, 개인의 Privacy는 어떤 식으로 유지가 되는 것일까? 그것은 Permission, 그리고 password 등으로 가능하도록 구현해 놓았다. 그리고, 시스템 관리를 위해서 Root라는 superuser를 두어서 어떤 일이든 가능한 위치에 놓았다.
초기에 유닉스가 나타난 당시, 사용하는 유저가 그리 많지 않았고, 또한 흑심을 품은 해커도 별로 나타나지 않았으므로, 보안에 관한 관심이 별로 없었다. 그러나, 요즈음의 경우 사용자 편의를 위해 짜여진 프로그램이 거꾸로 시스템을 공격하는 무기고가 되고 있다. 일반 유저가 프로그램의 버그를 이용하여 갑자기 관리자의 권한을 지니고 권력(?)을 휘두르는 사태에 이르렀다.
해커들이 localhost에서 관리자의 권한을 잡는 방법은 여러가지가 있으나, 아직까지 크게 알려지지 않은 이 race condition을 이 문서에서 다루어 보도록 한다.
2. race condition이란?
race condition이란, 해킹조건을 뜻하는 말이 아니었다. race condition은 간단히 말해서, 두 프로세스간에 resource를 사용하기 위해서, 다투는 과정이다. 그 단적인 예를 여기에 하나 보인다.
------ race condition EXAMPLE 1 ----------------
void main(void)
{
int childpid;
int a, b;
if((childpid = fork()) > 0) { /* Parent process */
for(a = 0; a < 100; a++) printf("O");
exit(0);
}
else { /* child process */
for(b = 0; b < 100; b++) printf("X");
exit(0);
}
}
------------------------------------------------
fork()라는 함수는 동일한 작업을 하는 프로세스를 하나 더 띄우는 함수이다. fork()를 호출할 때, 그 return값은 새로 만들어진 프로세스의 번호가 되는데, 그것으로 두 프로세스를 나눌 수 있게 된다. (자세한 것은 system prog책을 참조하시오) 그러면 위에 Remark를 보인 것 처럼 원래의 프로세스는 O라는 문자를 찍게되며, 자식으로 나온 프로세스는 X를 찍는다. 물론 각각 100번을. 이때, 유닉스는 Time Sharing을 사용하므로, 프로세스 마다 시간을 각각 할당하게 되는데, 어느쪽에 시간을 더주느냐 덜주느냐가 문제가 된다.
그냥 생각하기로는 OXOXOX... 이런 식으로 나오리라 생각할 수도 있지만, 실행해보면 OOOXXOOXXXXXXOOXOXX 이런 식으로 얽혀서 주기성이 없이 나타난다. 이것이 바로 race condition이라는 것이다.
3. Symbolic Link
유닉스에는 Symbolic link라는 아주 좋은 개체가 존재한다. 일반적으로 어떤 파일을 접근하고자 할때, 그것의 Full-path를 찾아가는 일은 대단히 귀찮은 일이다. 물론 PATH라는 좋은 매체가 존재하기는 하나, 그것으로는 조금 불충분하다고 생각할 수 있다. symbolic link는 그냥 path name으로 연결해주는 매체로써, 예를 드는 것이 가장 쉬울 것으로 예상된다.
당신이 시스템내에서 /home/project/AI/SIM 이라는 디렉토리에서 연구를 한다고 하자. 당신의 login디렉토리는 /user/iam이라고 하자. 당신은 그쪽으로 연구를 하러 갈때 항상 cd /home/project/AI/SIM 과같은 방식으로 갈 수 밖에 없을 것이다. 그것도 매일같이 한다면 더욱 귀찮을 것이다. 이런 경우 symbolic link를 이용하면 매우 간단히 해결된다. 당신의 홈 디렉토리에서 'ln -s /usr/project/AI/SIM .link' 라고 입력하면, ".link"라는 링크 파일이 만들어 진다. 그러면 차후에 cd .link라고 입력하면 .link는 /home/project/AI/SIM으로 연결되어 있으므로, 자동으로 그쪽 디렉토리로 이동하게 된다. 매우 편리한 기능이다.
Symbolic link는 위와 같이 매우 편리하게 이용할 수 있으나, 위험성을 많이 내포하고 있다. 유닉스에 존재하는 일반적인 버그에 수시로 나타나는 것이 바로 이 Symbolic link인데, 왜 그런지 그 이유를 살펴보도록 한다.
예를 들어서, 어떤 프로그램이 hello라는 파일을 열어서, 그곳에 무언가를 써준다고 가정한다. 이때 만약 당신이 Permission이 된다면, hello라는 파일을 지우고나서, symbolic link로 'ln -s ~xxx/.rhosts hello' 라고 해두면 어떻게 되겠는가? 그 프로그램이 실행되면 hello라는 파일을 여는데, hello는 ~xxx/.rhosts라는 파일에 링크되어 있으므로, 그 프로그램은 ~xxx/.rhosts를 열어서 쓰게 된다. (물론 잘만 프로그램을 짜면 그런 일을 없앨 수 있다.) 이러한 단적인 예제가 elm 에 존재하는 autoreply라는 버그였는데, 그것은 setuid root되어 있고, /tmp에 arep.???? 라는 666 mode의 파일을 생성한다. 그러면, 그 생성되는 파일을 없애고(unlink), symbolic link를 /.rhosts(root의 .rhosts)로 연결시켜버린다. 그러면 실행하면서 /.rhosts라는 파일에 "+ +"정도가 들어가게 하기만 하면, 만사 OK(or BAD?)가 된다.
4. Why race condition APPEAR?
위와 같다면 왜 race condition이 등장하게 되었을까? 그냥 링크시켜서 하면 되는 것인데, 왜 프로세스 간의 resource경쟁이 나타나는가? 그것은 일종의 방어자와 공격자의 싸움에서 등장한 결과라고도 볼 수 있다.
프로그래머는 드디어 위와 같은 autoreply의 문제점을 인식하고, 새로운 방법을 모색하게 되었다. 그것은 바로 lstat()를 이용한 것으로, lstat()을 이용하여, 먼저 modify하고자 하는 파일이 Symbolic Link인지를 먼저 파악하고 그런 후에 그 파일을 open()시켜서 처리하도록 한것이다. 정말 혁신적인 방법으로, 아무런 문제가 없는 듯이 보였다. 그러나, 여기에서 race condition이 등장한다.
lstat()과 open()사이에는 분명히 갭이 존재한다. 그 갭을 적절히 이용한 것이 바로 race condition인데, 먼저 race프로그램을 background로 돌린다. race 프로그램은 돌면서, 공격하고자 하는 프로그램이 modify하는 파일을 연속해서 지우고, 링크를 만들고 하는 작업을 반복한다. 그런 후에 공격하고자 하는 프로그램을 돌린다. 그러면 어떻게 되는가?
lstat()이 이루졌을때, unlink()가 되어있고, open()될때 symbolic link가 되어 있다면, lstat()은 무용지물이 되고 만다. 그러나, 그것이 이루어 질지 안 이루어 질지는 미지수이다. 위에서 얘기한 것 처럼 프로세스는 어떻게 시간을 할당할지 전혀 알 수 없기 때문이다. 그러므로, race condition이라 불리운다.
여기까지 설명을 했으니, 여기 내가 간단히 짜놓은 예제를 보인다. 이것은 SunOS의 sendmail(/bin/mail)의 버그를 설명하는 것이다.
------- race.c --------------------------------
-------------------- race ---------------------
#include <sys/types.h>
#include <fcntl.h>
void main(void)
{
while(1) {
unlink("./tmp.file");
symlink("./.rhosts", "./tmp.file");
}
}
-----------------------------------------------
이것은 race를 위해 돌릴 프로그램이다. 공격하고자 하는 프로그램이 현재 디렉토리에 "tmp.file"이라는 이름의 파일을 변경한다고 할 때, 만들어 놓은 것이다. "tmp.file"지우고, 그후 다시 현재 디렉토리의 ".rhosts"에 링크하고하는 작업을 반복시키고 있다. 실행 파일 명은 race이다.
---- victim.c ---------------------------------
------------------------ xx -------------------
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
main()
{
struct stat buf;
char *name = "./tmp.file";
char *data = "+ +\n";
int fd;
int is_link;
int i;
if(lstat(name, &buf)) {
printf("File does not Exist.\n");
fd = open(name, O_WRONLY|O_CREAT, 0644);
write(fd, data, strlen(data));
now_ok();
close(fd);
exit(0);
}
else {
printf("File does EXIST!\n");
printf("Now This file is a ");
if((is_link = S_ISLNK(buf.st_mode)) ) printf("link\n");
if(S_ISREG(buf.st_mode) ) printf("regular file\n");
if(is_link) {
printf("THIS IS SYMBOLIC LINK. DIE MAN\n");
exit(0);
}
fd = open(name, O_WRONLY | O_APPEND);
write(fd, data, strlen(data));
now_ok();
close(fd);
exit(0);
}
}
now_ok()
{
printf("Now ok is Appended.\n");
}
--------------------------------------------
victim.c는 공격하고자 하는 프로그램의 간단한 예제이다. 꽤 길어졌는데, 그것은 그 과정을 확실히 보이기 위함이다.
이 프로그램은 시작할 때, 먼저 lstat()을 이용, 파일이 존재하는지 안하는지를 체크한다. 없으면, open에서 O_CREAT 옵션을 이용하여, 파일을 생성하고 data를 "+ +"을 넣는다. "+ +"은 유별난 데이터지만 sendmail의 경우, 마음대로 data를 바꾸어서 넣을 수 있으므로, "+ +"을 넣었다고 가정한다.
파일이 존재하면 lstat으로 부터 얻은 정보를 이용해서, symbolic link인지 아닌지를 체크한다. symbolic link이면 이 프로그램의 의도에 맞게 대응할 수 있다. 그렇게 않으면 일반 파일이므로, 내용을 추가하여 넣는다.
이제 이 두 프로그램의 race를 지켜보기 바란다. 여기 실행 결과를 Capture한 파일을 보인다.
---------- Captured File ---------------------
Script started on Wed Aug 21 02:19:24 1996
[moses:/u4/norther/seoro] 1 cat ./.rhosts
nowhere nobody
[moses:/u4/norther/seoro] 2 race &
[1] 6519
[moses:/u4/norther/seoro] 3 xx
File does EXIST!
Now This file is a link
THIS IS SYMBOLIC LINK. DIE MAN
[moses:/u4/norther/seoro] 4 xx
File does not Exist.
Now ok is Appended.
[moses:/u4/norther/seoro] 5 cat ./.rhosts
+ +
ere nobody
[moses:/u4/norther/seoro] 6 xx
File does EXIST!
Now This file is a link
THIS IS SYMBOLIC LINK. DIE MAN
[moses:/u4/norther/seoro] 7
script done on Wed Aug 21 02:20:11 1996
---------------------------------------------
자 옆에 달린 1,2,3.. 번호를 따라가본다.
1번에서 먼저 .rhosts에 들어있는 파일을 보았다. "nowhere nobody"라는 데이터가 들어 있다.
2번에서 race &로 돌려 background로 계속해서 tmp.data를 지웠다가 링크하는 과정을 반복하고 있다.
드디어 3번에서 목표 프로그램을 실행해본다. 파일이 존재하며, 그것이 symbolic link임이 드러난다. 이것은 race할때, unlink()하여, 파일을 없앤 순간이 아니라, symbolic link를 연결한 순간에 lstat()에 걸려서 나타난 현상이다.
4번에서 다시 시도한다. 이번에는 파일이 없으며, 내용을 넣는다고 나타났다.
5번에서 .rhosts내용을 확인해본 결과, 아닌게 아니라 "+ +"메시지가 들어가있다.
6번에서 한번 더 해보았지만 실패하고 만다.
매우 확실한 예제로 이정도면 race가 왜 등장하게 되었는지 알 수 있으리라고 생각한다. 이제 실제 예로 몇가지 예를 설명한다.
5. Some Examples
[1] SunOS sendmail(/bin/mail)
SunOS의 sendmail은 외부로 부터 온 메일을 받아서 그것을 /var/spool/mail/$USER 위치에 넣는다. $USER라는 표기는 그냥 온 유저에 맞도록 넣는다는 의미이다. 문제는 그 유저의 permission으로 넣어주기 위해서(chown) Root권한으로 프로그램이 돌아간다는 사실이다. /var/spool/mail의 디렉토리가 777로 열려있다고 가정한다. 이때, /etc/passwd에는 entry가 존재하고, /var/spool/mail에는 아직 존재하지 않는 유저가 있다고 생각해보자. ftp, sundiag등 mail이 날아올 일이 없는 id가 분명히 있을 것이다. 이런 경우 race condition으로 시스템에 구멍이 생긴다.
ftp를 지목하였다고 하자. race 프로그램을 만든다. 그것은 /var/spool/mail/ftp를 지웠다가 그 파일을 'ln -s /.rhosts /var/spool/mail/ftp'로 링크하는 것을 반복하는 것이라고 생각한다. 이제 race프로그램을 돌린다. 그런 후에, ftp로 아주 적절한 data를 넣어서 메일을 보낸다. 그러면 어떻게 되는가?
sendmail은 4장에서 소개한 방법으로 Symbolic link를 판별한다. 그러므로, 확률이 반반정도로 위의 예처럼 잘 걸린 경우 그 내용이 /.rhosts에 들어가든지 unlink()되어 파일이 없었던 경우라면, ftp라는 파일이 생성되고 결말이 날 것이다.
[2] Solaris 2.x ps(/usr/bin/ps)
여기부터는 간략히 그 메카니즘만을 설명하기로 한다. Solaris 2.x에 있는 ps는 /tmp 디렉토리에 임시파일을 만들고, 그 파일에 내용을 쓴 다음 chown()을 이용하여, 권한을 바꾸고 마지막으로 그것을 /tmp/ps_data라는 파일로 rename시켜준다.
이것은 어떤 방법으로 race condition이 가능한가?
이번의 race프로그램은 약간 신경을 써서 만들어야 한다. 임시로 만들어지는 파일의 이름이 무엇인지 알지 못하므로, 이런 경우에는 race프로그램에서 계속해서 /tmp디렉토리를 search해가면서 나타나는 파일마다 race를 걸어주어야 하게 된다. search하면서 파일이 나타나면, 그것을 unlink()시키고, 그다음 그것을 우리가 원하는 파일에 링크한다. 그 후 그 파일을 chown()시키므로, 우리가 원하는 파일의 permission이 바뀌게 된다.
[3] Misc
/usr/ucb/lpr 임시 파일이 1000을 주기로 이름이 반복된다.
lpr -q -s 옵션을 이용 원하는 파일에 symbolic link가능
/bin/passwd -F 패스워드 변경시 /etc/ptmp라는 파일을 생성, 내용을
바꾼후에, /etc/passwd에 overwrite시킨다.
/usr/lib/sendmail 보낸 user가 존재하지 않는 경우, /var/tmp/dead.letter에
Guessing가능한 파일이 생성된다.
6. 대책
race condition, 또는 symbolic link에 의한 대책은 여러가지가 있을 수 있다.
첫째, 가능한한 임시 파일을 만들지 않는 것이다.
요즈음 시스템이 비대해지면서, 어느정도는 메모리 내에서 처리가 가능하다. 굳이 임시 파일을 만드는 것은 race condition의 원인이 된다.
둘째, unlink()를 불가능하게 한다.
unlink()를 시키지 못하면, symbolic link가 만들어 지는 것은 불가능하다. 위의 Solaris의 ps버그는 /tmp가 0777모드로 다른 유저가 /tmp의 파일을 modify가능하기에 나타난 버그이다. 이런 경우 /tmp를 1777로 sticky를 붙이게 되면, unlink()가 불가능해진다.
셋째, creat()와 open()의 구분을 확실히 한다.
이것은 /bin/mail의 경우 확연한 것으로 만들고자 하는 파일을 계속 지웠다가 링크를 만들었다가 하므로, 결국 공격을 당할 시에는 두가지 경우만이 존재한다. symbolic link이거나, 정말로 존재하지 않거나 두가지이다. 그러므로, lstat()에서 파일이 존재하지 않은 것으로 판명된 경우는 open()시킬 때, 옵션을 O_WRONLY|O_CREAT으로 주는 것이 아니라, 여기에 O_EXCL을 첨가하여, 만일 어떤 식으로든 파일이 존재하는 경우, 파일 생성 또는 쓰기를 포기하게 하는 것이다.
넷째, umask를 최하 022정도 유지한다.
파일이 생성되는 경우, 기본 permission이 666으로 누구나 와서 쓸 수 있다. 이에 umask를 이용하면, permission이 mask되어 나와서, 다른 유저의 write permission을 없애준다.
그외에도 많이 있을 수 있겠으나, 이정도로 간단히 정리하도록 한다.
7. 결론
이하 race condition에 대해서 다루었다. UNIX시스템에서 이렇듯 시스템 프로그램에 얼마든지 버그가 존재할 수 있으며, 여기에 대해 적극 대처하는 것이 필요하다.
여기까지 race conditon을 일단(!)마치고, 점차적으로 내용을 늘려나가기로 한다.
_M#]
요새는 거의 통하지 않는다는 기법.
아마 막힌지 꽤 오래되었을거다.
한번 실제 해보면 재미있을 듯.
전에 해커스쿨 풀 때 요거 이용한게 있었던것 같기도 한데 =_=a
다 까먹었다;
문득 해킹 기법 중 race condition이 생각나 이것저것 찾아봤다.
두개 골랐는데 비슷하다.
그리고 어렵다 =_=
뭐 쉬운개념이긴한데 중간중간 모르는게 조금씩 있다.
일단 하나는
[#M_race condition in the Unix system |숨기기|
/*------------------------------------------------*/
/* race condition in the Unix system */
/*------------------------------------------------*/
/* Written by Laks Bluesky */
/*------------------------------------------------*/
0. 프로세스와 CPU
유닉스 시스템에서 두개 이상의 프로세스가 동시에 실행
될 경우, 그 두개의 프로세스는 서로 CPU 를 차지하기
위해 CPU 를 향해 경쟁하며 달리는 형태가 되어진다.
예를 들어, 이러한 프로그램이 있다고 가정해 보자.
{
- X 를 출력
- child process를 생성
- O 를 출력
- 무한루프
}
이 프로그램을 실행시켰을 경우 이론상으로는 XOXOXOX..
식으로 모프로세스가 출력하는 X와 자프로세스가 출력하
는 O가 한번씩 번갈아 나타나야 하겠지만 실제로는 모프
로세서와 자프로세서가 CPU를 차지하기 위해 계속해서
달리는 형태가 되어 XXOOXOOXOOOXXOOOOX...와 같이 불규
칙적인 결과가 나타나게 된다. race condition은 이러한
특성을 이용하는 해킹 기법으로, 목표 프로그램과 해커
의 exploit이 서로 경쟁하게 만듦으로써 작업의 처리시
간을 가로채는 것이다. race condition은 주로 임시파일
을 생성하는 setuid 프로그램을 목표 프로그램으로 하는
데, 목표 프로그램이 임시파일을 생성하기 전에 해커의
exploit이 먼저 그 임시파일을 생성하도록 함으로써 이
루어 지는 것이다.
1. race condition 의 정의
race condition이란, 버그를 갖고 있는 setuid 프로그램
과 해커의 exploit 이 서로 경쟁(Race) 상태(Condition)
에 이르게 하여, setuid 프로그램의 권한으로 다른 파일
에 접근할 수 있게 하는 방법을 말한다. 예를 들어 한
프로그램이 root의 소유권으로 setuid가 붙어 있고, 또
이 프로그램이 작업의 성격상 임시파일을 생성한다고 할
때 해커가 그 임시파일과 같은 이름의 심볼릭 링크를 생
성해 두었다면 실제로 프로그램이 조작하는 파일은 심볼
릭 링크된 목표파일일 것이다. 보다 구체적인 예를 들어
보자.
Solaris 2.6 이하 모든 시스템에서 kcms_calibrate 라는
프로그램은 /tmp 디렉토리에 Kp_kcms_sys.semcd 라는 임
시파일을 생성하게 된다. 만약 해커가 kcms_calibrate를
실행하기 직전에 /tmp/Kp_kcms_sys.semcd 라는 이름으로
/root/.rhosts 를 목적지로 갖는 심볼릭 링크를 만든다
면 실제로 kcms_calibrate가 조작하는 파일은 심볼릭 링
크의 목표파일로 설정되어 있는 /root/.rhosts가 되는것
이다. 다행히 Solaris 에서는 /root/.rhosts를 조작하는
것만으로 root권한의 쉘을 얻을 수는 없지만 root의 권
한으로 다른 파일에 접근할 수 있다는것만으로도 충분히
보안상의 헛점이 될 수 있다.
그러면 이와같은 race condition이 이루어지기 위한 조
건을 먼저 알아보자.
2. race condition이 발생할 조건
해커가 A라는 프로그램을 대상으로 race condition을 시
도하고자 할때, A 는 다음과 같은 조건을 만족하고 있어
야 한다.
- setuid 가 붙어 있을것.
- 임시파일을 생성할 것.
- 그 임시파일의 이름을 해커가 미리 알고 있을것.
- 임시파일을 생성할때 race condition 에 대한 대처를
하지 않을것.
위의 4개의 조건이 동시에 만족될 때, 해커는 A 라는 프
로그램을 대상으로 race condition을 시도할 수 있다.
3. exploit 의 구조
race condition을 이용한 exploit을 제작할 때에 explo-
it은 최소한 다음의 기능을 가져야 한다.
{
- system() 함수 또는 exec() 함수를 이용하여 타
겟 프로그램을 백그라운드로 실행시킬것.
( 이로써 목표 프로그램과 exploit은 race condition 상
태에 놓여지게 된다. )
- symlink() 함수를 사용하여 이미 알고 있는 임시
파일의 이름으로 심볼릭 링크를 생성한다.
( 목표 프로그램이 임시파일을 생성하기 전에 미리 같은
이름의 심볼릭 링크를 생성함으로써 목표 프로그램이
조작하는 파일의 경로를 바꾸어 두는 것이다. )
}
이 exploit을 목표 프로그램에 대해 실행시켰을때 expl-
oit의 실행이 끝나기 전에는 race condition이 성공했는
지를 파악할 수 없으므로, for 문을 이용하여 여러번 반
복시켜 주는것이 성공확률을 높일 수 있다.
symlink() 함수를 이용하여 심볼릭 링크를 생성할때, 목
표파일을 존재하지 않는 파일로 지정할 경우 default u-
mask에 의해서 rwxrwxrwx의 권한을 갖는 목표파일이 생
성되어 진다. 목표 프로그램이 만일 root 소유라면, 결
국 목표파일은 root 소유로 만들어 질 것이다. 해커는
이렇게 생성된 목표파일을 이용할 수도 있다. 또는, 이
미 존재하는 파일, 예를 들어 /etc/passwd 등을 목표파
일로 지정하면 목표 프로그램이 조작하는 파일은 심볼릭
링크로 연결된 /etc/passwd 가 되는 것이다.
4. 새로운 race condition
프로그래머들은 해커들이 race condition을 이용하여 시
스템을 위협하는 것을 막기위해 다음과 같은 방법을 생
각해 냈다.
- 임시파일을 생성할 때, 그 임시파일이 이미 존재하는
파일인지 검사한다.
- 만일 이미 존재하고 있다면 exploit이 생성한 심볼릭
링크일 가능성이 있으므로, 그 파일을 지우고 새로 임
시파일을 생성한다.
하지만 해커들은 프로그래머들의 노력을 무시하듯이 더
욱 발전된 형태의 race condition을 개발함으로써 이를
무색하게 했다. 보다 발전된 형태의 race condition은
다음과 같은 구조를 갖는다.
{
- system() 함수 나 exec() 함수를 이용하여 목표
프로그램을 백그라운드로 실행시킨다.
- 임시파일이 심볼릭 링크인지 판단하여 심볼릭 링
크가 아니라면 임시파일을 지운다.
- 임시파일의 이름으로 심볼릭 링크를 생성한다.
}
다시 말해서, 목표 프로그램이 임시파일을 생성할 때,
race condition이 이루어지고 있는가를 검사한 뒤에 임
시파일을 생성한다는 점을 이용하여 일단 목표 프로그램
으로 하여금 안전한 조건을 만들어 주고 목표 프로그램
이 안전하다고 생각하며 임시파일을 생성하는 순간 생성
된 임시파일을 지우면서 심볼릭 링크를 생성하는 것이다.
이렇게 되면 목표 프로그램과 exploit 은 임시파일을 사
이에 두고 서로의 동태를 파악하며 CPU 를 향해 계속해
서 달리는 형태가 되어 그야말로 race condition 이라는
이름이 잘 걸맞게 된다.
5. 프로그래머의 대응책
프로그래머들은 기존의 방법으로는 race condition을 피
할 수 없음을 알고 또 한번 race condition에 대한 대응
을 고안해 냈다. 임시파일을 생성할 때, 일단 임시파일
을 생성한 뒤에 방금 생성한 파일이 심볼릭 링크인지를
검사하는 방법이다. 현재까지 이러한 방식의 프로그램은
race condition이 불가능한 것으로 알려져 있다.
/**************************************************/
ps. security.kaist.ac.kr 의 서의성(paladin@sparcs.ka
ist.ac.kr)님의 리포트를 참고하였습니다.
_M#]
또 하나는
[#M_Study on Race Condition|숨기기|
Study on Race Condition----------------
1. 머리말
유닉스는 멀티 유저를 지향한 매우 훌륭한 시스템이다. 여러 사람으로 하여금 정보를 공유할 수 있도록 잘 만들어져 있다. 그러면, 개인의 Privacy는 어떤 식으로 유지가 되는 것일까? 그것은 Permission, 그리고 password 등으로 가능하도록 구현해 놓았다. 그리고, 시스템 관리를 위해서 Root라는 superuser를 두어서 어떤 일이든 가능한 위치에 놓았다.
초기에 유닉스가 나타난 당시, 사용하는 유저가 그리 많지 않았고, 또한 흑심을 품은 해커도 별로 나타나지 않았으므로, 보안에 관한 관심이 별로 없었다. 그러나, 요즈음의 경우 사용자 편의를 위해 짜여진 프로그램이 거꾸로 시스템을 공격하는 무기고가 되고 있다. 일반 유저가 프로그램의 버그를 이용하여 갑자기 관리자의 권한을 지니고 권력(?)을 휘두르는 사태에 이르렀다.
해커들이 localhost에서 관리자의 권한을 잡는 방법은 여러가지가 있으나, 아직까지 크게 알려지지 않은 이 race condition을 이 문서에서 다루어 보도록 한다.
2. race condition이란?
race condition이란, 해킹조건을 뜻하는 말이 아니었다. race condition은 간단히 말해서, 두 프로세스간에 resource를 사용하기 위해서, 다투는 과정이다. 그 단적인 예를 여기에 하나 보인다.
------ race condition EXAMPLE 1 ----------------
void main(void)
{
int childpid;
int a, b;
if((childpid = fork()) > 0) { /* Parent process */
for(a = 0; a < 100; a++) printf("O");
exit(0);
}
else { /* child process */
for(b = 0; b < 100; b++) printf("X");
exit(0);
}
}
------------------------------------------------
fork()라는 함수는 동일한 작업을 하는 프로세스를 하나 더 띄우는 함수이다. fork()를 호출할 때, 그 return값은 새로 만들어진 프로세스의 번호가 되는데, 그것으로 두 프로세스를 나눌 수 있게 된다. (자세한 것은 system prog책을 참조하시오) 그러면 위에 Remark를 보인 것 처럼 원래의 프로세스는 O라는 문자를 찍게되며, 자식으로 나온 프로세스는 X를 찍는다. 물론 각각 100번을. 이때, 유닉스는 Time Sharing을 사용하므로, 프로세스 마다 시간을 각각 할당하게 되는데, 어느쪽에 시간을 더주느냐 덜주느냐가 문제가 된다.
그냥 생각하기로는 OXOXOX... 이런 식으로 나오리라 생각할 수도 있지만, 실행해보면 OOOXXOOXXXXXXOOXOXX 이런 식으로 얽혀서 주기성이 없이 나타난다. 이것이 바로 race condition이라는 것이다.
3. Symbolic Link
유닉스에는 Symbolic link라는 아주 좋은 개체가 존재한다. 일반적으로 어떤 파일을 접근하고자 할때, 그것의 Full-path를 찾아가는 일은 대단히 귀찮은 일이다. 물론 PATH라는 좋은 매체가 존재하기는 하나, 그것으로는 조금 불충분하다고 생각할 수 있다. symbolic link는 그냥 path name으로 연결해주는 매체로써, 예를 드는 것이 가장 쉬울 것으로 예상된다.
당신이 시스템내에서 /home/project/AI/SIM 이라는 디렉토리에서 연구를 한다고 하자. 당신의 login디렉토리는 /user/iam이라고 하자. 당신은 그쪽으로 연구를 하러 갈때 항상 cd /home/project/AI/SIM 과같은 방식으로 갈 수 밖에 없을 것이다. 그것도 매일같이 한다면 더욱 귀찮을 것이다. 이런 경우 symbolic link를 이용하면 매우 간단히 해결된다. 당신의 홈 디렉토리에서 'ln -s /usr/project/AI/SIM .link' 라고 입력하면, ".link"라는 링크 파일이 만들어 진다. 그러면 차후에 cd .link라고 입력하면 .link는 /home/project/AI/SIM으로 연결되어 있으므로, 자동으로 그쪽 디렉토리로 이동하게 된다. 매우 편리한 기능이다.
Symbolic link는 위와 같이 매우 편리하게 이용할 수 있으나, 위험성을 많이 내포하고 있다. 유닉스에 존재하는 일반적인 버그에 수시로 나타나는 것이 바로 이 Symbolic link인데, 왜 그런지 그 이유를 살펴보도록 한다.
예를 들어서, 어떤 프로그램이 hello라는 파일을 열어서, 그곳에 무언가를 써준다고 가정한다. 이때 만약 당신이 Permission이 된다면, hello라는 파일을 지우고나서, symbolic link로 'ln -s ~xxx/.rhosts hello' 라고 해두면 어떻게 되겠는가? 그 프로그램이 실행되면 hello라는 파일을 여는데, hello는 ~xxx/.rhosts라는 파일에 링크되어 있으므로, 그 프로그램은 ~xxx/.rhosts를 열어서 쓰게 된다. (물론 잘만 프로그램을 짜면 그런 일을 없앨 수 있다.) 이러한 단적인 예제가 elm 에 존재하는 autoreply라는 버그였는데, 그것은 setuid root되어 있고, /tmp에 arep.???? 라는 666 mode의 파일을 생성한다. 그러면, 그 생성되는 파일을 없애고(unlink), symbolic link를 /.rhosts(root의 .rhosts)로 연결시켜버린다. 그러면 실행하면서 /.rhosts라는 파일에 "+ +"정도가 들어가게 하기만 하면, 만사 OK(or BAD?)가 된다.
4. Why race condition APPEAR?
위와 같다면 왜 race condition이 등장하게 되었을까? 그냥 링크시켜서 하면 되는 것인데, 왜 프로세스 간의 resource경쟁이 나타나는가? 그것은 일종의 방어자와 공격자의 싸움에서 등장한 결과라고도 볼 수 있다.
프로그래머는 드디어 위와 같은 autoreply의 문제점을 인식하고, 새로운 방법을 모색하게 되었다. 그것은 바로 lstat()를 이용한 것으로, lstat()을 이용하여, 먼저 modify하고자 하는 파일이 Symbolic Link인지를 먼저 파악하고 그런 후에 그 파일을 open()시켜서 처리하도록 한것이다. 정말 혁신적인 방법으로, 아무런 문제가 없는 듯이 보였다. 그러나, 여기에서 race condition이 등장한다.
lstat()과 open()사이에는 분명히 갭이 존재한다. 그 갭을 적절히 이용한 것이 바로 race condition인데, 먼저 race프로그램을 background로 돌린다. race 프로그램은 돌면서, 공격하고자 하는 프로그램이 modify하는 파일을 연속해서 지우고, 링크를 만들고 하는 작업을 반복한다. 그런 후에 공격하고자 하는 프로그램을 돌린다. 그러면 어떻게 되는가?
lstat()이 이루졌을때, unlink()가 되어있고, open()될때 symbolic link가 되어 있다면, lstat()은 무용지물이 되고 만다. 그러나, 그것이 이루어 질지 안 이루어 질지는 미지수이다. 위에서 얘기한 것 처럼 프로세스는 어떻게 시간을 할당할지 전혀 알 수 없기 때문이다. 그러므로, race condition이라 불리운다.
여기까지 설명을 했으니, 여기 내가 간단히 짜놓은 예제를 보인다. 이것은 SunOS의 sendmail(/bin/mail)의 버그를 설명하는 것이다.
------- race.c --------------------------------
-------------------- race ---------------------
#include <sys/types.h>
#include <fcntl.h>
void main(void)
{
while(1) {
unlink("./tmp.file");
symlink("./.rhosts", "./tmp.file");
}
}
-----------------------------------------------
이것은 race를 위해 돌릴 프로그램이다. 공격하고자 하는 프로그램이 현재 디렉토리에 "tmp.file"이라는 이름의 파일을 변경한다고 할 때, 만들어 놓은 것이다. "tmp.file"지우고, 그후 다시 현재 디렉토리의 ".rhosts"에 링크하고하는 작업을 반복시키고 있다. 실행 파일 명은 race이다.
---- victim.c ---------------------------------
------------------------ xx -------------------
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
main()
{
struct stat buf;
char *name = "./tmp.file";
char *data = "+ +\n";
int fd;
int is_link;
int i;
if(lstat(name, &buf)) {
printf("File does not Exist.\n");
fd = open(name, O_WRONLY|O_CREAT, 0644);
write(fd, data, strlen(data));
now_ok();
close(fd);
exit(0);
}
else {
printf("File does EXIST!\n");
printf("Now This file is a ");
if((is_link = S_ISLNK(buf.st_mode)) ) printf("link\n");
if(S_ISREG(buf.st_mode) ) printf("regular file\n");
if(is_link) {
printf("THIS IS SYMBOLIC LINK. DIE MAN\n");
exit(0);
}
fd = open(name, O_WRONLY | O_APPEND);
write(fd, data, strlen(data));
now_ok();
close(fd);
exit(0);
}
}
now_ok()
{
printf("Now ok is Appended.\n");
}
--------------------------------------------
victim.c는 공격하고자 하는 프로그램의 간단한 예제이다. 꽤 길어졌는데, 그것은 그 과정을 확실히 보이기 위함이다.
이 프로그램은 시작할 때, 먼저 lstat()을 이용, 파일이 존재하는지 안하는지를 체크한다. 없으면, open에서 O_CREAT 옵션을 이용하여, 파일을 생성하고 data를 "+ +"을 넣는다. "+ +"은 유별난 데이터지만 sendmail의 경우, 마음대로 data를 바꾸어서 넣을 수 있으므로, "+ +"을 넣었다고 가정한다.
파일이 존재하면 lstat으로 부터 얻은 정보를 이용해서, symbolic link인지 아닌지를 체크한다. symbolic link이면 이 프로그램의 의도에 맞게 대응할 수 있다. 그렇게 않으면 일반 파일이므로, 내용을 추가하여 넣는다.
이제 이 두 프로그램의 race를 지켜보기 바란다. 여기 실행 결과를 Capture한 파일을 보인다.
---------- Captured File ---------------------
Script started on Wed Aug 21 02:19:24 1996
[moses:/u4/norther/seoro] 1 cat ./.rhosts
nowhere nobody
[moses:/u4/norther/seoro] 2 race &
[1] 6519
[moses:/u4/norther/seoro] 3 xx
File does EXIST!
Now This file is a link
THIS IS SYMBOLIC LINK. DIE MAN
[moses:/u4/norther/seoro] 4 xx
File does not Exist.
Now ok is Appended.
[moses:/u4/norther/seoro] 5 cat ./.rhosts
+ +
ere nobody
[moses:/u4/norther/seoro] 6 xx
File does EXIST!
Now This file is a link
THIS IS SYMBOLIC LINK. DIE MAN
[moses:/u4/norther/seoro] 7
script done on Wed Aug 21 02:20:11 1996
---------------------------------------------
자 옆에 달린 1,2,3.. 번호를 따라가본다.
1번에서 먼저 .rhosts에 들어있는 파일을 보았다. "nowhere nobody"라는 데이터가 들어 있다.
2번에서 race &로 돌려 background로 계속해서 tmp.data를 지웠다가 링크하는 과정을 반복하고 있다.
드디어 3번에서 목표 프로그램을 실행해본다. 파일이 존재하며, 그것이 symbolic link임이 드러난다. 이것은 race할때, unlink()하여, 파일을 없앤 순간이 아니라, symbolic link를 연결한 순간에 lstat()에 걸려서 나타난 현상이다.
4번에서 다시 시도한다. 이번에는 파일이 없으며, 내용을 넣는다고 나타났다.
5번에서 .rhosts내용을 확인해본 결과, 아닌게 아니라 "+ +"메시지가 들어가있다.
6번에서 한번 더 해보았지만 실패하고 만다.
매우 확실한 예제로 이정도면 race가 왜 등장하게 되었는지 알 수 있으리라고 생각한다. 이제 실제 예로 몇가지 예를 설명한다.
5. Some Examples
[1] SunOS sendmail(/bin/mail)
SunOS의 sendmail은 외부로 부터 온 메일을 받아서 그것을 /var/spool/mail/$USER 위치에 넣는다. $USER라는 표기는 그냥 온 유저에 맞도록 넣는다는 의미이다. 문제는 그 유저의 permission으로 넣어주기 위해서(chown) Root권한으로 프로그램이 돌아간다는 사실이다. /var/spool/mail의 디렉토리가 777로 열려있다고 가정한다. 이때, /etc/passwd에는 entry가 존재하고, /var/spool/mail에는 아직 존재하지 않는 유저가 있다고 생각해보자. ftp, sundiag등 mail이 날아올 일이 없는 id가 분명히 있을 것이다. 이런 경우 race condition으로 시스템에 구멍이 생긴다.
ftp를 지목하였다고 하자. race 프로그램을 만든다. 그것은 /var/spool/mail/ftp를 지웠다가 그 파일을 'ln -s /.rhosts /var/spool/mail/ftp'로 링크하는 것을 반복하는 것이라고 생각한다. 이제 race프로그램을 돌린다. 그런 후에, ftp로 아주 적절한 data를 넣어서 메일을 보낸다. 그러면 어떻게 되는가?
sendmail은 4장에서 소개한 방법으로 Symbolic link를 판별한다. 그러므로, 확률이 반반정도로 위의 예처럼 잘 걸린 경우 그 내용이 /.rhosts에 들어가든지 unlink()되어 파일이 없었던 경우라면, ftp라는 파일이 생성되고 결말이 날 것이다.
[2] Solaris 2.x ps(/usr/bin/ps)
여기부터는 간략히 그 메카니즘만을 설명하기로 한다. Solaris 2.x에 있는 ps는 /tmp 디렉토리에 임시파일을 만들고, 그 파일에 내용을 쓴 다음 chown()을 이용하여, 권한을 바꾸고 마지막으로 그것을 /tmp/ps_data라는 파일로 rename시켜준다.
이것은 어떤 방법으로 race condition이 가능한가?
이번의 race프로그램은 약간 신경을 써서 만들어야 한다. 임시로 만들어지는 파일의 이름이 무엇인지 알지 못하므로, 이런 경우에는 race프로그램에서 계속해서 /tmp디렉토리를 search해가면서 나타나는 파일마다 race를 걸어주어야 하게 된다. search하면서 파일이 나타나면, 그것을 unlink()시키고, 그다음 그것을 우리가 원하는 파일에 링크한다. 그 후 그 파일을 chown()시키므로, 우리가 원하는 파일의 permission이 바뀌게 된다.
[3] Misc
/usr/ucb/lpr 임시 파일이 1000을 주기로 이름이 반복된다.
lpr -q -s 옵션을 이용 원하는 파일에 symbolic link가능
/bin/passwd -F 패스워드 변경시 /etc/ptmp라는 파일을 생성, 내용을
바꾼후에, /etc/passwd에 overwrite시킨다.
/usr/lib/sendmail 보낸 user가 존재하지 않는 경우, /var/tmp/dead.letter에
Guessing가능한 파일이 생성된다.
6. 대책
race condition, 또는 symbolic link에 의한 대책은 여러가지가 있을 수 있다.
첫째, 가능한한 임시 파일을 만들지 않는 것이다.
요즈음 시스템이 비대해지면서, 어느정도는 메모리 내에서 처리가 가능하다. 굳이 임시 파일을 만드는 것은 race condition의 원인이 된다.
둘째, unlink()를 불가능하게 한다.
unlink()를 시키지 못하면, symbolic link가 만들어 지는 것은 불가능하다. 위의 Solaris의 ps버그는 /tmp가 0777모드로 다른 유저가 /tmp의 파일을 modify가능하기에 나타난 버그이다. 이런 경우 /tmp를 1777로 sticky를 붙이게 되면, unlink()가 불가능해진다.
셋째, creat()와 open()의 구분을 확실히 한다.
이것은 /bin/mail의 경우 확연한 것으로 만들고자 하는 파일을 계속 지웠다가 링크를 만들었다가 하므로, 결국 공격을 당할 시에는 두가지 경우만이 존재한다. symbolic link이거나, 정말로 존재하지 않거나 두가지이다. 그러므로, lstat()에서 파일이 존재하지 않은 것으로 판명된 경우는 open()시킬 때, 옵션을 O_WRONLY|O_CREAT으로 주는 것이 아니라, 여기에 O_EXCL을 첨가하여, 만일 어떤 식으로든 파일이 존재하는 경우, 파일 생성 또는 쓰기를 포기하게 하는 것이다.
넷째, umask를 최하 022정도 유지한다.
파일이 생성되는 경우, 기본 permission이 666으로 누구나 와서 쓸 수 있다. 이에 umask를 이용하면, permission이 mask되어 나와서, 다른 유저의 write permission을 없애준다.
그외에도 많이 있을 수 있겠으나, 이정도로 간단히 정리하도록 한다.
7. 결론
이하 race condition에 대해서 다루었다. UNIX시스템에서 이렇듯 시스템 프로그램에 얼마든지 버그가 존재할 수 있으며, 여기에 대해 적극 대처하는 것이 필요하다.
여기까지 race conditon을 일단(!)마치고, 점차적으로 내용을 늘려나가기로 한다.
_M#]
요새는 거의 통하지 않는다는 기법.
아마 막힌지 꽤 오래되었을거다.
한번 실제 해보면 재미있을 듯.
전에 해커스쿨 풀 때 요거 이용한게 있었던것 같기도 한데 =_=a
다 까먹었다;
댓글을 달아 주세요