[질문]setuid 로 설정된 /bin/sh 실행에 대하여
글쓴이: nidle / 작성시간: 수, 2006/04/05 - 9:03오후
안녕하세요 제가 setuid를 공부하다 이상한점이 있어서 이렇게 글올립니다.
제가 사용하는 리눅스는 페도라4를사용하고 있습니다
[hmpark@linux80 ~]$ whoami hmpark [hmpark@linux80 ~]$ ls -la /bin/sh -rwsr-xr-x 1 root root 378024 10월 8 1999 /bin/sh* [hmpark@linux80 ~]$ /bin/sh [hmpark@linux80 hmpark]# id uid=504(hmpark) gid=504(hmpark) euid=0(root) groups=504(hmpark) [hmpark@linux80 hmpark]# whoami root
위에처럼 하면 root권한이 된다고 하는데 직접해보닌 안됬습니다.
이내용이 지금도 맞는건가요.
/bin/sh에대한 권한설정은
root계정으로 chmod +s /bin/sh 도 해보구
chmod +s /bin/bash 위에예처럼 똑같이 4755해봤습니다.
책과 여러 검색으로만봤을때는 이해했는데 이렇게 직접몇가지 해보니 또 헷갈리네요 ^^
좀더 추가해서 /bin/sh -p 옵션을 주었을경우
whoami로 봤을때
root로 나옵니다
id로 봤을때는 euid=0(root)로 더나왔습니다. 그러나 실제 root권한은 없네요 권한이 없는 문서를 읽을수 있으나 수정불가였습니다
어느정도의 root권한을 주지만 완전한 root권한이 아니었습니다.
Forums:
좀 복잡합니다.
실제 setuid,setgid로 인해 바뀌는 것은 euid, egid입니다.
uid, gid값은 setuid,setgid 비트로 인해 변하지는 않습니다.
euid가 Effective UID일 것이고 uid는 Real UID입니다.(GID도 마찬가지)
즉 님이 설정하신 대로 setuid에 의해 euid가 root인 sh 프로세스가 생성됩니다.
예를 들어 그 sh 프로세스로 vi를 실행시켜 /etc/shadow를 읽으려 한다 해봅시다.(# vi /etc/shadow)
(섀도우 패스워드를 쓰시면 아시겠지만 shadow 파일은 root 소유이고 권한은 rw-------일 겁니다. 확실치는 않지만...)
sh 프로세스 같은 caller를 A 프로세스, vi 같은 callee를 B 프로세스라 합시다.
현재 A 프로세스 euid는 root, uid는 hmpark입니다. 이제 B 프로세스를 실행하려 합니다.
여기서 따져주어야 할 점 2가지가 있습니다.
1. euid, egid는 접근 권한에만 관여합니다.(일반적으로 euid=uid)
2. 최근 커널은 새 프로세스 생성시 이 프로세스의 euid를 real uid로 바꿔버립니다.(보안상 이유 때문)
이 말이 무엇이냐 하면 다음과 같습니다.
1. A 프로세스(euid root, uid hmpark)에서 B 프로세스를 실행시키는 것은 문제가 없습니다. B 프로세스를 root가 실행시킬 수만 있다면 당근 프로세스는 생성됩니다.
2. 이 과정에서 커널은 B 프로세스의 uid를 보고 euid를 같게 변경시켜버립니다.(B 프로세스는 이제 euid hmpark,uid hmpark)
3. B 프로세스에서 root 파일을 읽으려 하면(vi에서 /etc/shadow 파일을 열려고 하면) euid가 hmpark이므로 권한 에러가 발생합니다.
따라서 새 프로세스인 B에서 권한을 뺏기므로 파일이 안 열린 겁니다.
그럼 무조건 안되는 것은 아니구요... real uid마저 임시로 바꾸는 법이 있습니다.
man setreuid하시면 나오구요... 예제를 들어봅니다.
int main() { setreuid(0,0); //uid 0값은 root인거 아시죠? system("/bin/sh"); return 0; }예를 들어본 겁니다.
A 프로세스가 /bin/sh가 아니라 이 프로그램이라고 치면 다음 순서로 일이 진행됩니다.
1. A 프로세스 : euid root, uid hmpark
2. setreuid에 의해 euid root,uid root
3. 이 상태로 /bin/sh 실행(마치 root가 실행하는 것처럼 됨)
4. 커널은 euid를 uid값으로 바꿉니다(euid root, uid root!!!!!!)
5. 완벽한 루트쉘 탄생!
6. sh가 종료되면(exit) 이 프로그램도 종료되면서 setreuid의 효력이 상실되고, 원래 상태(euid hmpark, uid hmpark)로 돌아옵니다.
이해가 되시는가요? 저도 확실치는 않지만 해커스쿨의 기억을 되살려-_- 음하하
실제 리눅스 시스템 해킹을 할때 이러한 최근 리눅스 커널(아마 2.4 버전대 이상?)의 특징을 고려합니다.
따라서 setuid/setgid가 된 취약한 프로그램 공략시(Code Execution Vulnerability의 경우) 반드시 setreuid가 실행되도록 합니다.
Shellcode에 반영하는 것도 있고, OMEGA의 경우 리턴주소를 연쇄적으로(setreuid->execl) 바꿔주고......
댓글 달기