리눅스 커널 심각한 오류발견(퍼옴)

supersky의 이미지

이 게시판과 성격이 맞는지 모르겠네요~~

공격자로 하여금 시스템의 루트 권한을 탈취하여 완전한 제어권을 가져갈 수 있는 심각한 보안 결함이 리눅스 커널에서 발견되었다. 최근 데비안 프로젝트의 서버가 침입당한 것은 바로 이 보안 결함을 악용한 공격에 의한 것이라고 한다.
이 결함은 단순히 애플리케이션에 존재하는 것이 아니라 리눅스 커널 자체에 존재하는 것이기 때문에 모든 리눅스 배포판에 영향을 준다는 점에서 매우 심각한 것이다. 이 결함은 리눅스 커널 2.4.0에서 2.5.69버전에 모두 해당되며 2.3.23-pre7과 2.6.0-test6에서는 결함이 수정되었다고 한다.

이 결함은 메모리 관리 기능인 brk( ) 시스템 콜에서 정수 오버플로우 현상을 일으키는 것이며 필요 주소와 길이 변수를 사용하여 do_brk( ) 펑션을 호출하게 되면 이 시스템 콜이 변수를 더하면서 정수 오버플로우를 체크하지 않는다고 한다.

보안 전문 업체인 시만텍에 따르면 이러한 결함으로 인해서 쉘 레벨 접근 권한을 가지고 있는 모든 로컬 유저들이 권한을 루트까지 확장할 수 있다고 하며 권한을 탈취하게 되면 시스템의 어떠한 작업도 실행하거나 중지시킬 수 있게 된다. 시만텍은 이 결함이 단순히 로컬 시스템 내부 문제가 아니라 이 결함이 원격 공격자로 하여금 루트 권한을 취득하도록 연계 될 수 있다고 경고했다.

여러 리눅스 배포판 업체들은 이에 빠르게 경고 메시지를 보내고 이를 수정하는 방법을 제공중에 있다. 위에서 언급했듯이 이 결함은 리눅스 커널에 존재하는 것이기 때문에 레드햇, 수세, 데비안, 맨드레이크등 모든 리눅스 배포판에 존재한다.

인용 : http://news.kbench.com/?no=23033&priority=1&category=61

참고 : https://rhn.redhat.com/errata/RHSA-2003-392.html

새로운 커널 다운로드 받기 상당히 힘들군요..
누가 미러링좀 해주세요.. ^^
저도 받으면 미러링 하겠습니다.

dg의 이미지

전 linux.sarang.net에서 받았는데요.. 2.4.23
잘 받아지던데..

pleasantman의 이미지

2.4.23 커널은 패치가 된 커널인지요?

어느 넘을 받아야 하는 건지요?

dhunter의 이미지

supersky wrote:
2.3.23-pre7과 2.6.0-test6에서는 결함이 수정되었다고 한다.

이기 때문에 2.3.23은 패치되어 있습니다. (PRE 이니까요. 그 뒤도 RC도 몇개 나오긴 했습니다만...)

from bzImage
It's blue paper

jj의 이미지

Quote:
시만텍은 이 결함이 단순히 로컬 시스템 내부 문제가 아니라 이 결함이 원격 공격자로 하여금 루트 권한을 취득하도록 연계 될 수 있다고 경고했다.

exploit 공개되면 나오면 난리 나겠군요... 후다닥...

--
Life is short. damn short...

dubhe의 이미지

asm으로 짜여져있고 매우 간단하더군요.

외국사이트에 오늘아침 올라온것 같습니다.

URL은...생략하겠습니다 --;;;;

송지석의 이미지

저번 데비안 compromise 사건이 이 버그 때문에 해킹된 때문인 것으로 알려졌습니다. 새소식란 참고하시길..
9월에 발견된 버그입니다.
http://www.hackerslab.org/korg/view.fhz?menu=news&no=1742

fibonacci의 이미지

jj wrote:
Quote:
시만텍은 이 결함이 단순히 로컬 시스템 내부 문제가 아니라 이 결함이 원격 공격자로 하여금 루트 권한을 취득하도록 연계 될 수 있다고 경고했다.

exploit 공개되면 나오면 난리 나겠군요... 후다닥...



해커스랩 가보니까 이미 공개되었네요..
커널 컴파일때까지 일반사용자 접속을 각별히 조심해야 겠습니다.

No Pain, No Gain.

supersky의 이미지

위에서 질문하신건데요... 찾아서 올립니다.

RedHat기준입니다.

7.1 : kernel-2.4.20-24.7.src.rpm
7.2 : kernel-2.4.20-24.7.src.rpm
7.3 : kernel-2.4.20-24.7.src.rpm
8.0 : kernel-2.4.20-24.8.src.rpm
9 : kernel-2.4.20-24.9.src.rpm

위가 Patch한 커널이라고 RedHat에 나와있더군요...
https://rhn.redhat.com/errata/RHSA-2003-392.html
위 URL에서 다운 받으시면 됩니다.

void main()
{
printf("Hello World\n");
exit(0);
}
/* 초심으로 돌아가자~~~~~ */

dhunter의 이미지

fibonacci wrote:
jj wrote:
Quote:
시만텍은 이 결함이 단순히 로컬 시스템 내부 문제가 아니라 이 결함이 원격 공격자로 하여금 루트 권한을 취득하도록 연계 될 수 있다고 경고했다.

exploit 공개되면 나오면 난리 나겠군요... 후다닥...



해커스랩 가보니까 이미 공개되었네요..
커널 컴파일때까지 일반사용자 접속을 각별히 조심해야 겠습니다.

조심할 필요도 없이 아예 끊고 작업하는게 안전하겠네요 (^^; )

어차피 이 정도의 심각한 보안 위험을 생각하면 몇십분의 쉘 접속 불가는 큰 문제가 아니니까요.

from bzImage
It's blue paper

fibonacci의 이미지

제가 관리하고(?) 있는 섭은, 계산 섭이라서...
그리고 요새 한창 논문쓰는 시기라서,
컴한번 끄면 몇명한테 난도질을 당할지도 -_-;
2.4.23도 받아만 놓고 컴파일 생각도 못하고 있네요...

No Pain, No Gain.

dubhe의 이미지

시만텍에서 remote로도 가능하다고 프레스에 나간거 같은데...

do_brk()에서의 취약점은 syscall인 brk()에서 발생하는것인데

로컬 외에는 전혀 불가능할것 같습니다. 시만텍에서 왜 그런 말도안되는 헛소리를 하는지 이해가 안가는군요...

현재 알려진 공격방법은 ELF헤더를 조작하여 do_brk()시에 커널메모리쪽(0xc0000000상위부분)을 rwx로 조작가능하게해서 접근하는 방식입니다.

jj의 이미지

dubhe wrote:
시만텍에서 remote로도 가능하다고 프레스에 나간거 같은데...

do_brk()에서의 취약점은 syscall인 brk()에서 발생하는것인데

로컬 외에는 전혀 불가능할것 같습니다. 시만텍에서 왜 그런 말도안되는 헛소리를 하는지 이해가 안가는군요...

현재 알려진 공격방법은 ELF헤더를 조작하여 do_brk()시에 커널메모리쪽(0xc0000000상위부분)을 rwx로 조작가능하게해서 접근하는 방식입니다.

굳이 해명하다면 nobody 로 돌아가는 데몬에라도 bof 구멍이 있으면 root 딸 수 있다... 그정도로 해명할 수 있을런지요...?

--
Life is short. damn short...

dubhe의 이미지

jj wrote:
dubhe wrote:
시만텍에서 remote로도 가능하다고 프레스에 나간거 같은데...

do_brk()에서의 취약점은 syscall인 brk()에서 발생하는것인데

로컬 외에는 전혀 불가능할것 같습니다. 시만텍에서 왜 그런 말도안되는 헛소리를 하는지 이해가 안가는군요...

현재 알려진 공격방법은 ELF헤더를 조작하여 do_brk()시에 커널메모리쪽(0xc0000000상위부분)을 rwx로 조작가능하게해서 접근하는 방식입니다.

굳이 해명하다면 nobody 로 돌아가는 데몬에라도 bof 구멍이 있으면 root 딸 수 있다... 그정도로 해명할 수 있을런지요...?

일반유저->root의 권한상승부분취약점이 맞긴 하지만 (그리고 BOF는 아닙니다. integer overflow라고 외국에서 말하던데 엄밀히 보면 integer overflow도 아니고 구현을 잘못한겁니다.) 현재 가능한 공격방법은 ELF헤더를 이용한다는것 이지요.이부분이 remote로 확장? 이라는 부분이 말이 안된다는 점입니다.

do_brk()는 address주소와 길이(len) 두개의 인자만을 갖는데 이 길이부분의 구현때문에 발생하는 문제인데 리모트에서 이걸 사용하게될때 건드릴 방법이 일단 없다고 보여집니다.

그리고 ELF헤더를 조작한 방법도 매우 독특하게 되어있습니다.

entry point를 스택쪽(0xbfff어쩌구)으로 잡아 코드넣고 ELF헤더의 메모리사이즈를 크게해서 0xc어쩌구 이상의 커널메모리까지 잡히도록해서 접근하는방식입니다.(프로그램이 사용하는 영역을 커널영역까지 포함하도록 속이는것이지요) 일반적인 상황에서는 생길수가 없습니다.

jj의 이미지

dubhe wrote:
일반유저->root의 권한상승부분취약점이 맞긴 하지만 (그리고 BOF는 아닙니다. integer overflow라고 외국에서 말하던데 엄밀히 보면 integer overflow도 아니고 구현을 잘못한겁니다.) 현재 가능한 공격방법은 ELF헤더를 이용한다는것 이지요.이부분이 remote로 확장? 이라는 부분이 말이 안된다는 점입니다.

그렇군요. Remote attack이 불가능 하다니, 천만다행입니다. 안녕히...

--
Life is short. damn short...

fibonacci의 이미지

해커스랩에서 읽기로는,
일반사용자 계정을 하나 뚫어서(스니핑등 기타 방법으로)
거기서 어셈코드를 돌려 루트권한을 얻는 식의 방법이던데요..
그러니 일반사용자계정을 뚫리지 않는다는 확신만 있으면
안심해도 될것 같습니다.
-----------------------------------------------
심심해서 제 섭에서 문제의 어셈코드로 실험해보고 있는데
따라하는것도 잘 안되네요.
제 커널은 2.4.18인데, 이게 먹히는 커널버전인지?

No Pain, No Gain.

Tony의 이미지

아직 remote로 뚫고들어가는 exploit이 알려진게 없을뿐 결코 불가능한건
아니라고 생각됩니다. 외부 접속을 받아서 그 결과를 malloc한후 저장하는
서버가 있다면 그리고 그 입력데이타의 길이제한이 없다면 가능할수도
있는 버그라고 생각됩니다. 처음 저 코드 버그를 보고 누가 exploit을 작성할
수 있을까 생각했는데 아예 elf헤더쪽을 건드려서 exploit을 만든걸보면
누가생각해냈는지 몰라도 참 대단하다는 생각이.....

아무튼 remote exploit이 이론적으로 불가능하다. 라는 말은 못할 것 같습니다.

김정균의 이미지

http//seclists.org/lists/bugtraq/2003/Dec/0016.html

에 보시면 어셈코드로 된 테스트 소스 파일이 있습니다.
메모리 write 까지만 가능하게 해 놓은 듯 싶은데, nasm 으로 빌드해서
테스트 해 보실 수 있습니다.

pepierce의 이미지

제가 쓰는 서버는 2.4.18-17.7.xsmp 라고 나오는데..;;

레드햇 가봐도 2.4.20 어쩌구 관련된 자료들만 있던데,

멀 어떻게 해야할지좀 알려주세요..ㅜ.ㅜ

빨리 패치해야할거 같은데..;;;

송지석의 이미지

pepierce wrote:
제가 쓰는 서버는 2.4.18-17.7.xsmp 라고 나오는데..;;

레드햇 가봐도 2.4.20 어쩌구 관련된 자료들만 있던데,

멀 어떻게 해야할지좀 알려주세요..ㅜ.ㅜ

빨리 패치해야할거 같은데..;;;

kernel-2.4.20-24.7.rpm 까세요. 패치된 겁니다.
cdpark의 이미지

Tony wrote:

아무튼 remote exploit이 이론적으로 불가능하다. 라는 말은 못할 것 같습니다.

외부에서 공격해서 내부 사용자 권한을 획득할 수 있으면(remote exploit든, 이번 데비안 사태처럼 패킷 스니핑이든..) 이 버그와 결합해서 root를 얻을 수 있죠. 그 다음엔 rootkit 깔고...

:!: 최근에 rsync code에 heap overflow 버그가 발견되었습니다. rsync server를 띄울 때에 이 버그가 영향을 줍니다. rsync server 관리자 분은 빨리 rsync 버그와 커널 버그를 모두 패치하세요.

sepa74의 이미지

2.3.23-pre7 이버전이 안전한거구요 2.4.23패치까지 된것이 아니면 소용없구요.
2.4.23으로 할필요는 없구 그냥 레드헷 쓰시는 분들은 윗분들이 걸어논 링크가셔서 버전 따라 rpm 패치 받으심 되요

ps:그리고 절대 Uvh 옵션 쓰심 안돼구요 ivh로 하셔야 됩니다.

indexer의 이미지

레드햇 9 인데 up2date 패치나 rpm 패치 둘다 되는 건가요? rpm 패치는 무슨 파일을 받아야 하는건가요?
src.rpm 인가요? 아님 i386.rpm 인가요.. --;
누가 좀 알려주세요. ^^ 부탁드립니다. ^^;
어떻게 패치 할지 참.. --;

난 나야!

niceview의 이미지

그냥 Uvh해도 되던데요? @_@

reboot후 커널 버전 확인해보니 바뀐걸로...

음...

그리고 srpm로 깔면 소스만 깔립니다.

그냥 간단히 패치하시려면 i386을 하시면 될거에요.

jedi의 이미지

niceview wrote:
그냥 Uvh해도 되던데요? @_@

reboot후 커널 버전 확인해보니 바뀐걸로...

음...

그리고 srpm로 깔면 소스만 깔립니다.

그냥 간단히 패치하시려면 i386을 하시면 될거에요.

-ivh 를 사용하는 이유는 위험에 대한 대비입니다. -Uvh를 이용하면 이전 버전 커널은 자동으로 지워지죠.
하지만 -ivh를 사용하면 기존의 커널이 남아 있습니다.
커널 업을 한다음 패닉이 난다면 대처하기가 기존의 잘되던 커널이 살아 있을때가 편하죠.. 일단 부팅은 되니까......
리고 업한뒤에 지우면 되니까요.

+++ 여기부터는 서명입니다. +++
국가 기구의 존속을 위한 최소한의 세금만을 내고, 전체 인민들이 균등한 삶을
영위할 수 있는 착취가 없는 혁명의 그날은 언제나 올 것인가!
-- 조정래, <태백산맥> 중에서, 1986년

HotPotato의 이미지

dhunter wrote:
fibonacci wrote:
jj wrote:
Quote:
시만텍은 이 결함이 단순히 로컬 시스템 내부 문제가 아니라 이 결함이 원격 공격자로 하여금 루트 권한을 취득하도록 연계 될 수 있다고 경고했다.

exploit 공개되면 나오면 난리 나겠군요... 후다닥...



해커스랩 가보니까 이미 공개되었네요..
커널 컴파일때까지 일반사용자 접속을 각별히 조심해야 겠습니다.

조심할 필요도 없이 아예 끊고 작업하는게 안전하겠네요 (^^; )

어차피 이 정도의 심각한 보안 위험을 생각하면 몇십분의 쉘 접속 불가는 큰 문제가 아니니까요.

ssh를 써도 그렇게까지 가능할까요?
ssh를 쓰면 속도는 좀 처지지만 그래도 데이터가 암호화되기 문에 스니핑이 어렵다던데..

--
즐 Tux~

dhunter의 이미지

HotPotato wrote:

ssh를 써도 그렇게까지 가능할까요?
ssh를 쓰면 속도는 좀 처지지만 그래도 데이터가 암호화되기 문에 스니핑이 어렵다던데..

스니핑의 문제 이전에 이미 계정을 얻고 있는 유저라면 누구나가 커널의 약점을 노릴수 있는거니까요. rsync 도 SSH고 일반 텔넷이고 문제가 아니고...

지금의 문제는 스니핑은 아닙니다....

from bzImage
It's blue paper

niceview의 이미지

jedi wrote:

-ivh 를 사용하는 이유는 위험에 대한 대비입니다. -Uvh를 이용하면 이전 버전 커널은 자동으로 지워지죠.
하지만 -ivh를 사용하면 기존의 커널이 남아 있습니다.
커널 업을 한다음 패닉이 난다면 대처하기가 기존의 잘되던 커널이 살아 있을때가 편하죠.. 일단 부팅은 되니까......
리고 업한뒤에 지우면 되니까요.

아.. -i 옵션은 upgrade 와 상관없이 강제 설치하는 옵션인줄 알았습니다.

커널설치의 경우 기존 커널을 살려놓고 하는군요. ^-^

vigor96의 이미지

redhat 6.2 / 7.0 의 경우에는

소스로 설치하는 것 말고는 방법이 없는건가요?..

혹시 6.2/7.0 용 커널 컴파일 된거 있으시면 알려주세요...

cdpark의 이미지

vigor96 wrote:
redhat 6.2 / 7.0 의 경우에는

소스로 설치하는 것 말고는 방법이 없는건가요?..

혹시 6.2/7.0 용 커널 컴파일 된거 있으시면 알려주세요...

6.2/7.0이라면 커널 문제 말고도 여러 보안 버그들이 잔뜩 숨어있을텐데요? 패치가 제공되나요?